Symfony Bridge Laravel Package

Product Decisions This Supports

• Enterprise SSO roadmap item (SAML 2.0 SP): This is the underlying plumbing that lets an app accept SAML assertions from Okta, Azure AD/Entra, OneLogin, JumpCloud, or a customer's ADFS. If enterprise deals are blocked on "do you support SAML SSO?", this package represents one candidate implementation path — not the decision itself.
• Build vs. buy framing for identity: The real PM decision is managed IdP broker (WorkOS, Auth0 Enterprise, Fronteater, SSOJet, Clerk Enterprise) vs. self-hosted SAML library. This package sits in the self-hosted column and should be evaluated as a line item in that comparison — engineering days, certificate rotation, metadata refresh, and incident surface included.
• Buy vs. borrow for the integration layer: It is explicitly a Symfony bridge, wrapping LightSAML's core for Symfony's DI container, routing, and security stack. In a Laravel codebase this is not a drop-in; it is at best a reference implementation for how to wire attribute mapping, SP metadata endpoints, and ACS (assertion consumer service) routes. That materially shifts the estimate.
• Feature scoping for multi-tenant SSO: If the roadmap includes per-customer IdP configuration (per-tenant metadata URLs, signing certs, attribute/role mapping), the package's SP-side abstractions inform the data model — how much config is per-tenant vs. global, and where the auth boundary lives.
• Deprecation/sunset triage: If this is already in a dependency tree, the zero-star / zero-dependent signal feeds directly into a "keep, wrap, or replace" call — especially given that SAML parsing is security-critical code. Note the 1.6.0 release shows a live maintainer shipping framework compatibility, which is a positive maintenance pulse but not community validation; the keep/wrap/replace decision should now also account for the PHP 8.1 floor.
• Upgrade/cost planning for existing adopters: The 1.6.0 requirement of PHP 8.1+ and Symfony 7 support is a roadmap input for anyone already on this bridge — it either unblocks a Symfony 7 upgrade or forces a PHP-version prerequisite into the same quarter.

When to Consider This Package

Consider it only if:

• You are on Symfony (or a Symfony-components-heavy stack), not a conventional Laravel app. In Laravel, prefer a Laravel-native SAML package built on onelogin/php-saml or a managed broker — the glue code you'd write around this bridge is not free.
• You need full control over the IdP relationship — custom attribute mapping, on-prem customers, data-residency constraints that rule out a hosted broker, or a contractual requirement that assertions never transit a third party.
• You have in-house PHP/Symfony depth to own a security-critical, low-community package: you'll be reading the source, pinning versions, and patching yourself.
• You're evaluating architecture, not shipping: this is a reasonable artifact to read before writing your own SP integration.
• Your platform baseline is PHP 8.1+. As of 1.6.0 that is a hard floor; earlier releases remain an option for PHP 8.0 environments, but that means pinning to an older line with no forward compatibility.

Look elsewhere if:

• You want a supported vendor with an SLA. Zero stars and zero dependents means no community validation, no security response process, and a bus factor of roughly one. For auth, that's a real cost — a recent release does not substitute for a support contract.
• Your timeline is weeks, not quarters. Hosted SSO brokers exist precisely to compress this; for a typical B2B SaaS, buying is usually cheaper than the first year of self-hosting SAML.
• You need SCIM provisioning alongside SAML — this package doesn't address lifecycle management, and bolting it on is another build.
• You require modern auth (OIDC, passkeys) as part of the same roadmap; this is SAML-specific plumbing.
• Your security posture requires a maintained dependency with recent CVE handling. Verify LightSAML core's activity before committing; the bridge's freshness — including the 1.6.0 bump — does not guarantee the underlying parser is current.
• You are stuck on PHP 8.0 or earlier and cannot move; 1.6.0's only headline changes are the Symfony 7 and PHP 8.1 requirements, so the new release offers you nothing.

Adoption gate (if you proceed): pin the version (1.6.0 or later only if you're on PHP 8.1+), vendor the fork if necessary, add SAML-specific integration tests (signed/unsigned assertions, clock skew, replay), and assign a named owner for dependency and certificate hygiene.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed open-source integration layer for SAML single sign-on — the checkbox enterprise buyers ask about. It is not a product or a vendor; it's a piece of plumbing. The strategic question it feeds is whether we buy a managed SSO service or self-host. My recommendation is to price both: buying typically wins until self-hosting is a differentiator or a contractual requirement. If we self-host, this package saves us design work on the Symfony side but carries real maintenance and security-ownership costs that must be staffed, not assumed. The 1.6.0 release is a modest positive signal — the maintainer is still shipping — but it changes nothing about the buy-vs-build math.

For engineering: Treat javer/symfony-bridge as a Symfony-specific adapter over LightSAML — useful as a reference for SP metadata, ACS routing, and attribute mapping, but not a Laravel dependency and not a supported library. The 1.6.0 release adds Symfony 7 support, requires PHP 8.1, and refreshes CI — i.e., compatibility housekeeping, not new capability, and effectively a breaking change for anyone on PHP 8.0. Signals remain weak on adoption: zero stars, zero dependents. Before adopting, confirm the LightSAML core's maintenance status, audit the assertion-validation path, and budget for a fork-and-own posture. If we're on Laravel, evaluate Laravel-native SAML packages or a managed broker first; the integration effort here likely erases the "free" advantage.