Sp Bundle Laravel Package

Product Decisions This Supports

• Enterprise SSO as a roadmap gate. "Login with Okta / Azure AD / Google Workspace" shows up in nearly every enterprise security questionnaire. This package is a candidate input to the build-vs-buy decision for SAML2 SP support — it does not make that decision for you.
• Build vs. buy for the protocol layer. SAML assertion parsing, XML-DSig signature validation, and metadata exchange are high-risk, low-differentiation. The realistic choice is between a managed identity broker (WorkOS, Auth0, Okta, AWS IAM Identity Center) and assembling an OSS library. This package sits on the "assemble" pole via LightSAML core — but the bundle itself is the wrong artifact for a Laravel product.
• Framework-fit triage as a real decision. lightsaml2/sp-bundle is a Symfony Bundle built on Symfony's kernel, DI container, event dispatcher, and config tree. On a Laravel codebase the honest read is that the bundle is not adoptable — but the underlying lightsaml/lightsaml core is framework-agnostic and is the reusable asset. The PM decision becomes: do we fund wrapping LightSAML in a Laravel-native service provider, or buy?
• Scoping SP-only vs. IdP. This is Service Provider software: your app consumes assertions from a customer's IdP. It does not help if you are issuing identities to others, and it does not do SCIM provisioning. Useful for prioritizing "authenticate users against customer IdPs" over "become an IdP," which is a far larger commitment.
• Risk-adjusted OSS selection. 1 star, 0 dependents, composite score 0.035 — effectively unproven in production, wrapping a library lineage with a checkered maintenance history. That belongs in the same decision record as license (MIT, good), PHP/Symfony version support (unverified), and security posture. Treat SAML code as a supply-chain dependency, not a utility.

When to Consider This Package

Consider the LightSAML core, and treat the bundle only as a reference implementation, when:

• Your stack is Symfony — then the bundle's DI wiring, config tree, and routing have real value. On Laravel you inherit almost none of that and should evaluate lightsaml/lightsaml directly.
• You need SP-initiated and IdP-initiated SAML2 and are prepared to own the integration end to end: certificate rotation, metadata refresh, multi-IdP configuration, and secret management.
• You have engineering capacity to vendor or fork. Assume you will read and possibly patch the source, and budget a security review of XML signature handling specifically (signature-wrapping / XSW attacks are the classic failure mode).
• You can pin and track transitive dependencies (xmlseclibs-class libraries) for CVEs, because no one in this repo is watching them for you.
• You want the bundle's services.yml and Configuration.php as a blueprint for the ~200 lines of service graph a Laravel service provider would need.

Look elsewhere when:

• You are on Laravel and want a drop-in. composer requireing the bundle pulls Symfony kernel components into an Illuminate app and will expect a Symfony kernel to boot. Evaluate Laravel-native SAML packages (aacotroneo/laravel-saml2, 24slides/laravel-saml2, which wrap OneLogin's toolkit) or the LightSAML core wrapped yourself — and expect to write the glue either way.
• You need a supported dependency: an SLA, a security contact, a changelog you can cite in a SOC 2 evidence request. A 1-star, 0-dependent package cannot carry that weight in a vendor review.
• Your requirement is really OIDC/OAuth — most modern IdPs offer OIDC, which is dramatically simpler and better tooled. SAML is often a legacy-customer accommodation, not a technical necessity.
• Time-to-market dominates: a managed broker ships SSO in days and converts a multi-week protocol project into a line item.
• You need to act as an IdP or need SCIM provisioning — this package does neither.

How to Pitch It (Stakeholders)

To executives: Enterprise SSO is a recurring blocker on mid-market and enterprise deals, appearing as a hard requirement in security reviews. It's a solved problem with two viable paths — assemble an open-source SAML library or buy a managed identity broker. The candidate here is MIT-licensed and technically credible at the protocol layer, but it is a Symfony component with essentially zero public adoption. On our Laravel stack the honest framing is: this is a technical reference, not a dependency. Recommendation: timebox a two-week spike behind a feature flag, reimplement the SAML flow in a Laravel-native service provider against the LightSAML core (or benchmark against laravel-saml2), and hold a managed-broker quote as the fallback so the roadmap date doesn't move if the OSS path disappoints.

To engineering: The valuable part is LightSAML's standards-compliant assertion parsing and signing — the expensive, security-critical surface. This bundle is thin Symfony plumbing around that core, and that plumbing does not port into Laravel. Use the bundle's Configuration.php and services.yml as a wiring blueprint, then build the SP flow with Laravel idioms: a service provider, config/saml.php, /saml/metadata, /saml/acs, /saml/login routes, and a controller that calls Auth::login() and regenerates the session. Expect to hand-wire the service graph, store the SP private key and IdP certificate in env/secret storage (never committed), and dispatch a Laravel event from the ACS for audit logging and user provisioning. Treat the SAML path as security-critical: pin dependencies, review XML signature validation against wrapping attacks, and plan per-tenant certificate and metadata rotation from day one. Effort is measured in engineering weeks, not days; the ongoing cost is dependency hygiene plus an on-call story for auth outages — and note that at 1 star and 0 dependents, there is no community to lean on when SSO breaks.