Lightsaml Idp Laravel Package

Technical Evaluation

What it is: A server-side PHP implementation of the SAML 2.0 Identity Provider role (metadata, SSO endpoints, assertion issuance/validation), from the lightSAML lineage. It is a protocol engine, not an application framework package. License is GPL-3.0.

Architecture fit: Most Laravel apps are SAML Service Providers (relying on Okta/Entra/Google). Adopting this flips the app into the trust anchor for downstream SPs — an architectural commitment, not a library swap. Fit is strong only if you are deliberately building a portal/IdP for a fleet of SPs you control. For "I need SSO login," this is the wrong tool.

Integration feasibility: No first-party Laravel bridge — expect to build a service provider, config file, routes (/saml/metadata, /saml/sso, /saml/slo), and glue to Laravel's auth/user provider. Requires ext-dom, ext-openssl, ext-libxml; likely depends on lightSAML-core for XMLDSig/canonicalization. Verify Composer constraints against PHP 8.2/8.3 and Laravel 10/11 before scoping.

Technical risk: Three compounding issues. (1) GPL-3.0 is viral copyleft — usually incompatible with closed-source distribution and frequently banned by legal; this alone can kill adoption. (2) Zero stars, zero dependents means essentially no production evidence, peer review, or CVE history. (3) SAML is a CVE-dense protocol (XML signature wrapping, XXE, comment truncation, signature bypass); unaudited crypto/XML code in an auth-critical path is a serious exposure with no maintainer to patch it.

Key questions:

• Is the package actively maintained? Which PHP versions and which XML-security library does it wrap?
• Does it support SP- and IdP-initiated flows, SLO, encrypted assertions, signed metadata, and key rollover?
• Multi-SP / multi-tenant attribute release — or single-relying-party only?
• Has any security review been done? Is a commercial/permissive license available?
• Business question: do you actually need to be an IdP, or should this be delegated to Keycloak/Authentik/simpleSAMLphp?

Integration Approach

Stack fit: Runtime fit with Laravel is fine (plain PHP), but there is no Laravel idiom — no facade, no publishable config, no migrations. Treat it as a low-level engine and wrap it behind your own IdPService interface so it stays swappable.

Migration path: Do not displace an existing IdP (Okta/Entra/simpleSAMLphp) until parity is proven. Moving from simpleSAMLphp is a rewrite, not a migration — budget for re-issuing metadata, re-registering certs, and re-onboarding every SP. Starting greenfield is the only low-friction path.

Compatibility: Check for pinned/outdated transitive deps (xmlseclibs, robrichards, Symfony components) that conflict with your matrix. Expect to pin, and possibly fork, the library.

Sequencing:

1. Sandbox PoC against a known SP (local Shibboleth/simpleSAMLphp or SAMLtest.id) — prove SSO, metadata consumption, and signature validation end-to-end.
2. Build the Laravel adapter: provider, config, routes, user/attribute mapping, session integration.
3. Add key management, metadata rotation, structured SAML logging, and a break-glass local login.
4. Independent security review / pen test before any external SP trusts you.
5. Migrate production SPs one relying party at a time, with rollback.

Operational Impact

Maintenance: Effectively self-maintained. Zero stars/dependents means no community; assume you own the code and any security forks. GPL-3.0 adds legal overhead — modifications may need to be published if distributed.

Support: No vendor, no SLA, no CVE feed. XML-security library CVEs will land on your team, not a maintainer's.

Scaling: Signing/validation is CPU-cheap; scale is dominated by the shared session store (Redis) and user lookup. Horizontally scalable if sessions are centralized. The operational pain is certificate and metadata rotation, not throughput.

Failure modes: Expired or mismatched signing certs (the classic 3am page); clock skew invalidating assertions; canonicalization bugs that break signature validation for a subset of SPs; IdP- vs SP-initiated flow mismatches; audience/recipient restriction gaps enabling replay. XML errors are opaque — invest in SAML tracing and correlated logs up front.

Ramp-up: SAML is unforgiving. Expect 2–4 weeks before a mid-level engineer is productive, plus a tracing tool (browser extension or proxy). Given the near-zero adoption signal, the defensible TPM recommendation is a time-boxed spike benchmarking this against Keycloak/Authentik (off-the-shelf IdP) or simpleSAMLphp before committing to own it in-app.