Php Saml Laravel Package

Product Decisions This Supports

• Enterprise-readiness gate: SAML SSO is a recurring procurement checkbox for B2B/mid-market and enterprise buyers. This package lets you answer "do you support SAML?" with a scoped, low-cost build decision rather than an immediate buy decision.
• Build vs. buy for authentication: Frame the choice explicitly: (a) implement SAML SP in-house on top of onelogin/php-saml, (b) adopt a managed identity product (Okta/Auth0/WorkOS/Entra External ID), or (c) push SSO to a per-customer professional-services engagement. This library makes option (a) credible for a Laravel/PHP team, typically days-to-weeks of work rather than months.
• Feature scoping for SSO v1: The README gives a concrete capability menu to prioritize against customer demand — SP-initiated SSO, IdP-initiated SSO, Single Logout (SLO), assertion/NameID encryption, signed AuthNRequest/LogoutRequest/LogoutResponse, ACS and SLS endpoints, and signed SP metadata publication. Use these as line items in a requirements doc so Sales and Engineering agree on what "SAML support" means in the release.
• Integration-architecture decisions: Because the toolkit is session-less and delegates session handling to the host app, it fits cleanly behind a Laravel guard/controller flow. That supports a decision to keep SAML as an authentication adapter rather than letting it dictate your session, user model, or tenancy design.
• Multi-tenant / per-customer IdP roadmap: Supporting one IdP per customer (each with its own metadata, certificate, and entity ID) is the natural enterprise pattern. This package's array-based settings model supports that, which informs whether you invest in an admin UI for per-tenant IdP configuration.
• Security roadmap and compliance narrative: The changelog references a real CVE history (signature wrapping, XEE, xmlseclibs CVEs) and explicit hardening guidance (strict mode, non-SHA1 algorithms, certificate over fingerprint, RelayState validation, replay-attack ID tracking). That's useful raw material for a SOC 2 / security-review conversation and for deciding how much security engineering you must budget on top of the library.
• Prioritization signal from the field: If enterprise deals are stalling on SSO, this is a high-leverage, low-cost unblock. If SSO requests are rare and self-serve only, deprioritize and point customers at a hosted identity provider.

When to Consider This Package

Consider it when:

• You run a PHP/Laravel application and need to act as a SAML 2.0 Service Provider (SP) against customer-controlled IdPs (Okta, Entra ID, OneLogin, Ping, ADFS, Google Workspace).
• You need SP-initiated and IdP-initiated SSO, and likely Single Logout, without adopting a full identity platform.
• Your team wants a framework-agnostic, session-less library it can wrap in Laravel controllers/middleware rather than a package that owns your auth stack.
• You want MIT-licensed, Composer-installable code with no per-seat or per-MAU vendor cost, and you're comfortable owning the security posture.
• You need metadata publishing and certificate/key rollover support for enterprise onboarding.
• Your team has (or can borrow) someone who understands SAML assertions, signatures, and certificate handling — the library is a toolkit, not a turnkey product.

Look elsewhere when:

• You want a drop-in Laravel package with migrations, routes, an admin UI, and per-tenant IdP management — evaluate a maintained Laravel SAML wrapper on top of this library, or a commercial product, rather than wiring the toolkit directly.
• You need to be an Identity Provider, need SCIM provisioning, or need OIDC/social login — this package is SP-side SAML only; Socialite or a managed IdP covers those.
• Your only requirement is "log in with Google/Microsoft" for self-serve users — full SAML is overkill.
• You have no appetite for security ownership: SAML signature validation, replay prevention, open-redirect defense, and XML parsing hardening are on you. A managed identity vendor shifts that risk.
• Maintenance risk is unacceptable: versions are branch-based (2.x legacy, 3.x PHP 7.0–7.2, 4.x PHP 7.3+/8.x), the README carries a long list of past security patches, and adoption depends on tracking releases. If you can't commit to prompt upgrades, choose a managed service.
• You need first-class vendor support/SLA — this is community-maintained, MIT, with a security contact rather than a support contract.

How to Pitch It (Stakeholders)

To executives / leadership: Enterprise buyers increasingly require SAML SSO before signing. This is an MIT-licensed, widely used PHP toolkit that lets us ship SP-side SAML — SSO, single logout, encrypted assertions, signed metadata — in weeks, not quarters, and without per-seat identity vendor fees. It removes a common late-stage deal blocker and strengthens our security story (centralized auth, no app-managed passwords), while keeping the option open to move to a managed identity provider later if scale or compliance demands it. The trade-off is explicit: we own the security configuration and upgrade cadence.

To engineering: It's a mature, tested, session-less SAML 2.0 SP implementation installable via Composer. It exposes both high-level (OneLogin_Saml2_Auth) and low-level APIs, so we can wrap it in a Laravel guard and keep our own session and user model. We must budget for the hardening checklist up front: strict = true, non-SHA1 signature/digest algorithms, registered IdP certificates instead of fingerprints, RelayState allow-listing to prevent open redirects, and message/assertion ID tracking to prevent replay. Also budget for a settings-as-array approach (never config files under vendor/) and a dependency-upgrade habit, given the library's CVE history.

To sales / customer success: We can commit to SAML SSO for enterprise accounts with a defined scope (SP-initiated and IdP-initiated login, logout, per-customer IdP metadata and certificates). Onboarding becomes "send us your IdP metadata" instead of custom per-customer work, and centralized auth reduces password-reset support load and phishing exposure.