Oneloginsaml Bundle Laravel Package

Product Decisions This Supports

• Enterprise SSO as a roadmap item. SAML 2.0 login is a recurring gate in enterprise procurement. This package is a concrete, low-cost way to scope that work: it tells you what "SSO support" actually means in a Symfony codebase (IdP metadata, assertion consumer endpoint, attribute mapping, session handling) before committing it to a quarter.
• Build vs. buy for authentication. Framing the choice as "wire a SAML bundle ourselves" vs. "pay an identity vendor" (WorkOS, Auth0, OneLogin, FusionAuth). This package represents the self-hosted, MIT-licensed end of that spectrum — the cheapest option on paper and the most expensive in ongoing ownership.
• Framework fit check. It is a Symfony bundle, not a Laravel package. If the product is Laravel, this is not a drop-in and the decision becomes "adopt a Symfony-based auth layer," "use a Laravel-native SAML library," or "offload to a hosted IdP." That distinction should be settled before any engineering estimate.
• Supply-chain and maintenance risk register. Zero stars, zero dependents, and no visible downstream adoption means no de facto production track record. That belongs in a dependency-risk entry alongside the feature decision, not after it.
• IdP coverage scoping. OneLogin is the namesake, but SAML 2.0 is the protocol — the decision to support Okta, Entra ID, and Ping is largely config work once a compliant SP exists. This package helps you price "support the top 4 IdPs" honestly.
• Security questionnaire readiness. SOC 2 / ISO 27001 buyer questions around SSO, MFA delegation, and centralized deprovisioning land on the PM. Having a concrete auth architecture — even one you ultimately reject — makes those answers defensible.

When to Consider This Package

Adopt or prototype it when:

• The application is Symfony (or you are willing to run Symfony components inside a Laravel app), and the team already knows the framework.
• You need SAML SP-initiated login against a single IdP and nothing more — no SCIM, no multi-tenant per-customer IdP configuration, no advanced policy engine.
• Self-hosted identity is a requirement — data residency, air-gapped deployment, or a customer contract that forbids third-party auth processors.
• The MIT license matters: no per-MAU pricing, no vendor lock-in, no procurement cycle for an auth vendor.
• The blast radius is small: an internal tool, a pilot, or a single enterprise account whose contract justifies bespoke work.
• You have someone who can own it — a Symfony-fluent engineer who can read the bundle source, pin the version, and patch it if upstream goes quiet.

Look elsewhere when:

• The product is Laravel. The effort to bridge frameworks usually exceeds the cost of a Laravel-native SAML library or a hosted IdP. Do not treat this as a Laravel package.
• You need per-tenant IdP configuration — one SP per customer, metadata upload, certificate rotation. That is product surface area above what a thin bundle provides.
• Provisioning and deprovisioning are on the roadmap. SAML authenticates; it does not sync users. SCIM is a separate build or buy.
• You need a vendor SLA, security review artifacts, or a named support contact. Zero dependents means zero external pressure on maintenance — the maintenance risk is entirely yours.
• You want MFA policy, adaptive access, or audit-grade identity analytics. Those are IdP-side capabilities; a SAML SP just consumes the result.
• Engineering capacity is the binding constraint. A self-hosted auth path is a permanent ownership line item, not a one-time integration.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed component that lets us evaluate SAML single sign-on without signing an identity vendor contract. It directly addresses a checkbox that stalls enterprise deals — buyers routinely require SSO before they will deploy. The honest tradeoff: it has effectively no public adoption (0 stars, 0 dependents) and no support relationship, so we would own its maintenance. Recommendation is to treat it as a scoping prototype that produces a real architecture and estimate, not as a production commitment we make in this meeting. If SSO is a must-win for the next two enterprise renewals, compare it head-to-head against a hosted identity vendor on total cost of ownership — license plus engineer time plus opportunity cost — before choosing.

To engineering: This is a Symfony bundle wrapping OneLogin's SAML toolkit. It gives us a service provider implementation — metadata exchange, assertion consumption, attribute mapping — without writing XML signature validation ourselves, which is the part we should never write ourselves. Two caveats they need to weigh in: first, it is not a Laravel package, so if our stack is Laravel, the integration cost is higher than the README implies and we should evaluate a native alternative; second, the project shows no downstream usage, so we should pin a commit, review the SAML library it depends on, and plan for the possibility that we are the maintainers. Ask for a spike estimate that includes the identity provider side, certificate rotation, and test coverage for the failure paths — expired assertions, clock skew, unsigned responses — because those are where SAML integrations actually break.