Lightsaml Lightsaml Laravel Package

Product Decisions This Supports

• Enterprise SSO / "Login with Okta, Azure AD, OneLogin": SAML 2.0 service-provider support is a recurring gate for B2B and enterprise-tier deals. This package covers the protocol primitives (AuthnRequest generation, Response/Assertion parsing, signature validation, metadata handling) needed to evaluate that capability.
• Build vs. buy for identity: Use it to frame the decision — SAML is commodity plumbing, not differentiation. The realistic options are (a) a maintained PHP library, (b) a managed identity/SSO vendor, or (c) owning a fork. This package is evidence for (c) only if you explicitly staff it.
• Roadmap sequencing for an enterprise tier: Helps size the "SSO + SCIM + audit logs" bundle. SAML is usually the first enterprise checkbox; knowing the SP-side scope (metadata exchange, assertion validation, logout) informs whether SSO ships in one sprint or a quarter.
• Use cases it supports well: SP-initiated SSO for a Laravel app, consuming IdP metadata, validating signed assertions, attribute mapping to local users/roles, and single logout. It does not position you to build an IdP or a compliance-certified identity platform.
• Risk/portfolio decision: A 0-star, last-released-2017 fork of an abandoned library is a signal to not make it a strategic dependency. The PM decision it best supports is "budget for a maintained alternative or a managed service," not "adopt this."

When to Consider This Package

Consider it only when:

• You are inheriting a legacy PHP/Laravel app already built on LightSAML and need a namespaced fork to patch a specific issue while you plan migration.
• You need a throwaway spike or proof-of-concept to validate a SAML SP flow before committing to a vendor or a maintained library.
• You are prepared to own the fork: pin it, vendor it, add security review, and accept that upstream fixes will not arrive.

Look elsewhere when:

• New production build — this is a 2017-era fork with no stars, no dependents, and no recent releases; it will not receive security patches for a security-critical protocol.
• You need PHP 8+ compatibility, modern crypto defaults, or active CVE response — the abandoned lineage means you inherit the maintenance burden.
• You need an IdP, SCIM, or compliance attestations — out of scope.
• You want a supported path — evaluate maintained PHP SAML libraries (e.g., OneLogin's php-saml, SimpleSAMLphp) or a managed SSO service, and compare total cost of ownership including security response.

How to Pitch It (Stakeholders)

To executives: SAML SSO is table stakes for enterprise deals, but this specific package is an unmaintained 2017 fork of an abandoned library. It is fine as a reference or a short spike, but it is not a dependency we should ship on. The ask is a small budget line: either a maintained library or a managed SSO vendor. Choosing this package to "save money" shifts security-patch risk onto us — the expensive option.

To engineering: Treat this as a starting point, not a dependency. If we touch it, we fork, pin, and own it: security review of signature validation, test coverage for assertion replay/expiry, and a migration plan. Spike cost is low; production cost of ownership is real. Recommend a time-boxed evaluation against a maintained alternative before committing.