Oneloginsaml Bundle Laravel Package

Product Decisions This Supports

• "Do we offer enterprise SSO?" — the gating feature decision. SAML 2.0 single sign-on is table-stakes procurement criteria for mid-market and enterprise buyers. This package represents the capability of making a Symfony/PHP app act as a SAML Service Provider (SP) against Okta, OneLogin, Entra/Azure AD, ADFS, or Google Workspace — the checkbox that unblocks security reviews and deals.
• Build vs. buy, resolved toward "adopt the protocol library." SAML is full of trapdoors: XML canonicalization, signature validation, assertion encryption, replay protection, clock-skew tolerance, SP- vs IdP-initiated flows. This package delegates that to the mature onelogin/php-saml toolkit and only wires it into the framework. The PM decision is to not fund a bespoke SAML implementation; consume the proven cryptography layer.
• Roadmap placement. Best framed as a gated enterprise/SSO tier or an advanced-security add-on — a sales enabler, not a headline differentiator. It also implies downstream product work: IdP metadata upload UI, configurable attribute mapping, per-tenant IdP configuration, and just-in-time (JIT) vs. pre-provisioned user provisioning as an explicit policy choice.
• Compliance posture. SAML SSO with signed assertions strengthens the access-control narrative for SOC 2 / ISO 27001 conversations and reduces password-based account risk for enterprise tenants — a concrete control auditors can point to.
• Stack-fit decision that reframes the whole evaluation. Despite being filed under "Laravel/PHP," this is a Symfony bundle — it is not usable in a Laravel app as-is. For a Laravel team the real decision is whether to adopt the framework-agnostic onelogin/php-saml library directly (or via a maintained Laravel wrapper). This distinction should set the evaluation scope before any engineering time is spent.
• Adoption-signal caveat that shapes risk. Near-zero stars and 0 dependents mark this as a low-visibility fork rather than a widely used distribution. The decision should center on the upstream toolkit plus a maintained upstream bundle/wrapper — treat this artifact as a reference implementation, not a dependency commitment.

When to Consider This Package

Consider it when:

• You run a Symfony application (this bundle is Symfony-specific — verify supported Symfony versions) and need SAML SP functionality on a reasonable timeline.
• Enterprise or regulated customers are actively requesting SSO and it's blocking deals or renewals.
• Your team is comfortable owning the integration layer around a community-maintained dependency — IdP metadata config, certificate rotation, attribute mapping.
• You want to avoid building SAML cryptography and protocol handling in-house.
• You're standardizing on the OneLogin php-saml toolkit and need minimal framework glue rather than a managed identity vendor.

Look elsewhere when:

• Your stack is Laravel — this bundle does not apply. Evaluate onelogin/php-saml directly or a maintained Laravel SAML package; don't adopt a framework-mismatched dependency.
• You also need OIDC, social login, or SCIM provisioning — a pure-SAML SP bundle leaves those gaps; a managed identity provider (WorkOS, Auth0, Stytch) or a broader package may be more economical.
• You need to act as an IdP — this is SP-only.
• Maintenance and supply-chain risk are unacceptable. A fork with no dependents raises questions about update cadence, security patching, and long-term ownership. Prefer the actively maintained upstream bundle or a vendor-backed SDK, and require an audit of the underlying php-saml version and CVE history.
• SSO is a core differentiator rather than table stakes — deeper custom flows may justify in-house work or a dedicated identity platform.

Adoption criteria to apply before committing: supported framework versions, release cadence and maintainer activity, test coverage of both SP- and IdP-initiated flows, CVE/patch history of the underlying toolkit, license compatibility, and whether the fork has diverged from upstream in ways that complicate upgrades.

How to Pitch It (Stakeholders)

To executives: Enterprise buyers increasingly treat SSO as a prerequisite, not a feature. A SAML SP integration unblocks procurement cycles and strengthens our security story for compliance reviews. The protocol layer is a solved problem in the PHP ecosystem, so this is primarily an integration and configuration effort rather than a multi-month build — but our package choice needs diligence, since the specific fork we're looking at has minimal adoption and the well-maintained asset is the underlying OneLogin toolkit.

To engineering: This is a Symfony bundle around OneLogin's proven php-saml library, so the hard cryptography and protocol work is delegated. That said, the bundle itself is a thin, low-adoption fork — plan to pin and monitor the underlying php-saml version, and budget for certificate rotation, metadata handling, IdP-specific attribute quirks, and testing both SP- and IdP-initiated flows with mocked IdP fixtures. If our target application is Laravel, this bundle is the wrong dependency and we should scope around the framework-agnostic library or a maintained Laravel wrapper instead.

To security/compliance: Adopting SAML 2.0 with signed assertions and encrypted responses materially improves our identity and access posture and gives auditors a concrete control around centralized authentication and deprovisioning. Condition adoption on tracking upstream security releases and having a documented upgrade path for the toolkit.

Bottom line for the decision meeting: The capability is strategically worthwhile; this specific artifact is a low-signal, framework-mismatched fork. Approve the SSO initiative, and direct engineering to validate the correct framework-appropriate dependency — an actively maintained Symfony bundle or a Laravel SAML solution backed by onelogin/php-saml — before committing to this package.