Lightsaml Laravel Package

Product Decisions This Supports

• Enterprise SSO roadmap item. SAML 2.0 is the table-stakes gate for selling into mid-market/enterprise buyers who run Okta, Microsoft Entra ID (Azure AD), OneLogin, Google Workspace, or Ping. A library like this is the build-vs-buy shortcut for shipping "Sign in with your IdP" without reinventing XML canonicalization and signature validation.
• Feature scoping in the auth domain. Using the library forces explicit decisions about acting as SP (your app trusts the customer IdP) vs. IdP (you issue assertions — usually out of scope). LightSAML covers both directions in principle, so it's a prompt to define the enterprise auth surface (SP-initiated, IdP-initiated, JIT provisioning, attribute mapping, logout).
• Security posture and supply-chain risk. SAML is a security-critical dependency. Committing to a SAML library is a long-lived maintenance obligation — patches for XML signature-wrapping and XXE issues become your CVE response plan. This drives decisions about whether to pin, vendor, or staff an owner.
• Integration and support matrix. The library shapes which IdPs you can realistically support and test. That feeds GTM messaging ("SSO available on Enterprise tier"), pricing gating, and support load.
• Admin/self-serve tooling. SAML libraries typically require hand-tuning metadata, certificates, and attribute maps. Adoption of the library implies either building a self-serve IdP configuration UI or accepting a high-touch onboarding motion.
• Build vs. buy vs. outsource. Alternatives range from this library (light, self-owned) through SimpleSAMLphp (heavier, self-owned) to commercial SSO vendors (WorkOS, Auth0/Okta, Stytch) that sell the whole problem away. This package makes the "build the plumbing, keep the UX" option cheaper.

When to Consider This Package

Consider it when:

• You're on PHP (Laravel or otherwise) and need SAML 2.0 request/response construction, parsing, and signature validation without a commercial dependency.
• You want MIT-licensed code with no vendor lock-in and are prepared to own the code — pin a version, track advisories yourself, and audit the crypto paths.
• You need a composable lower-level SAML toolkit rather than a turnkey SSO product, e.g., custom attribute mapping, multi-tenant IdP metadata stores, or non-standard flows.
• You're already inside the mlightsaml namespace — this fork exists largely as a patched namespace vendored into an existing dependency tree. If a downstream package (historically Laravel SAML wrappers) pins mlightsaml/lightsaml, adopting it is a migration-avoidance decision, not a fresh one.

Look elsewhere when:

• You want community validation and active maintenance. This fork has 0 stars and 0 dependents. The upstream lightsaml/lightsaml is the canonical project; evaluate that instead, and only take this fork if you consciously need its patches. For any security-critical SAML work, an unreviewed fork is a red flag — you need proof of eyes on the code, not just compilable code.
• You need turnkey SP integration. onelogin/php-saml (and its successor lineage) is a more commonly deployed SP-focused option with better-documented attack mitigations; simplesamlphp/simplesamlphp is the standard if you also need to act as an IdP or run a federation proxy.
• You want vendor-backed support and SLAs. If enterprise SSO is a revenue-critical promise (uptime, CVE patch guarantees, IdP certification testing), buy from an SSO vendor rather than build on an unfunded OSS fork.
• You need audited/certified SAML profiles, SCIM provisioning, or MFA in the same product. These are usually better served by a dedicated identity vendor.
• You're on a non-PHP stack or want a hosted identity layer — this library is the wrong layer.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a lightweight, MIT-licensed SAML 2.0 library for PHP that lets us ship enterprise single sign-on — the feature enterprise buyers ask for before signing — without building cryptographic XML handling ourselves or paying a per-seat SSO vendor. It removes a build-vs-buy blocker and keeps the integration under our control at no license cost. The trade-off is ownership: SAML is security-critical, and this particular fork shows no community adoption (zero stars, zero dependents), so if we adopt it we must pin versions, treat it as internal code, and assign an owner for security patches. Recommendation: use it as a scoping tool for the SSO initiative, but make the go/no-go decision after comparing against the upstream lightsaml project, onelogin/php-saml, and a buy option — because "free library" still carries maintenance cost and CVE risk.

For engineering (one paragraph): LightSAML is a composer-installable, MIT-licensed toolkit for SAML 2.0: AuthnRequest/Response building and parsing, XML signature and certificate handling, metadata generation, and SP- and IdP-side abstractions. It's a lower-level library, not a Laravel SSO product — expect to build the controller flow, per-tenant IdP metadata store, attribute mapping, and logout handling yourself. The mlightsaml/lightsaml fork is unvalidated (0 stars, 0 dependents); before adopting, diff it against upstream lightsaml/lightsaml to understand what was patched and why, then treat signature validation and XML parsing as audit-critical code paths — signature-wrapping and XXE are the known failure modes for any SAML implementation. If we adopt, pin the version in composer.json, add it to our dependency-review process, and write integration tests against at least two IdP fixtures (Entra ID and Okta) before it ships in a customer-facing login.