Saml Bundle Laravel Package

Technical Evaluation

Architecture fit — unchanged, and still poor at the framework boundary. The v2.0 release note ("Support symfony 4.") does not alter the fundamental problem: pdias/SamlBundle is a Symfony bundle, not a Laravel package. Its integration surface remains Symfony-specific — a Bundle class, a DependencyInjection\Extension with a Configuration tree, compiler passes, and event-subscriber wiring into Symfony's kernel and security firewall. Laravel's service container, config repository, middleware pipeline, and auth guards share no contracts with these. There is still no ServiceProvider, no publishable config, no facade. Any Laravel use remains a re-implementation, not an installation. A Symfony 4 target actually widens the gap: Symfony 4's DI and bundle conventions predate the Symfony 5.4/6.x idioms, so the code is now two framework generations behind the ecosystem we would even hypothetically borrow patterns from.

What v2.0 actually tells us. Read the release for what it is: a major version bump whose entire changelog is one line. That is a meaningful signal in three directions:

• Positive, but minimal. The maintainer is not entirely absent; there is a pulse. The 2019 timestamp in the prior assessment is now superseded.
• Negative on currency. Symfony 4 reached end of life in November 2023. Shipping a release whose headline feature is support for an EOL framework generation — with no mention of Symfony 5.4 LTS, 6.x, or 7.x, and no mention of PHP 8.x — does not indicate revival, it indicates a one-off catch-up. The package remains unusable on any currently supported Symfony, which is the strongest possible evidence that it will never be a viable Laravel dependency.
• Negative on maintenance discipline. A major version bump with no migration notes, no deprecation path for 1.x, and no enumerated breaking changes is a governance red flag. If we forked, we would be inheriting an upgrade with undocumented blast radius.

Where the value actually sits — now with a caveat. The bundle remains a thin configuration and DI wrapper around a SAML 2.0 SP toolkit (historically the OneLogin php-saml lineage). The real protocol work — AuthnRequest construction, SAMLResponse parsing, XML-DSig validation, assertion decryption, metadata generation — lives in that underlying library. Treat the bundle as a reference implementation of SP configuration and controller flow, not a dependency. The v2.0 caveat: the configuration shape being referenced is now Symfony 4-era, so its SP knobs (entity ID, ACS URL, SLO endpoints, signing/encryption certs, NameID format, attribute mapping) should be checked against the current toolkit's schema rather than copied. The conceptual checklist survives; the literal config keys may not.

Integration feasibility — still low, marginally improved but not decision-changing.

Technical risk — still concentrated in the security-critical path. SAML is an XML-signature and assertion-trust protocol; the failure mode is an authentication bypass, not a broken page. The v2.0 release says nothing about the pinned toolkit version, so the core risk is unresolved:

• Unpatched XML parsing exposure (XXE, signature-wrapping / XSW class of attacks) if the underlying toolkit predates those fixes — and a Symfony-4-era refresh makes a stale transitive pin more likely, not less.
• No composer audit / advisory coverage — nobody is filing CVEs against a 16-star bundle with zero dependents.
• PHP 8.x incompatibilities (dynamic properties, mcrypt remnants, typed signature changes in transitive deps) are untouched by a release that targets Symfony 4-era PHP baselines.
• Certificate and metadata rotation logic never exercised against a modern IdP's published metadata.

Key questions — one is now answered, the rest stand:

1. Is the package abandoned? Answered: semi-maintained at best. A single one-line major release after six years, targeting an EOL framework, is not a support signal.
2. Which underlying SAML toolkit version is pinned in v2.0, and does it include the XSW and XXE mitigations? The release notes do not say.
3. Were there breaking changes between 1.x and 2.0 beyond the Symfony constraint bump? Undocumented — matters only if anyone proposes forking.
4. Is SAML an actual IdP requirement, or a proxy for "enterprise SSO"? If the latter, OIDC/SAML via a maintained vendor SDK is cheaper.
5. Who owns security patching for a forked auth component, and what is the SLA?
6. Does the IdP support multiple SPs so we can run a parallel pilot without disturbing existing integrations?

Recommendation: reject as a direct dependency; retain, with reduced confidence, as an architectural reference. v2.0 does not change the decision — it reinforces it. The decisive signals from the prior assessment (0.23 score, zero dependents, no Laravel surface) are untouched, and the new release adds two of its own: it targets an EOL framework generation, and it ships as an undocumented major bump. The opportunity: 11.42 reading still points the right way — the gap is real (no well-maintained, Laravel-native SAML SP), which argues for a thin internal wrapper over a maintained toolkit, not adoption of a Symfony bundle that has just demonstrated it is not tracking supported runtimes.

Integration Approach

Stack fit. Still no direct fit; v2.0 changes nothing here. The pragmatic pattern remains a three-layer decomposition:

1. Protocol layer — a maintained SAML toolkit (OneLogin php-saml current major, or lightsaml), owned via explicit Composer constraint and monitored through composer audit.
2. Bridge layer — a Laravel package we author: SamlServiceProvider, config publishing, a guard or middleware that resolves the assertion to an Eloquent user, and an event for post-auth hooks.
3. Policy layer — attribute-to-role mapping, JIT provisioning rules, and multi-tenant IdP resolution keyed off email domain or explicit tenant slug.

The bundle's contribution is confined to the conceptual configuration checklist and the ACS/SLS controller flow; with v2.0 the literal Symfony 4 config shape should be re-validated against the current toolkit before reuse. Budget roughly 1–2 engineer-weeks for a competent PHP dev to build the bridge.

Migration path. Still assume greenfield SP integration — zero dependents means there is almost certainly no existing pdias deployment to migrate from. The v2.0 major bump is a reminder that anyone who did deploy it now faces an undocumented upgrade; not our problem, but worth citing in the decision record.

• Option A — Bridge (recommended). Toolkit + in-house Laravel wrapper. Full control, patchable, testable. Cost: ~2 weeks build, ~1 week/quarter maintenance.
• Option B — Vendor an existing maintained Laravel SAML package. Faster, but the Laravel SAML ecosystem is itself thin and several popular packages are similarly stale; vet each with the same scorecard (last release, dependents, advisory history, supported PHP/Laravel matrix). Do not assume "has a Laravel tag" means maintained.
• Option C — Managed identity broker. Offload SAML to an IdP-broker or auth SaaS and consume OIDC/SAML from Laravel. Higher run cost, lowest engineering risk, fastest to a compliance-ready posture. Preferred if the deadline is aggressive or the team lacks SAML depth.
• Option D — Fork the bundle. Now more clearly indefensible. Forking a package that just shipped an undocumented major version targeting an EOL framework means inheriting an unpriced upgrade burden on top of the security-patching burden. Reject.

Compatibility notes. If any evaluation path touches the bundle directly, v2.0 narrows rather than widens the matrix: it asserts Symfony 4, which is EOL, and says nothing about Symfony 5.4 LTS, 6.x, or 7.x, nor about PHP 8.1/8.2/8.3. Expect failures on the DI extension and on deprecated dynamic-property usage before you reach the protocol layer. Verify against the current Laravel LTS and supported PHP versions, not against the bundle's stated target.

Sequencing. Enforce gates; do not let this run as a straight-line build.

1. Spike (3–5 days). Stand up the chosen toolkit against a test IdP (or a simplesamlphp test IdP). Produce a signed AuthnRequest and validate a signed response end-to-end. Output: go/no-go on the toolkit. Explicitly include a check of the toolkit's pinned version and its advisory history — the thing v2.0 left undisclosed.
2. Threat model + decision record. Enumerate XSW, XXE, replay, and clock-skew defenses. Record the reject-pdias decision with the v2.0 evidence (EOL target, undocumented major bump, zero dependents) and name an owner.
3. Bridge build behind a feature flag. Config, routes, guard, user resolution, attribute mapping. Ship dark.
4. Contract tests. Fixture corpus of valid, expired, unsigned, wrong-audience, wrong-recipient, and tampered assertions — each must fail closed. This corpus is the single highest-leverage artifact you will produce.
5. Pilot with one IdP, one tenant, internal users only; parallel-run against password auth.
6. Cert rotation and metadata refresh drill before GA — not after. Then general availability, then decommission the fallback path on a stated date.

Operational Impact

Maintenance. v2.0 does not create an upstream to lean on; it creates the illusion of one. A single one-line release after six years, targeting an EOL Symfony generation, with no migration notes, is not a maintenance cadence — and the total absence of Symfony 5.4/6.x/7.x and PHP 8.x support tells us the next release, if any, is not on a schedule we can plan against. Adopting the bundle still transfers ~100% of maintenance to us on day one, now with an undocumented major-version delta attached. The bridge approach retains the better profile: the toolkit upstream absorbs protocol churn, and we own only config and mapping code — a small, readable surface one engineer can maintain. Budget ~2–4 engineer-days per quarter for dependency bumps and certificate/metadata hygiene, plus a mandatory review whenever the toolkit publishes a security release.

Support. Still no vendor, no SLA, no maintainer responsiveness, no triage community. v2.0 slightly dilutes the "abandoned" framing but does not create a support relationship — there is no issue-triage signal, no backport policy, and no security disclosure process. Internal support falls to whoever built the bridge, which argues for documenting it as a platform component with a named owner and a runbook, not an app-team responsibility. "Login is broken for everyone" needs a paged owner and a documented break-glass path.

Scaling. Unchanged. SAML SP traffic is low-volume and bursty — one assertion exchange per session, so per-request protocol cost is negligible relative to normal app load. Real scaling concerns are stateful: SP-initiated request ID tracking (for replay and InResponseTo validation) needs a shared store across multiple nodes, and IdP-initiated flows must tolerate concurrent logins. Session store sizing, not SAML parsing, is the capacity lever.

Failure modes to instrument from day one. These are the incidents you will actually have:

• Certificate expiry — the highest-frequency, most preventable outage. Alert at 30/14/7 days on both SP signing cert and IdP metadata cert; automate rotation.
• Signature validation failures after an IdP-side cert roll or metadata change — surface the specific validation error, not a generic 401.
• Clock skew — assertion NotBefore/NotOnOrAfter rejections; enforce NTP and publish the tolerance.
• ACS URL / Entity ID mismatch after a domain or environment change — a config-drift classic between staging and prod.
• Attribute mapping drift — IdP renames mail to emailAddress; user provisioning silently returns null and JIT creates broken accounts. Validate required attributes and fail loudly with a named missing claim.
• Silent fail-open — the worst outcome. Assert as a hard invariant that any unparsed or unverified response is rejected, and test it.

Ramp-up. Plan for 2–3 weeks before the owning engineer is productive: SAML's binding types, signature placement, and metadata semantics are not learnable from code alone. Ramp on the bundle path is now slower than before, not faster — the documentation is thin, the code targets an EOL Symfony, the dependencies are stale, and the community corpus is empty (no blog posts, no Stack Overflow, and a one-line changelog that explains nothing). The bridge path ramps faster because the toolkit has real documentation and an active issue tracker. Add explicit handover artifacts — runbook, test IdP setup, certificate inventory, and the assertion fixture corpus — or you will re-derive this knowledge at the first outage, at the worst possible time.

Bottom line for the portfolio decision: v2.0 is a signal to re-confirm, not revisit. Treat pdias/saml-bundle as documentation, not a dependency. Fund a thin in-house Laravel bridge over a maintained SAML toolkit, or buy the problem away with a managed broker if the timeline is the binding constraint.