Sp Bundle Laravel Package

Technical Evaluation

Architecture fit — poor as published, salvageable only at the library layer. lightsaml/sp-bundle is a Symfony bundle, not a framework-neutral library. It assumes Symfony's DI container, FrameworkBundle config tree, EventDispatcher, HttpKernel request/response cycle, and Symfony routing for its ACS/metadata endpoints. Laravel exposes analogous but non-interchangeable primitives (service providers, config/*.php, middleware, Route). There is no supported path to composer require this into a Laravel app — the bundle's bootstrapping contract simply does not exist there. The only realistic leverage is dropping to the underlying lightsaml/lightsaml core and re-implementing the SP orchestration (AuthnRequest generation, Response/Assertion validation, metadata parsing) inside Laravel-native services. At that point you have adopted the dependency, not the package — which changes the value proposition entirely.

Integration feasibility — low. Three compounding problems:

1. Runtime constraints. As published the bundle targets PHP 7.1+ with Symfony 3.4/4.x. Laravel 9+ requires PHP 8.0+, and Laravel 10/11 require 8.1/8.2. Even with --ignore-platform-reqs, PHP 8 removed/changed behavior that 2019-era code paths rely on. Expect fatal errors or silent deprecation noise.
2. Lifecycle mismatch. Last release 2019-11-13. No Laravel service provider, no facades, no published config shape, no tests against modern PHP.
3. Security-critical domain. SAML SP code is the highest-trust surface in an auth flow. Adopting an unmaintained validator means no patches for signature-wrapping, XML entity expansion, or assertion-replay classes of vulnerability. This is a governance issue, not just a technical one.

Technical risk — high, concentrated in security and longevity. A 2019-frozen SAML implementation is the wrong risk profile for an authentication boundary. lightsaml/lightsaml itself is effectively dormant, so the bundle cannot inherit fixes from below. The 64 stars / 0 dependents signal is a proxy for "no community to catch regressions." A POC will probably work against one IdP, which is precisely the failure mode: it validates the happy path and hides the maintenance liability.

Key questions to resolve before committing:

• Is our requirement SP-initiated only, or do we need IdP-initiated, Single Logout, encrypted assertions, and signed metadata? (SLO is where stale libraries usually fail.)
• Single-tenant IdP or multi-tenant, per-customer metadata? The latter is a much larger build.
• Do we already have customers on this path, or is this greenfield? (Migration cost vs. net-new.)
• What is our internal SAML competence? If thin, unmaintained code is a trap.
• Are we willing to own a fork? If not, this is a no.

Recommendation: do not adopt the bundle. Evaluate framework-agnostic alternatives (SAML-Toolkits/php-saml, actively maintained OneLogin lineage) or a managed IdP-brokered approach (Auth0/WorkOS/Okta as the SAML terminator, OIDC into Laravel). Budget the build vs. buy decision before writing any code.

Integration Approach

Stack fit. None at the bundle level. If the SAML requirement is non-negotiable and we self-host, the correct shape is: framework-neutral SAML library → thin Laravel adapter (service provider + config + auth guard + middleware) → our own routes for ACS, metadata, and login initiation. That adapter is ~2–4 dev-weeks of well-scoped work regardless of which library sits underneath, so the library choice should be driven by maintenance posture, not by bundle convenience.

Migration path. If anything is already running on the Symfony bundle (unlikely given 0 dependents, but confirm), the port is a config extraction exercise: SP entity ID, ACS URL, signing/decryption certs and keys, IdP metadata XML or URL, attribute mapping. All of that is portable. What is not portable is any code that touched the bundle's services or its Symfony event hooks — that gets rewritten. Assume a lift-and-rewrite of the integration layer, preserving only configuration and certificate material.

Compatibility. Hard blockers: PHP 8.x runtime, Symfony 5/6/7 component versions, and PSR/symfony/http-foundation version drift between the bundle's era and current Laravel. Soft blockers: no Laravel-native session handling for AuthnRequest ID correlation and RelayState — you must own that store explicitly, keyed to survive multiple app nodes.

Sequencing (if we proceed at all):

1. Requirements lock (1 week). SP-initiated vs. IdP-initiated, SLO yes/no, encryption, multi-tenant metadata, attribute contract.
2. Spike against two real IdPs (1–2 weeks). Azure AD and Okta, not one — divergent XML handling is the cheapest way to surface library rot. Timebox hard; go/no-go at the end.
3. Security review of the validator (parallel). Specifically: signature verification coverage over Response and Assertion, audience/recipient/InResponseTo/NotOnOrAfter checks, XXE posture, replay cache.
4. Adapter build (2–4 weeks) only after 2 and 3 pass. Include cert-rotation and metadata-refresh runbooks from day one.
5. Dual-run / shadow mode. Log SAML outcomes without enforcing, one release cycle, before cutting over the login path.

If step 2 or 3 fails, pivot to managed brokering — that decision is cheapest at week three.

Operational Impact

Maintenance. This is the decisive factor. An unmaintained 2019 auth dependency transfers the entire patch burden to us: we become the de facto maintainer of a fork, on a security-critical path, with no upstream. That is a permanent headcount tax, not a one-time integration cost. Every PHP minor bump becomes a compatibility audit. Compare against an actively maintained library where the same audit is someone else's job.

Support. Zero. No maintainer response, no CVE feed, no upgrade guide. Internal support means whoever built the adapter owns it indefinitely — a bus-factor-of-one risk that should be documented explicitly.

Scaling. SAML itself scales fine (stateless per-request validation). The scaling hazard is our own state: pending AuthnRequest IDs and RelayState must live in a shared store (Redis) with TTLs — sticky sessions will not survive autoscaling or rolling deploys. Metadata caching must be shared too, or every node hammers the IdP's metadata endpoint and risks throttling. Neither concern is handled for us.

Failure modes to plan for:

• Certificate rotation on the IdP side — the classic outage; login fails org-wide with an opaque XML error. Needs alerting on metadata drift and a documented rotation runbook.
• Clock skew — expired/not-yet-valid assertion windows cause intermittent, hard-to-reproduce failures.
• Metadata fetch failure — a cold cache plus an unreachable IdP endpoint locks out every user; needs a last-known-good fallback on disk.
• Malformed/oversized XML — entity expansion and parser memory blowups on untrusted input; needs strict limits and parser hardening.
• Orphaned IdP sessions — without SLO, users remain logged in at the IdP after local logout, which is a compliance finding in regulated contexts.
• Opaque errors — SAML failure messages are notoriously unhelpful; without structured logging that captures the raw (sanitized) response, MTTR runs in hours, not minutes.

Ramp-up. SAML is a specialty skill; the team's general Laravel fluency does not transfer. Expect 1–2 weeks of genuine ramp per engineer, plus access to IdP admin consoles for both test and production tenants. Testing requires a real IdP sandbox (Azure AD free tier, Okta developer) — SAMLtest.id is useful for smoke tests but insufficient for signature/encryption edge cases. Budget that environment setup into the plan, not after it.

Bottom line for the product decision: the integration cost is roughly the same whether we build on this bundle's core or on a maintained alternative, but the run-rate cost is not. Recommend rejecting lightsaml/sp-bundle and spending the same engineering budget on a maintained library or a managed broker.