Laravel Saml Laravel Package

Product Decisions This Supports

• Enterprise SSO as a sellable capability: Adds SAML 2.0 Service Provider support to a Laravel app, enabling the "log in with Okta/Entra ID/Google Workspace/OneLogin" requirement that gates most B2B and enterprise deals. This is a feature decision, not an infrastructure detail.
• Build vs. buy: A mature, dependency-light SP implementation removes weeks of custom XML-signature, assertion-validation, and logout-flow work. Choosing this package keeps the team building product instead of maintaining crypto and protocol edge cases.
• Security/compliance roadmap inputs: Strict validation, signing requirements, and tampered/unsigned response rejection map directly to SOC 2 / ISO 27001 questionnaire answers and enterprise security review checklists.
• Migration planning signal: v2.0.0 hard-requires PHP 8.3+ and Laravel 13.x. This ties the SSO feature to the platform-upgrade roadmap — teams on Laravel 9–12 must either defer the upgrade or pin to 1.x, which is a sequencing decision for the PM, not just engineering.
• Support and incident-response posture: The release preserves the original Error/TypeError on SAML response and logout failures instead of masking it with a secondary TypeError. That materially shortens time-to-diagnosis for customer-facing login outages, which is a support-cost and SLA decision.
• Use-case coverage to validate against real customers: SP-initiated login, metadata publishing, signed-response acceptance, and logout (SLS) are exercised; PMs should confirm which flows (IdP-initiated, SLO enforcement, multi-tenant per-IdP config) are actually on the near-term roadmap.

When to Consider This Package

Consider it when:

• You are on Laravel 13.x with PHP 8.3+ (8.3, 8.4, and 8.5 are all validated by the release), and enterprise customers or internal IT require SAML-based SSO.
• You need a conventional Service Provider: metadata endpoint, ACS/SLS routes, configurable IdP certificates, signed-assertion validation, and request-ID matching.
• You want the SSO surface to remain a configuration concern (existing config keys and SAML APIs are preserved in 2.0.0), so per-customer IdP onboarding is not a code change.
• Your security bar demands explicit rejection of unsigned/tampered responses and strict validation by default — the package's defaults align with that, and the new tests document it.
• You are willing to own the final verification step: no live IdP integration test was performed in CI, so a manual login/assertion/logout pass against each customer IdP is a required part of your rollout checklist, not an optional one.

Look elsewhere or wait when:

• You are on Laravel 9–12: stay on the 1.x line. Adopting 2.0.0 is blocked until the framework upgrade lands — treat this as a dependency, not a shortcut.
• You need OIDC/OAuth as the primary protocol, or multi-protocol abstraction across many providers — a dedicated identity broker or hosted IdP (Auth0, WorkOS, Keycloak) will be a better fit than a protocol-specific package.
• You need SCIM provisioning, advanced IdP-initiated flows, or per-tenant policy engines out of the box; verify coverage before committing, as these are outside the tested surface described here.
• You require vendor-backed SLAs or live integration test evidence in CI — the release notes are explicit that IdP testing was manual/absent, so the integration risk sits with you.
• Your team has no appetite for major-version tracking: 2.0.0 is a hard platform-floor bump with a documented upgrade guide. If you cannot absorb that cadence, a hosted identity service shifts the maintenance burden off your team.

How to Pitch It (Stakeholders)

For executives: Enterprise buyers increasingly refuse to approve vendors without SAML SSO. This package gets us that checkbox on a maintained, security-reviewed foundation rather than a bespoke implementation, and it is the piece that unblocks enterprise-tier deals. The trade-off is a hard platform dependency: version 2.0.0 requires PHP 8.3+ and Laravel 13, so SSO availability is now coupled to our framework-upgrade timeline. If we are still on Laravel 9–12, we can ship SSO today on the 1.x line and revisit 2.0.0 with the platform upgrade — the customer-facing capability is not blocked either way.

For engineering: Adopt 2.0.0 when you are on Laravel 13 / PHP 8.3+. Read the upgrade guide first; keep IdP certificates, strict validation, signing requirements, and your ACS/SLS routes and middleware unchanged — the release explicitly preserves existing SAML APIs, config keys, security defaults, and logout behavior, so this should be a dependency-and-platform change rather than a rewrite. Two concrete wins: explicit IdP settings no longer incorrectly invoke the configuration resolver, and SAML/logout failures now surface the original Error/TypeError instead of being masked by a secondary TypeError — meaningfully better production diagnosability. The test suite went from a placeholder to real coverage (provider, metadata, login/logout, authentication, signed-response acceptance, unsigned/tampered rejection, request-ID mismatch), with 26 tests passing across PHP 8.3/8.4/8.5 on highest dependencies and on lowest secure dependencies, plus style, strict Composer validation, platform checks, and advisory audits.

Known gap to plan around, not to hide: CI does not exercise a live identity provider. Budget an explicit verification step — test login, assertion validation, and logout against each customer's IdP — in the rollout plan and in the on-call runbook. Treat that as the acceptance criterion for the SSO launch, not as a formality.