Sp Bundle Laravel Package

Product Decisions This Supports

• Enterprise tier gating (highest-leverage use): SAML2 SP support is the checkbox that unlocks deals with buyers running Okta, Azure AD/Entra, Ping, or OneLogin. This package is the concrete shape of that feature: SP metadata endpoint, ACS/assertion consumer, IdP-initiated and SP-initiated flows, signed assertion validation, attribute mapping to local users.
• Roadmap sequencing for SSO: Reading its bundle structure clarifies the real workstream — not "add SAML," but metadata exchange with customers, per-tenant IdP config storage, attribute/role mapping, JIT user provisioning, and certificate rotation. Those are the items that actually consume engineering time; the protocol library is the small part.
• Build vs. buy framing: The package supports a "buy the protocol, don't build it" conclusion — nobody should hand-roll XML-DSig or assertion parsing. But it also supports a second buy decision: whether to buy the whole SSO surface (WorkOS, Auth0/Okta, Scalekit, Descope) rather than operate SP infrastructure yourself. Owning an SP means owning a security-critical, always-on auth path.
• Use-case scoping: Useful as a requirements checklist for B2B customer onboarding — which IdPs must be supported, whether IdP-initiated is required (common with legacy enterprise portals), whether SCIM is in scope, whether multiple IdPs per tenant is needed (it is, for enterprise).
• Prior art, not a dependency: Its value to us is as a reference implementation of LightSAML wiring in a PHP framework. It informs effort estimates; it should not inform the technology choice.

When to Consider This Package

Consider it only if all of the following hold:

• The target application is Symfony, not Laravel. This is a Symfony bundle (SpBundle, DI extension, bundle config tree). In a Laravel codebase it contributes essentially nothing usable — no service provider, no config publishing, no facade. At best its Security/ and Entity/ classes are readable as a spec.
• You are already committed to lightsaml/lightsaml as the core protocol library, so the bundle is a thin integration layer rather than a second dependency to vet.
• The IdP set is small, known, and stable, and you have in-house capability to fork and patch security-critical code yourself.
• You can pin to the PHP/Symfony versions it supports. The 1.2.1 release adds Symfony 4.1 compatibility only — a framework line that reached end-of-life in January 2020 — so this is a compatibility widening, not a modernization. You would still be constrained to a decade-old Symfony/PHP baseline and accept that on your platform upgrade path.

Look elsewhere — decisively — when any of these are true:

• Laravel target. Evaluate 24slides/laravel-saml2, aacotroneo/laravel-saml2 (also stale — vet carefully), or call onelogin/php-saml / python3-saml-style toolkits directly. On the Symfony side, nbgrp/onelogin-saml-bundle and hslavich/oneloginsaml-bundle are the live-ish alternatives.
• Maintenance signal matters. 64 stars, 0 dependents, and a 1.2.1 release whose entire changelog is a bump to a since-EOL Symfony version. That is not a maintenance signal — it is evidence that the project's ceiling is framework-compatibility patches, with no realistic CVE response path. SAML implementations are a well-known target for XML Signature Wrapping, comment-truncation, and XXE classes of attack; an unpatchable SP is an audit finding, not a convenience.
• You need modern IdP features — per-tenant metadata, encrypted assertions, SLO, SCIM, or IdP-initiated flows with strict replay protection. Expect to build these yourself on top.
• Compliance is in the sales path (SOC 2, ISO 27001, enterprise security questionnaires). A dormant auth dependency will be flagged in vendor review and will cost you more in security-review cycles than it saves.
• You want time-to-market. The buy-the-SSO-provider route is days; operating your own SP against arbitrary customer IdPs is a quarter-plus and an on-call burden.

Net PM read: 1.2.1 does not move the needle. A single-line changelog adding support for a Symfony version that has itself been unsupported for years confirms the earlier characterization rather than revising it. Score 12.3 with opportunity 40.6 still reflects a package that is conceptually relevant (SSO is a real revenue lever) but operationally dead. Treat it as documentation.

How to Pitch It (Stakeholders)

To executives: Enterprise buyers consistently require SAML-based SSO before they will sign, and it's frequently a gating item in security review rather than a nice-to-have. The capability is strategically important; this specific package is not the way to get it. It is a Symfony-only integration layer whose most recent release (1.2.1) consists solely of adding compatibility with Symfony 4.1 — a framework version that has been end-of-life since 2020 — and it still has no downstream dependents. Recommendation: commit to SSO on the roadmap, but fund it either as (a) a buy from a managed identity vendor, which gets us multi-IdP support, SCIM, and audit logging in weeks, or (b) a build on a maintained protocol library with a named owner for security patching. What we should not do is adopt an abandoned auth dependency into a revenue-critical path.

To engineering: This is a Symfony bundle wrapping LightSAML for the Service Provider role — SP metadata, ACS endpoint, assertion validation, attribute mapping. Two hard blockers for us: it is not a Laravel package (no service provider, no publishable config; the value is reference code only), and its release cadence is compatibility patches only — 1.2.1 adds Symfony 4.1 support and nothing else, so there is no security-response story for signature-validation bugs, which is exactly the class of vulnerability that matters here. Use it to scope the work: enumerate IdP-initiated vs SP-initiated, per-tenant IdP config and certificate rotation, attribute-to-role mapping, JIT provisioning, and replay/clock-skew handling. Estimate accordingly. Then pick a maintained library or a managed provider for the actual implementation, and put an explicit owner on the auth path.

One-line ask: Approve SSO as a roadmap item, and approve a spike to choose between managed SSO and a maintained protocol library — with this package ruled out as a dependency.