Lightsaml Laravel Package

Product Decisions This Supports

• Enterprise SSO / B2B Federation roadmap: Justifies scoping SAML 2.0 as a first-class auth path for enterprise and partner customers. The package covers the full SAML 2.0 data model (AuthnRequest, Response, Assertion, LogoutRequest, metadata) plus HTTP-Redirect and HTTP-POST bindings — enough to ship SP-initiated SSO, IdP-initiated SSO, SLO, and metadata exchange without inventing a protocol layer.
• Build vs. buy for identity: A defensible "build on OSS" position. MIT license, no per-connection or per-MAU fees, no vendor lock-in, and the code path that validates signatures is inspectable and auditable — which matters if you sell into regulated buyers who ask "how do you verify assertions?" A commercial SAML vendor buys you support and speed; this buys you control and zero licensing drag.
• Security posture and compliance commitments: The 5.x/6.x line gives concrete, citable controls rather than marketing claims: XML Signature Wrapping (XSW) rejection (5.0.1), duplicate/absent assertion ID rejection (5.1.0), SHA-256 as the default signing algorithm instead of SHA-1 (4.7.0), and 6.1.0 stopping implicit rsa-sha1 signing on SHA-1-issued certificates. These map directly to SOC 2 / ISO 27001 audit questions about weak-hash signing and assertion-forgery defenses — useful ammunition for security questionnaires and renewal negotiations.
• Partner interoperability as a sales unblocker, with a known boundary: 6.1.0 supports RSA certificates issued by ECDSA or other non-RSA CAs and no longer crashes on MD5-issued certificates, converting "we can't connect to this customer's IdP" from an engineering escalation into a configuration task. The boundary is now explicit rather than a crash: EC/EdDSA certificate keys are rejected with Unsupported certificate public key type, even when issued by an RSA CA. That is a qualification question for sales engineering ("does your IdP sign with an RSA key?") that should sit in the deal-desk checklist, not a surprise discovered during onboarding.
• Predictable signing behaviour under heterogeneous PKI: 6.1.0 makes algorithm negotiation deterministic — the credential store inherits the issuer's algorithm only when it is RSA-SHA256/384/512, and otherwise falls back to RSA-SHA256. For product planning this means we can state a single default posture in our security documentation and only document exceptions for partners who legitimately require SHA-384/512, rather than reasoning per-tenant about inherited weak defaults.
• Security introspection as an operational feature: The new X509Certificate::getPublicKeyType() gives us a supported way to inspect a partner's certificate before wiring it into a trust store. That underpins a pre-flight "test connection" or metadata-validation step in an admin UI — a product surface we can build on a stable API instead of parsing certificates ourselves.
• Platform modernization planning: The 5.0.0 line requires PHP 8.4 and PSR-7 interfaces, and dropped the Symfony http-foundation coupling. That's a roadmap dependency: adopting or upgrading this package forces a decision on your PHP runtime baseline and HTTP abstraction. Sequence it with your framework upgrade, not against it.
• API surface decision — raw vs. wrapper: The package is deliberately low-level. The README itself recommends litesaml/saml (ServiceProviderWrapper / IdentityProviderWrapper) for higher-level integration. That is a scoping decision: do you want your engineers owning assertion validation logic (control, flexibility) or a thin wrapper (speed, fewer footguns)?
• Use cases where it fits cleanly: SP-side SSO against customer IdPs; multi-tenant federation where each tenant brings its own metadata and certificates; custom assertion validation rules (audience, NotBefore/NotOnOrAfter, InResponseTo correlation); encrypted assertions; and internal admin/partner portals where the SAML layer is infrastructure, not a product surface.

When to Consider This Package

Consider it when:

• You are on PHP 8.4+ (or willing to make that your baseline) and use PSR-7 request/response objects. On older PHP or heavy Symfony http-foundation coupling, 4.x is the ceiling and you inherit a weaker security baseline.
• You need protocol-level control: non-standard partner IdPs, custom signature/encryption policy, custom certificate stores, or assertion validation rules that off-the-shelf plugins won't express.
• You have in-house SAML or security expertise and are willing to own the security-patching cadence — tracking CVE-adjacent releases like 5.0.1 and 5.1.0 is now part of your job, not a vendor's.
• Your partner population signs with RSA keys (the overwhelmingly common case). 6.1.0 widened issuer compatibility (ECDSA/MD5 CAs, non-RSA issuers) but deliberately narrowed leaf-key support: EC certificate keys are rejected outright. If a target account mandates EC-signed assertions, this package cannot serve them today — qualify that before it enters a contract.
• You want a small, auditable dependency rather than a framework plugin that pulls in a large transitive tree. Note the maintainers have actively shed dependencies (Monolog, dom-crawler, Pimple, Symfony http-foundation).
• You need metadata generation/consumption and both redirect and POST bindings as primitives, and you're comfortable composing the flows yourself.
• You are building an SP, or an IdP with modest requirements — not a full federation product.

Look elsewhere when:

• You want plug-and-play: use litesaml/saml on top of this, or a full-stack bundle/plugin. Going straight to the data model means writing binding handlers, state management, replay protection, and error UX yourself.
• You need EC/EdDSA signing keys on the IdP side, or a partner insists on a non-RSA key algorithm. The rejection is explicit and safe, but it is still a hard no.
• Adoption signal matters to your risk model: ~109 GitHub stars and no listed dependents is thin. You will be one of very few public consumers, which means fewer field-tested edge cases and less community Stack Overflow coverage. Budget for reading the cookbook and the source.
• You need a commercial SLA, indemnity, or 24/7 support — for a security-critical auth path with an auditor asking questions, a vendor contract may be the cheaper answer.
• Your team has no SAML experience. The spec is unforgiving and mistakes here are auth bypasses, not bugs. The XSW vulnerability class is exactly the trap a low-level library exposes you to if you misuse it.
• You need OIDC/Social login in the same abstraction, or a managed IdP with admin UI, user provisioning (SCIM), and policy dashboards. This is a toolkit, not an identity platform.
• You need turnkey metadata onboarding UX for self-serve customers — you'd be building that layer regardless.

How to Pitch It (Stakeholders)

For executives: This is a mature, MIT-licensed PHP library that lets us add enterprise SAML single sign-on without per-seat licensing or vendor lock-in. It's actively maintained — recent releases have closed real, published security gaps (assertion-forgery via XML Signature Wrapping, weak SHA-1 signing defaults), and the latest one hardens certificate handling so partner onboarding no longer depends on our engineers reverse-engineering each customer's PKI. The maintainers keep tightening defaults rather than shipping and forgetting, which is the behaviour you want in an auth dependency. The trade-off is honest: it is a low-level component, not a product. We get control and auditability; we pay for it in engineering time to build the integration layer around it. One known limit worth flagging to sales: partners who sign with non-RSA (elliptic-curve) certificates aren't supported — rare, but we should qualify it early in enterprise deals. If we later decide to buy instead, nothing about this choice traps us, because the protocol artifacts (metadata, certificates, assertions) are portable.

For engineering: Adopt litesaml/lightsaml as the SAML protocol engine, not as our integration. Use litesaml/saml's ServiceProviderWrapper for the happy path and drop to the data model only where we need custom validation. Two hard constraints: PHP 8.4 is the floor, and bindings are PSR-7 — plan this alongside the runtime upgrade. We own three things the library deliberately does not: request/response correlation state and replay protection, certificate rotation and trust-store management, and user-facing error handling when a partner IdP misbehaves. Two 6.1.0 details to bake into our config and runbook: signing algorithm is now inherited from the issuer only for RSA-SHA256/384/512 and otherwise forced to RSA-SHA256 (so audit what we actually emit per tenant rather than assuming), and certificate key type is enforced — use X509Certificate::getPublicKeyType() in our onboarding validation to fail fast with a clear message instead of at assertion time. Verify our configuration actually enforces the 5.0.1+ XSW checks before we sign anything in production, and pin versions with a tested upgrade path — security releases here have been breaking (5.0.0), so we treat minor bumps as reviewable changes, not routine updates. 6.1.0 is additive with a documented behaviour change, so it's a safe bump, but re-test any tenant whose IdP certificate chain is unusual.