Lightsaml Idp Laravel Package

Product Decisions This Supports

• Enterprise SSO as an IdP (not an SP): This package makes your product the identity provider — you authenticate users and issue signed SAML assertions to third-party service providers (Salesforce, Slack, AWS, customer-built apps). This is the rarer half of the SSO market; most teams need the SP side and reach for onelogin/php-saml or lightsaml/lightsaml instead.
• Build vs. buy for identity: Gives engineering a credible in-house path for federation, to be weighed against managed providers (Okta, Auth0, WorkOS, OneLogin) and self-hosted options (Keycloak, SimpleSAMLphp).
• Roadmap sequencing — SAML vs. OIDC: A concrete datapoint for deciding whether SAML IdP capability belongs in the next two quarters or stays a "sales-blocked, revisit later" item. The honest default is: defer unless a specific deal or partner integration demands it.
• Packaging and pricing: Supports gating federation behind an Enterprise/SSO tier, since the cost is concentrated in security review, key management, and certificate rotation rather than in raw development.
• Deal unblocking: Directly addresses the "we can only buy if you support SAML federation with our identity stack" objection from large or regulated buyers.
• Procurement/compliance questionnaires: Informs security review answers around assertion signing, key custody, and metadata exchange.

When to Consider This Package

Consider it when:

• The stack is PHP/Laravel or Symfony and the team wants to stay in-language with no sidecar service.
• You specifically need to issue SAML assertions — partner integrations, a B2B portal acting as the customer's IdP, or white-label deployments where customers point their SPs at you.
• Self-hosted, on-prem, or air-gapped delivery is a requirement, ruling out SaaS identity vendors.
• Traffic is modest and latency budgets tolerate in-process XML signing.
• You have security engineering capacity to own XML canonicalization, signature validation, and key rotation — and you treat this as a starting library rather than a finished IdP.

Look elsewhere when:

• Licensing is a blocker. GPL-3.0 is copyleft: shipping an on-prem distribution of a proprietary product that links this in likely forces GPL obligations on the combined work. (SaaS-only, no distribution, is a materially different risk profile under GPLv3 — but this needs counsel, not a PM's judgment.) The wider lightSAML ecosystem's MIT licensing does not cover this package — verify file by file before assuming otherwise.
• You need the SP side. Wrong tool; use an MIT-licensed SP library or a managed provider.
• You need OIDC, SCIM provisioning, or OAuth2. This is SAML-only; modern buyers increasingly ask for OIDC first.
• Adoption signals matter. Zero stars and zero dependents means no external bug reports, no community CVE response, and no second pair of eyes on security-critical code. SAML implementations have a long history of XML signature-wrapping and assertion-injection flaws; an unreviewed implementation is a liability, not an asset.
• You need vendor SLAs, an audit trail, or a compliance attestation (SOC 2, ISO 27001) covering the identity layer.

Suggested gate before any commitment: a two-week spike that stands up metadata exchange, signed assertions, and key rotation against two real SPs, plus a parallel legal review of the license and a threat-model review of the signing path. Kill the initiative if either review is unfavorable.

How to Pitch It (Stakeholders)

To executives: Enterprise and regulated buyers routinely ask for SAML single sign-on, and a subset need us to act as their identity provider to close the deal. This package is a viable in-language building block for that capability and would let us ship federation without adding a vendor dependency or a new service to operate. Two caveats decide the business case: the license is GPL-3.0, which is a real constraint for any on-prem distribution of our product, and the library has essentially no community adoption, so we would own all security assurance ourselves. Recommendation: treat it as an option worth a short, bounded spike — not a committed roadmap item — and only proceed if a named customer or partner is blocked on it.

To engineering: This is the IdP half of SAML, in PHP. Expect to own the hardening: strict XML parsing, signature verification, certificate and metadata lifecycle, clock-skew and replay handling, and assertion expiry. Plan for a security review before first customer and a documented key-rotation runbook. If the team would rather not own protocol-level XML security, the alternative is a small Keycloak or Ory service behind our auth layer — more infrastructure, far less bespoke crypto.

To legal and security: GPL-3.0 applies to this package; confirm our distribution model and whether an on-prem build triggers copyleft obligations on our combined work. Security: no maintainer community, no disclosed CVE history to lean on, and a protocol area with known attack classes — we should assume full responsibility for code review rather than inheriting it.

Bottom line: A defensible bet only for a PHP shop that needs to act as a SAML IdP, can absorb the security work, and has cleared the license for its delivery model. Everyone else should buy or defer.