Product Decisions This Supports
- Build vs. buy for the IdP half of SSO. This package is the issuing side — it authenticates users and signs SAML 2.0 assertions to downstream apps. Most products only ever need the consuming (SP) side; a true IdP is an enterprise/platform-tier capability customers ask for when they want to point their own apps at your login. That framing is the real product decision here.
- Stack-fit triage — and it fails ours. Despite being filed under Laravel/PHP, this is a Symfony 2 bundle (Bundle subclass, DI extension, XML/YAML service definitions, Symfony security/session assumptions). It cannot be installed into a Laravel app; there is no service provider, config stub, or Laravel extra. The supported decision is not "adopt" but "mine it for scope and protocol surface."
- Scoping a homegrown IdP. Reading it enumerates the real surface area you'd have to own either way: metadata endpoint, AuthnRequest handling, signed assertions/responses, certificate config and rotation, attribute mapping, single logout, session lifecycle. That list is a build estimate input, not a dependency.
- Roadmap and pricing gating for enterprise deals. If a customer or partner asks "can your product be our identity provider," this package confirms the answer today is "not without real build work." That is a packaging, pricing, and sales-commitment risk to flag before a rep promises SSO-as-IdP.
- Supply-chain risk triage. Zero stars, zero dependents, zero score on an authentication path means any appearance in a dependency audit should be treated as an unmaintained security-critical component, not a reusable library.
When to Consider This Package
Only consider it if every one of these is true:
- You are already running a Symfony 2.x legacy system you cannot migrate off.
- The IdP is internal-only — small user base, no external SLA, no federation with commercial SaaS.
- You have engineering capacity to vendor/fork it and own the code, including a security review of the signing, certificate, and token logic.
- The need is a short-lived proof of concept, not a production commitment.
Look elsewhere in essentially every other case, including ours:
- Laravel applications: out of scope entirely. Evaluate a SAML SP library, Laravel Passport/OIDC, or Socialite-based OIDC — depending on whether you actually need IdP or SP.
- Any modern Symfony version: use a maintained bundle rather than back-porting a Symfony 2 package (Symfony 2 EOL'd in 2018; the PHP 5.x floor compounds it).
- Anything requiring compliance or audit posture — SAML/OIDC conformance, key rotation, multi-tenancy, SCIM, audit logs. A zero-star, zero-dependent package is an unacceptable supply-chain risk on the auth path.
- Best default: unless IdP is a genuine differentiator, stand up Keycloak (self-hosted) or buy Okta/Auth0/Entra and integrate via OIDC. Same customer answer — "yes, we support SSO" — without owning an IdP and its security obligations.
How to Pitch It (Stakeholders)
To executives: We evaluated this package as a shortcut to offering SSO/identity-provider capability for enterprise customers. It is not viable: it is an unmaintained Symfony 2 component with no community and no dependents, and it does not run on our stack. The useful outcome is clarity on the requirement — SSO-as-IdP is a real enterprise feature with real scope, and it belongs on the roadmap as a deliberate investment, not a drop-in. My recommendation is to buy or deploy a standard identity provider (Keycloak self-hosted, or a commercial vendor) rather than build. That gets us a defensible "yes we support SSO" in weeks, with vendor-backed security, instead of quarters of custom auth code we would have to defend in every security review and every enterprise deal.
To engineering: Do not adopt. It is a Symfony 2 bundle — incompatible with our Laravel target — with zero stars, zero dependents, and it sits directly on the authentication path where a defect is a breach. Treat the repository as protocol documentation (metadata, AuthnRequest handling, assertion signing, cert rotation, attribute mapping, single logout) and as an input to a build estimate if IdP ever becomes strategic. Default path is OIDC against a managed or self-hosted standard IdP; if we ever build, the first deliverable is a written protocol/threat-model artifact and a fork we own — not a package we depend on.