Laravel Samlidp Laravel Package

Product Decisions This Supports

• Enterprise SSO as a feature, from the IdP side. This package makes your Laravel application the SAML Identity Provider — it authenticates users and issues assertions to third-party Service Providers. That directly enables the "your customers' employees log into partner/third-party tools with their account on your platform" motion, which is typically a paid-tier or enterprise-contract requirement rather than a core feature.
• Build vs. buy for identity. Informs whether to stand up a dedicated IdP (Okta, Entra ID, Auth0, WorkOS, FusionAuth) versus issuing assertions from the existing Laravel user store. Choosing the package means identity stays in your database with no per-MAU identity vendor cost; choosing a vendor buys you protocol breadth (OIDC, SCIM, admin UIs) and compliance artifacts you would otherwise have to produce.
• Roadmap sequencing for B2B/enterprise tiers. SAML IdP capability is usually a checkbox on an enterprise RFP. Knowing this package is a low-integration-effort path lets you schedule SSO into a release without a multi-quarter platform bet.
• Use cases worth validating: white-label partner portals, an internal IdP for a portfolio of first-party apps, marketplace/agency scenarios where your tenants need to federate their own users into vendor tools, and legacy SP integrations that only speak SAML 2.0.
• Explicit non-decision: this is not the right dependency if the goal is "let our users sign in with their company's Okta/Entra ID." That is the Service Provider direction and needs a different library. Confusing the two is the most common and most expensive scoping error here.

When to Consider This Package

Adopt when most of the following hold:

• Your Laravel app is already the system of record for user identity (you own credentials, sessions, and the user table), and you need to emit SAML assertions rather than consume them.
• You have a named, contracted integration — a specific SP (a vendor product, a partner portal, an internal legacy app) that requires SAML 2.0 and will not accept OIDC or a shared session.
• Volume is modest and the tenant set is known. You can absorb the per-connection configuration work (entity IDs, certificates, ACS URLs, attribute mapping) as an implementation task, not a self-service product.
• You can own key management and certificate rotation — signing certs, expiry monitoring, and a re-issuance runbook. This is operational debt the package does not remove.
• Laravel 13.x compatibility matters to your upgrade calendar. v5.4.0 is a compatibility release that keeps the package viable on the current framework line. Treat it as a signal that the package is maintained, not as a feature delivery — it changes nothing about capability or API surface. If you are still on Laravel 11/12, this release is a no-op for you; if you are planning a 13 upgrade, it removes a blocker.

Look elsewhere when:

• You need to consume SAML (be the SP) — use a SP-oriented library.
• You need OIDC/OAuth2, SCIM provisioning, or admin self-service SSO configuration. A commercial identity vendor is the honest answer; bolting those onto this package is a build project disguised as a dependency.
• You have high connection counts or self-service onboarding requirements, where per-tenant certificate and metadata management becomes a product surface.
• You need certification, audit reports, or a vendor SLA to satisfy a customer's security review. A community-maintained package will not clear that gate regardless of code quality.
• You need active, first-party maintenance guarantees. Assess the maintenance posture and fork history before committing; pin the version and be prepared to own patches.

How to Pitch It (Stakeholders)

To executives: This is a small, focused dependency that lets our existing Laravel application act as an identity provider, so users authenticated in our product can sign into partner and third-party tools via enterprise-standard SAML SSO. It converts an enterprise-contract checkbox into an engineering task measured in days rather than a platform initiative. It carries no per-user licensing cost, which is the main economic argument against routing the same need through a commercial identity vendor. The tradeoff is that we own certificate lifecycle and that it does not extend to OIDC or automated user provisioning — those remain separate decisions. The v5.4.0 release is maintenance only: it confirms Laravel 13 compatibility, which de-risks our framework upgrade path but adds no new capability.

To engineering: The package is the IdP half of SAML only — do not scope it against SP-side requirements. v5.4.0 contains a single change, Laravel 13.x support; there is no API change, so no migration work beyond the framework upgrade itself. Budget explicitly for signing-certificate storage and rotation, attribute-mapping configuration per SP, and an integration test harness against at least one real SP, since SAML failures are typically metadata and clock-skew issues rather than code defects. Pin the dependency and review upstream maintenance activity each release cycle before assuming it will keep pace with future Laravel versions.