Sp Bundle Laravel Package

Product Decisions This Supports

• Roadmap: "SSO as a feature" for B2B. Enterprise buyers routinely require SAML2 SSO (Okta, Azure AD/Entra, Ping, OneLogin, ADFS) before signing. This package informs the build/buy decision for that capability on a Symfony/PHP stack.
• Build vs. buy vs. wrap. javer/sp-bundle is a thin Symfony integration layer over the LightSAML SP library. The PM decision is really three-way: (a) build SAML SP in-house on a library, (b) adopt a maintained bundle, or (c) outsource to an IdaaS (WorkOS, Auth0, Stytch, Frontegg) that abstracts SAML and SCIM. This package is the "wrap a library" option and should be priced against the others on maintenance cost, not just license.
• Feature scope decisions. What "SSO support" must include: SP-initiated and IdP-initiated flows, metadata exchange, signed assertions/encryption, Single Logout, and per-tenant IdP configuration (multi-tenancy). The bundle gives you the plumbing for the auth exchange but does not solve tenant config management, SCIM provisioning, or admin UX — those remain product work.
• Use-case triage. Reasonable fit for internal tools, admin back-offices, partner portals, or an MVP demo of SSO to unblock a pilot. Poor fit as the foundation of a paid, SLA-backed enterprise tier.
• Risk register input. With 1 star, 0 dependents, and a single maintainer, community backstop and CVE-response guarantees remain absent. Release 2.1.0 (Symfony 7 support, PHP 8.1 floor, CI refresh) is a positive maintenance signal that reduces — but does not eliminate — abandonment risk: it shows the maintainer tracks the ecosystem, yet it ships no features and no security fixes, and does not change the bus factor of one. Treat it as low-activity, still-viable for non-critical paths rather than actively supported.
• Platform currency. The 2.1.0 bump moves the supported floor to PHP 8.1 / Symfony 7, which is now a gating criterion for any app on modern framework versions — and a forced upgrade for anyone on PHP 8.0 or Symfony 5/6 who wants the 2.1.x line.

When to Consider This Package

Consider it when:

• The stack is Symfony 7 / PHP 8.1+ (or you can stay pinned to an earlier 2.x line on older platforms) and the team is comfortable reading and patching library code.
• The need is internal, low-blast-radius, or a proof-of-concept — you can absorb a breaking change or fork it without a customer-facing incident.
• You want a thin reference implementation of SAML SP wiring in modern Symfony to learn from or fork, rather than a vendor dependency. The 2.1.0 release makes it a considerably more useful reference than it was in January 2024, since it now demonstrates wiring against a current framework version.
• You're not subject to a compliance regime (SOC 2, HIPAA, FedRAMP) that requires a supported, patched auth dependency.

Look elsewhere when:

• Production enterprise SSO with contractual SLAs is the goal — the adoption signals (1 star, 0 dependents) still fail any reasonable due-diligence bar, and a CI/dependency refresh does not constitute a support commitment. Prefer onelogin/php-saml (php-saml), actively maintained SAML SP bundles such as nbgrp/saml-sp-bundle, or an IDaaS that gives you SSO + SCIM + admin UI out of the box.
• You need SCIM provisioning, per-tenant IdP self-service, or admin dashboards — none of that lives in an SP bundle; it's product surface you'll build regardless.
• The team lacks SAML depth and would be debugging XML signatures and clock skew in production.
• Your app is pinned below PHP 8.1 or above Symfony 7's support window in either direction — the release cadence here is slow enough (roughly a year-plus between releases) that you should assume you may need to fork to track fast-moving platform versions.
• OIDC-only satisfies your buyers — a much smaller, better-supported surface than SAML.

How to Pitch It (Stakeholders)

Bottom line: javer/sp-bundle is an MIT-licensed, lightweight Symfony bundle for the Service Provider side of SAML2. Release 2.1.0 (Symfony 7 support, PHP 8.1 minimum, CI updates) confirms the project is still alive and tracking the framework — a meaningful improvement over the "last touched January 2024" picture. But it is a maintenance refresh, not a maturity step: still 1 GitHub star, 0 dependents, a single maintainer, no feature or security content, and no support contract. It remains unsuitable as the backbone of a customer-facing enterprise SSO offering. For executives: the strategic decision is buy vs. build enterprise SSO, not which bundle; a buy (IDaaS) gets you SAML, SCIM, and admin UX with support, while building on a low-traffic bundle trades license cost for ongoing engineering and incident risk. For engineering: if we adopt or fork it, pin the version, own the LightSAML dependency, budget for the PHP 8.1/Symfony 7 upgrade path, and treat it as vendored code rather than a community-supported dependency. Recommended path: use it for internal/POC needs and as a current-framework reference implementation; for the product roadmap, evaluate a maintained SAML library or IDaaS and revisit in the next planning cycle — the 2.1.0 release is grounds for downgrading it from "unmaintained-adjacent" to "low-activity," not for promoting it to critical-path.