Symfony Bridge Laravel Package

Product Decisions This Supports

• Enterprise SSO as a roadmap item. SAML 2.0 is still the default protocol for selling into enterprise IT (Okta, Azure AD/Entra, ADFS, OneLogin, Ping). This package is one option on the "how do we ship SSO" decision table — it tells you what a bundle-based (Symfony-style) integration path would cost versus a first-party or hosted approach.
• Build vs. buy for identity. SAML is not a feature you hand-roll: XML canonicalization, signature validation, assertion replay protection, and clock skew handling are all places where a subtle bug becomes an auth bypass. This package is the "assemble from open-source parts" branch of that decision — useful mainly as a cost anchor when comparing against a hosted IdP/broker or a commercial SP library.
• Buyer-segment prioritization. If your pipeline is SMB/PLG, SSO is a checkbox that a broker (WorkOS, Auth0, Ory, Keycloak) satisfies for a fixed per-connection price. If your pipeline is mid-market and above, SAML becomes a procurement blocker and the decision moves from "nice to have" to "revenue-gating." This assessment helps you place SSO on the roadmap with a defensible trigger.
• Platform-consistency decisions. The package is a Symfony bridge, not a Laravel one. That's a direct input into the "do we adopt framework-native packages or port adjacent-ecosystem ones" decision — and a reminder that the cost of porting is a permanent maintenance tax, not a one-time task.
• Deprecation/technical-debt triage. With a last release in May 2018, zero dependents, and a low opportunity score, this is a "do not adopt" data point for the architecture review — useful for closing out the "should we just use the LightSAML Symfony bundle?" question definitively rather than re-litigating it each quarter.

When to Consider This Package

Adopt only under a narrow set of conditions:

• You are on Symfony, not Laravel. The repository is lightSAML/SymfonyBridgeBundle — it ships a Symfony bundle (DI extension, service definitions, configuration tree). On Laravel you would be wiring Symfony's DI container into a Laravel service provider, or more realistically reimplementing the ~few-hundred-line bridge yourself. That's the entire value of this package, and it's the part you'd be throwing away.
• You are pinned to a PHP 7.x / Symfony 3–4 stack. Laravel 10/11 run on Symfony 6/7 components; the bundle's service definitions, autoloading, and any deprecation-era API usage are unlikely to survive that jump without patching.
• You need the low-level LightSAML primitives, not a finished SP. This bundle is a thin wrapper over lightsaml/lightsaml — you still own metadata exchange, ACS/SSO endpoint routing, attribute mapping, user provisioning/JIT, and session lifecycle. Budget for that work explicitly.
• You have in-house PHP security expertise to review and pin the transitive dependency tree, since you will be maintaining a fork.

Look elsewhere when:

• You're on Laravel and want SAML now. Evaluate aacotroneo/laravel-saml2 or the socialiteproviders/saml2 Socialite driver against your Laravel version, or skip the protocol entirely and use a broker. These are maintained-adjacent at best; treat all of them as "review the dependency tree before committing."
• You want to not own SAML. WorkOS, Auth0, Okta, Ory, or self-hosted Keycloak as an SP-side broker remove signing-cert rotation, IdP-specific quirks, and the audit surface from your team.
• You need SAML and OIDC and SCIM. A single-protocol bundle answers one-third of the enterprise identity question; SCIM provisioning is usually the next blocker after SSO.
• Security review is a gate. An unmaintained library in the authentication path is a hard fail for most security teams, regardless of code quality. Expect the review to end there.

How to Pitch It (Stakeholders)

For executives: "We evaluated an open-source SAML integration for enterprise SSO. It's a thin glue layer for Symfony applications, last released in 2018, with essentially no adoption, and it doesn't cover the parts of SSO that actually cost money — user provisioning, attribute mapping, certificate rotation, and support. Recommendation: don't build SSO on this. Either budget for a maintained SP library plus ~X engineer-weeks of integration, or pay a broker a per-connection fee and ship SSO in a sprint instead of a quarter. Either way, SSO is a sales-unblocking item for mid-market and up, so it belongs on the roadmap — just not through this dependency."

For engineering: "This is a Symfony bundle, not a Laravel package — everything it does, we'd have to adapt or rewrite, and it's ~7 years stale against Symfony 6/7. It wraps lightsaml/lightsaml and leaves us owning the ACS endpoint, metadata handling, attribute mapping, and replay/clock-skew edge cases. It also puts an unmaintained dependency in the auth path, which our security review will flag. If we go the library route, prefer a maintained SAML toolkit or a Socialite driver we can pin and audit; if we want this off our plate, a broker integration is a fraction of the surface area and shifts the certificate/spec-quirk maintenance to the vendor."

Bottom line for the decision log: Low opportunity, low adoption, stale release, wrong framework — no. Revisit only if the org standardizes on Symfony and someone owns the fork.