Symfony Bridge Laravel Package

Product Decisions This Supports

• Enterprise deal gating (SSO as a checkbox). SAML 2.0 SSO appears on most mid-market and enterprise security questionnaires and blocks contract signature until it ships. This package is one candidate implementation path, so it informs the "can we unblock this deal this quarter?" decision — but it does not by itself answer it.
• Build vs. buy for federation. SAML is deceptively expensive to get right (XML canonicalization, signature validation, clock skew, certificate rotation, IdP metadata drift). This bundle sits at the "assemble cheaply" end: a thin Symfony DI bridge over the LightSAML library, not a from-scratch build and not a managed service.
• Stack-alignment decision (the most important one here). This is a Symfony bundle, not a Laravel package. Its entire value is the bridge into Symfony's Security component and bundle system, which Laravel does not have. For a Laravel product, this is a reference implementation input, not a dependency — and that distinction is itself a roadmap decision.
• Roadmap scoping for identity. The choice of SAML engine determines how cheaply you can later add IdP-initiated flows, JIT user provisioning, per-tenant IdP configuration (multi-tenant B2B), attribute/role mapping, and eventually SCIM. Pick the engine with the adjacent features in mind, not just the happy path.
• Supported-IdP prioritization. Useful as a short spike when validating against Okta, Microsoft Entra ID, Google Workspace, Ping, or OneLogin — proving metadata exchange and assertion parsing before committing roadmap time.
• Packaging and pricing. SSO is commonly a paid tier or enterprise-plan differentiator. Knowing the real build/own cost (see maintenance below) is required before promising it in a contract or price sheet.
• Security and maintenance risk budgeting. With 1 star, 0 dependents, and a near-zero version score, adoption is a "we will own this code forever" decision, not a "the community keeps it patched" decision. That materially changes total cost of ownership in any build-vs-buy model.

When to Consider This Package

Evaluate it only when all of the following hold:

• The application is Symfony — not Laravel, not framework-agnostic PHP. For Laravel, look at a maintained SAML2 wrapper (e.g. 24slides/laravel-saml2, itself over onelogin/php-saml) or a managed identity broker instead.
• You have already independently chosen LightSAML as the engine, or you are running a short, time-boxed spike to evaluate it.
• The integration is internal-facing, low-blast-radius, or a proof of concept — not a customer-facing, multi-tenant, revenue-critical auth path.
• You are prepared to vendor/fork the bundle and own security patches, Symfony version bumps, and CVE response for the LightSAML dependency chain.
• You want a reference for container wiring and configuration structure to copy into your own bundle, rather than a dependency you composer require and forget.

Look elsewhere when:

• You are on Laravel. Hard blocker, not a preference. There is no bundle system, no SecurityBundle, no equivalent firewall listener seam.
• You need vendor support, an SLA, or audited security posture. One star and zero dependents means no community debugging surface; when an assertion-validation bug appears, you are the only one who will find it.
• You need modern Symfony/Laravel compatibility guarantees. Verify release cadence, PHP 8.2/8.3 constraints, and whether it references Security token classes removed in Symfony 6. Compare against actively maintained alternatives before committing.
• The requirement includes SCIM provisioning, per-tenant IdP configs, or self-serve IdP setup — a bare bridge won't carry you; price in the product surface, not just the protocol.
• Your security review requires tracked dependency advisories; an effectively unmaintained bridge is a finding waiting to happen.

How to Pitch It (Stakeholders)

For executives: SAML SSO is a revenue enabler — it sits on most enterprise security questionnaires and blocks deals until it ships. This specific package is a cheap prototype path, not a production commitment: it's a Symfony-only bridge over the LightSAML library with essentially no community behind it (1 star, 0 dependents), and it does not fit a Laravel stack at all. Recommendation: fund the capability (SSO, then SCIM), treat this bundle as a two-to-three-day spike to de-risk the protocol work, and budget for either an actively maintained bundle, a managed identity broker, or in-house ownership. Do not let "there's a package for that" compress the estimate — adopting it converts the team into maintainers of a security-critical fork.

For engineering: It's a dependency-injection bridge, not a SAML implementation — the real work and the real risk live in LightSAML and in your metadata/configuration handling. On Symfony it gives you a head start on service wiring and config schema; on Laravel it gives you nothing except a reference for metadata generation, AuthnRequest construction, and response-validation orchestration. Before adopting: run a composer require --dry-run against your actual composer.json as the first 30-minute task, check last commit and open issues, and read the assertion-validation path yourself — auth code you don't understand is auth code you can't defend in a security review. Preferred sequence: spike with this, then decide between a maintained SAML bundle (e.g. nbgrp/oneloginsaml-bundle, hslavich/OneloginSamlBundle), the OneLogin toolkit directly behind a framework-native guard, or vendoring this bundle with a named owner and a patch cadence.