Onelogin Saml Bundle Laravel Package

Product Decisions This Supports

• Unblocking enterprise deals with an SSO requirement. SAML 2.0 support is a recurring checkbox in security questionnaires and procurement reviews (Okta, OneLogin, Microsoft Entra ID, Ping, JumpCloud, ADFS). A package that provides a working Service Provider implementation turns "SSO — roadmap" into "SSO — available," which frequently gates six-figure ACV contracts.
• Build vs. buy for the auth layer. This is a concrete data point for the "buy the protocol, build the product" call. SAML is a security-sensitive protocol with a long history of signature-wrapping and XML canonicalization vulnerabilities; using a maintained implementation instead of hand-rolling assertions, redirects, and signature validation is almost always the right trade. The decision left to the PM is whether to buy this library or a managed identity vendor.
• Tiering and packaging. SSO is a classic enterprise-tier feature. If this package lands the integration cheaply, it can be gated behind an "Enterprise" plan rather than sold as an add-on, simplifying the pricing page and improving attach on the top tier.
• Roadmap sequencing. Because the integration is a bundle-style drop-in rather than a months-long protocol project, it can be scheduled as a two-to-four sprint enabler ahead of a compliance push (SOC 2, ISO 27001, or a customer's annual vendor review) instead of competing with core roadmap items. New in v3.0.0: the bundle now targets Symfony 8.0, so sequencing has a framework-upgrade dependency — if the product is still on Symfony 6/7, either the auth work waits on the framework upgrade or it is pinned to the 2.1.x line.
• Compliance and audit posture. "Enterprise customers can enforce their own identity policy, MFA, and session lifetime" is a control that shows up in vendor security reviews. Adopting an IdP-delegated auth model shifts account lifecycle, deprovisioning, and password policy to the customer's IdP — which measurably shrinks your own compliance surface.
• Framework-fit decision (important caveat). This is a Symfony bundle, not a Laravel package. Laravel does not consume bundles — no bundle registration, no services.yaml extension model. So the PM decision this actually informs is "do we adopt this directly, or do we use the underlying onelogin/php-saml SDK wrapped in our own service provider / Socialite driver?" Do not let this appear in a Laravel roadmap as a drop-in dependency; it isn't one. The v3.0.0 release reinforces this: the headline change is Symfony framework wiring, which is precisely the layer Laravel cannot consume.

When to Consider This Package

Consider it when:

• The application is Symfony-based and needs SAML 2.0 Service Provider behavior — IdP-initiated or SP-initiated login, assertion attribute mapping, and logout — without a managed identity vendor in the loop.
• You are on, or are planning to be on, Symfony 8.x — v3.0.0 tracks the current framework major. For Symfony 6/7 estates, the 2.1.x line remains the relevant target until the framework upgrade lands.
• You want SSO inside your own perimeter: self-hosted or on-prem-adjacent deployments where customers will not accept an Auth0/WorkOS/Okta-style third-party broker holding their identity data.
• You need per-tenant IdP configuration (each enterprise customer brings their own metadata) and want a framework-native authenticator rather than gluing SAML into a custom middleware.
• Licensing and procurement friction matter: BSD-3-Clause is permissive, no commercial negotiation, no per-MAU pricing.
• The team is small and the alternative is spending engineering weeks on certificate rotation, metadata refresh, and signature validation edge cases.

Look elsewhere when:

• Laravel is the actual stack. Use onelogin/php-saml directly behind a service provider, or an established Laravel SAML2 driver, or Socialite plus a SAML provider. This bundle is the wrong shape for that app, and the 3.0 release is more Symfony-specific than its predecessor, not less.
• A single maintainer and a thin star/dependent footprint is too thin a bus factor for a revenue-critical auth path. Zero dependents means limited real-world hardening signal. Prefer the upstream SDK the bundle wraps, which has a broader maintainer base.
• You need OIDC, SCIM provisioning, or social login alongside SAML. A managed IdP (WorkOS, Auth0, Entra External ID, Keycloak if self-hosted) covers all three plus directory sync; this package does SAML only — a scope that v3.0.0 does not change.
• You want SSO as a product feature, not an integration. Managed vendors give you an admin portal, IdP metadata upload UX, and per-tenant configuration screens out of the box — the bundle does not.
• Timeline is under two weeks and no Symfony/SAML experience exists. Certificate and metadata misconfiguration is the single most common SAML support ticket; the library does not remove that operational tax.

Diligence item introduced by v3.0.0: the changelog lists only "Symfony 8.0 support," but the major version bump almost certainly carries a breaking minimum-version constraint (likely dropping older Symfony majors). The changelog does not enumerate removals, deprecations, or upgrade steps — confirm the composer.json Symfony constraint and any API changes against your codebase before scoping the spike.

How to Pitch It (Stakeholders)

For executives: SAML SSO is a gate on enterprise revenue. This package is a permissively licensed, actively maintained implementation that lets enterprise customers authenticate through their own identity provider — which is what their security teams require before signing. It is free, self-hosted, and keeps customer identity data out of a third-party broker, avoiding a new vendor and a new data-processing agreement. The new 3.0 release confirms the maintainer is alive and tracking Symfony's annual major releases, which is the signal we care about most for a single-maintainer dependency. The trade is operational: we own the configuration and the on-call for the auth path.

For engineering: This is a Symfony bundle wrapping the OneLogin PHP SAML toolkit — firewall-based authenticator, attribute mapping, multi-IdP metadata. v3.0.0 is a major bump whose only stated change is Symfony 8.0 support; treat the major version as a signal that Symfony 6/7 support may have been dropped and verify the Composer constraint before anything else. It is not installable in our Laravel services; for Laravel, plan on the underlying onelogin/php-saml SDK behind a service provider. Flag the maintenance profile: single primary maintainer, small star count, zero dependents, BSD-3-Clause — active, but thin. Recommend pinning (3.x for Symfony 8, 2.1.x otherwise), vendoring the upstream SDK where feasible, and writing integration tests around assertion validation and certificate rotation before this touches a paying customer's login flow.

The honest ask: approve a time-boxed spike to validate the integration against two real IdPs (Entra ID and Okta) on our target Symfony version, confirming the 3.0 compatibility matrix and that the maintenance risk is acceptable — or, if the risk isn't acceptable, approve budget for a managed identity vendor and treat this package as the fallback for self-hosted/on-prem customers only.