Sp Bundle Laravel Package

Technical Evaluation

Architecture fit. Poor. lightsaml2/sp-bundle is a Symfony Bundle, architected around Symfony's HttpKernel, DependencyInjection, bundle bootstrapping, and configuration tree. Laravel has no bundle concept—it uses service providers, facades, its own container, and middleware/route primitives. The bundle's specific value (auto-registration, config schema, bundled controllers/routes) does not transfer to Laravel without a deliberate port. The reusable asset is the framework-agnostic LightSAML core engine, not this wrapper. For a TPM, the honest read is: this package is a decision input and reference implementation, not a dependency to adopt.

Integration feasibility. Low for the bundle itself; moderate for the engine beneath it. You cannot composer require this and boot it inside Laravel—it will expect a Symfony kernel. Feasible paths are (a) wire LightSAML core directly into a Laravel service provider with ACS, metadata, login, and logout routes plus middleware, or (b) fork the bundle into a Laravel-native package. Both are small internal projects, not drop-ins. The bundle's services.yml and Configuration.php are the most valuable artifacts, as a blueprint for the service graph.

Technical risk. High. Adoption signals are near-zero (1 star, 0 dependents, composite score 0.035). SAML2 SP is a security-critical surface: XML-DSig signature validation, canonicalization, assertion replay protection, certificate handling and rotation, metadata exchange. A low-adoption wrapper around a LightSAML lineage with a checkered maintenance history is a supply-chain and patch-latency exposure. PHP 8.x and Symfony 6/7 support is unverified, which erodes even its reference value. MIT licensing is the one clear positive.

Key questions.

• Is lightsaml2 a maintained fork of the original LightSAML bundle, and what is the release and security-disclosure cadence?
• Which LightSAML core version does it pin, and does that core support current PHP?
• Which SAML profiles are covered—SP-initiated SSO only, or also SLO and IdP-initiated?
• Does it handle signed metadata generation, key/cert rotation, and multi-IdP configuration?
• Who actually maintains it, and is there a security contact?
• Does the bundle do anything materially beyond ~200 lines of LightSAML wiring a Laravel service provider would produce?

The high "opportunity" score reflects category demand (enterprise SSO is universally requested), not fitness of this specific package.

Integration Approach

Stack fit. The bundle does not fit a Laravel stack. Reframe the decision for stakeholders: adopt LightSAML core and build a thin, Laravel-native integration, rather than pulling Symfony kernel and DI into an Illuminate application. This keeps the stack coherent and avoids dragging in transitive Symfony constraints Laravel does not otherwise need.

Migration path. Do not install the bundle into Laravel. Extract its configuration schema, assertion-handling flow, and metadata logic as a reference, then reimplement the SP flow using Laravel idioms (service provider, config/saml.php, ACS/metadata/login routes, auth middleware, Auth::login()). If specific bundle code proves valuable, fork it into a Laravel package rather than shoehorning the Symfony wrapper.

Compatibility. Composer resolution will likely be fragile—the bundle's Symfony dependency ranges conflict with Laravel's expectations. Components Laravel already uses (http-foundation, console, process) are fine; bundles are not. Expect friction on PHP 8.x and Symfony 6/7 ranges, and plan to pin and audit transitive dependencies including xmlseclibs-class packages for CVEs.

Sequencing.

1. Timebox a two-week spike: prototype LightSAML core inside a Laravel service provider behind a feature flag.
2. Implement metadata generation, AuthnRequest (HTTP-Redirect), and ACS response handling with signature validation.
3. Validate end-to-end against the target IdPs (Okta, Entra, Google Workspace).
4. Benchmark against Laravel-native SAML packages that wrap OneLogin's toolkit (e.g., aacotroneo/laravel-saml2, 24slides/laravel-saml2).
5. Hold a managed-broker quote (WorkOS, Auth0, Okta) as the fallback so the roadmap date does not move if the OSS path disappoints.
6. Decide build vs. buy vs. fork with an explicit risk record: license, adoption, maintenance cadence, security posture.

Operational Impact

Maintenance. Effectively unmaintained public project. You inherit the maintenance burden of the adaptation and of any fork. Pin versions, vendor and audit dependencies, and plan for the possibility of owning the SAML stack outright. Treat this as a supply-chain dependency, not a utility.

Support. No meaningful community, documentation, or triage at 1 star / 0 dependents. Rely on internal expertise; budget for hands-on SAML debugging rather than community answers. A supported vendor with an SLA, security contact, and changelog will be required for SOC 2 or vendor-review evidence—this package cannot carry that weight.

Scaling. SP-side SAML is request-bound and low-throughput (login events), so raw concurrency is not the concern. Operational scaling concerns are metadata and certificate rotation, multi-IdP/tenant configuration, and secret management—each of which becomes a per-customer onboarding cost.

Failure modes. Signature validation failures, XML canonicalization and encoding issues, clock skew, expired or rotated certificates, IdP metadata drift, assertion replay—and, most concerning, unpatched vulnerabilities in an abandoned dependency lineage (signature-wrapping / XSW attacks are the classic failure mode). Each can silently break SSO or, worse, weaken authentication. Plan an on-call story for auth outages and per-tenant certificate management from day one.

Ramp-up. Non-trivial. Requires SAML domain knowledge, LightSAML internals, and Laravel adaptation work. With no community to lean on, expect above-average time-to-first-working-SSO and sustained cognitive overhead. The TPM's leverage here is to frame this as a timeboxed spike and a build-vs-buy input—not a commitment—with a managed-broker fallback protecting the roadmap date for the enterprise SSO gate.