Sp Bundle Laravel Package

Product Decisions This Supports

• Scoping and pricing the enterprise SSO epic. This package is useful as a specification of the work, not as a dependency: reading it surfaces the real deliverables behind "add SAML" — SP entity and key management, an ACS endpoint, metadata generation and exchange, IdP trust configuration, attribute mapping, session establishment, and (separately) certificate rotation. That list is what you scope, estimate, and attach to a deal.
• Framing the build-vs-buy call. It anchors the cheapest possible "build" position: a thin framework wrapper over a SAML core library. Compare it honestly against a hosted broker (WorkOS, Auth0, FusionAuth) and against maintained self-hosted options (onelogin/php-saml, SimpleSAMLphp) on the dimensions that decide the contract — IdP interop breadth, Single Logout, encrypted assertions, IdP-initiated flows, metadata refresh, and who carries the pager.
• Correcting a framework-scope assumption. This is a Symfony bundle, not a Laravel package — no service provider, no bridge, no usage example for Laravel. That fact alone removes it from a Laravel evaluation matrix and routes the roadmap to a Laravel-native SAML package or a broker. Letting it sit in the candidate list as "a Laravel option" manufactures false confidence in the timeline.
• Quantifying dependency and maintenance risk on the trust boundary. Zero stars, zero dependents, a single maintainer, and a dependency on LightSAML (effectively maintenance-only) means no security review process, no CVE watch, no upgrade path. Since SAML parses hostile XML directly in front of authentication, that is a product risk with a blast radius, not a code-hygiene nit.
• Negotiation leverage with a demanding customer. If one account insists on SAML, this package is concrete evidence that the cheap path is a bespoke integration you'd own forever. That supports offering a brokered SSO timeline instead of committing to a one-off.
• Deciding how SSO enters the roadmap at all. Whether SSO is a checkbox requirement (password + MFA fallback is acceptable) or a competitive feature (it must be supported, certified, and monitored) determines whether any in-house SAML work is rational. That is a PM call, not an engineering one.

When to Consider This Package

Consider it only as a reference implementation — a readable example of how the AuthnRequest → IdP redirect → POST to ACS → validate → establish session sequence is wired in Symfony. That use is nearly always safe and occasionally valuable for sanity-checking a design.

It becomes a candidate dependency only if all of the following hold:

• The application is Symfony-based. For a Laravel codebase this is not a candidate at all.
• Scope is one to three IdPs, each of which you can get metadata for and hand-test against directly.
• You have an engineer who has genuinely shipped SAML before — XML signature wrapping, Destination/Audience validation, clock skew, assertion replay — and who will fork and vendor the code rather than trust upstream.
• SSO is a checklist requirement with a working password + MFA fallback, not a hard availability dependency.
• You accept that your team owns the security review, the LightSAML audit, and every future PHP/Symfony upgrade.

Look elsewhere if any of these are true:

• You're on Laravel — wrong framework; the container, config, and HTTP lifecycle assumptions do not boot.
• You need IdP interop breadth (Okta, Entra, ADFS, Ping, OneLogin), Single Logout, encrypted assertions, or IdP-initiated flows out of the box.
• You have compliance obligations (SOC 2, ISO 27001, HIPAA) that presume a supported component with a disclosure process and an SLA.
• The buyer expects SCIM provisioning alongside authentication — a SAML SP library does not get you there.
• You have more than a handful of customers, or a self-serve SSO motion where you cannot hand-test every tenant.

Stronger defaults to evaluate instead: a maintained Laravel-native SAML SP for Laravel, onelogin/php-saml or SimpleSAMLphp for self-hosted PHP, or a broker if you would rather not own the trust boundary at all.

How to Pitch It (Stakeholders)

Executives. We evaluated a SAML 2.0 Service Provider bundle that could, in principle, unlock enterprise SSO. It is a Symfony bundle built on the legacy LightSAML library, MIT-licensed, with zero stars, zero dependents, and a single maintainer. It demonstrates the shape of the integration but is not a viable production dependency: it is unmaintained, its underlying SAML library is legacy, and it does not fit our Laravel stack. Authentication is our highest-trust boundary — an unpatched XML parser in front of login is an incident waiting to happen, and a breach costs far more than any code we'd save. Recommendation: do not adopt. If enterprise SSO is on the roadmap, budget for either a maintained SAML library we integrate and test against each customer's IdP, or a hosted SSO broker that offloads IdP certification, Single Logout, and SCIM. Integration effort is broadly similar either way; the difference is who owns the pager and the CVE feed.

Engineering. Treat this repo as a reference implementation, not a dependency. It is worth reading for how metadata exchange, assertion validation, and the ACS round trip are structured, and it gives us a concrete requirements list for the SSO epic. If we ever need a stopgap for a single Symfony service, we vendor it into our tree, pin it, and write our own tests around signature validation, audience/destination checks, and replay — with no expectation of upstream upgrades or upstream trust. For Laravel, start from a maintained Laravel-native SAML SP or a broker SDK, and fund the work as a small, security-reviewed project with a named owner, alerting on certificate rotation and validation failures, and the legacy login path kept warm for one full release cycle.