Lightsaml Symfony Bridge Laravel Package

Product Decisions This Supports

Feature: Enterprise SSO / SAML federation (the primary use case). This package is the glue layer that wires the LightSAML PHP library into Symfony's DI container and security stack — it's the piece you'd evaluate when a B2B customer says "we need SAML SSO before we can sign the contract." It informs the decision of how to ship SP-initiated (and in principle IdP-initiated) SAML login in a Symfony app: exposed ACS/metadata endpoints, assertion-to-user mapping, and attribute/role provisioning.

Build vs. buy vs. adopt (the highest-leverage decision it touches). The realistic framing is not "adopt this bundle" but "which SAML stack do we standardize on." This package represents one candidate — a buy-from-open-source option — and evaluating it forces the team to name the real strategic dependency, which is LightSAML itself, not the small bridge on top. That distinction changes effort estimates: swapping the bridge is cheap; inheriting a stale SAML core is not.

Migration / legacy triage. This is genuinely useful for one decision: if a legacy Symfony 2.8/3.x application already runs LightSAML and you're deciding whether to keep the integration alive through a migration window or rip it out now, the bridge's release history is evidence for "rip it out." It also supports deprecation decisions — i.e., whether to keep maintaining an internal SAML module versus replacing it with a maintained library.

It does NOT support: any decision about a new build, any roadmap item requiring a security support path, or any commitment that has a compliance review attached (SOC 2 / ISO / vendor questionnaire will ask about maintained dependencies, and "PHP 5.6-compatibility patches" is a fail).

When to Consider This Package

Consider it only in narrow, read-mostly contexts:

• You have an existing Symfony 2.8/3.x app already on LightSAML and you need to reproduce or document current SAML behavior during a migration.
• You're doing an internal audit or security review of an existing integration and need to understand how SP configuration, metadata, and user provisioning were wired.
• You need a reference implementation for legacy behavior ("what did our old SP response look like?") before rewriting it.

It is not appropriate when any of the following are true — and for a new product, at least one almost always is:

• New project, or Symfony 4+/5+/6+/7+.
• You need a committed security patch path — SAML is security-critical surface, and the most recent release is a PHP 5.6 syntax-compatibility patch, meaning the maintainer's forward-compatibility effort is directed backward at a runtime that reached end-of-life in December 2018.
• You need maintained bindings, IdP mode, modern assertion encryption/signing defaults, or protocol edge cases (SLO, artifact binding, encrypted assertions with rotating certs).
• Procurement or compliance will ask about dependency health, which they will.

Look elsewhere, concretely:

• onelogin/php-saml (maintained SAML toolkit) with a supported Symfony integration, e.g. hslavich/onelogin-php-saml-bundle or nbgrp/saml-sp-bundle — check current maintenance activity before committing.
• Question the protocol, not just the library. Many "we need SAML" requirements are satisfiable by OIDC, which is cheaper to operate and better supported in modern Symfony (via standard OAuth2/OIDC clients and an external IdP). If a customer genuinely requires SAML, you know early; if they just require "SSO with Okta/Entra," OIDC is usually the better buy.
• Outsource entirely to a hosted IdP broker (WorkOS, Auth0, Keycloak self-hosted) if SSO is not your core product — this is the "buy" option and is usually the right answer for a first enterprise SSO feature.

Health signals to put in front of the team: 0 stars, 0 dependents, initial release 2017-05-18, latest release 1.0.5 which is a PHP 5.6 compatibility patch (replacing Class::class with get_class()/stringified class names) — this is the single most telling datapoint: the package has decided its support baseline is PHP 5.6, not PHP 8.x. MIT license (so forking is legally trivial — but forking a SAML implementation means you own a security-critical protocol implementation forever, which is a bad trade for almost any team).

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated an open-source option for enterprise SSO and it does not clear our dependency-health bar — it's a small 2017 bridge over a SAML library that is itself effectively unmaintained, and its most recent release exists solely to stay compatible with PHP 5.6, a runtime that has been out of security support since 2018. There is no community, no dependents, and no one to call when it breaks. SAML is the login path for our biggest customers, so unmaintained code there is an unacceptable security and availability risk. Recommendation: fund SSO as a deliberate choose-one-of-three decision — hosted IdP broker (fastest, lowest ops burden, recurring cost), a maintained SAML library, or OIDC if the customer's requirement allows it — and treat the OIDC/hosted path as the default. Note the license is permissive, so there's no legal blocker; the blocker is operational ownership.

To engineering: This is glue, not a platform — the cost and risk live in LightSAML, and the newest release proves the project is optimizing for legacy runtimes rather than forward compatibility. Do not start here. Timebox a spike (1–2 days, no more) against a maintained SAML library or an OIDC IdP and validate against one real customer's metadata; that spike answers the build-vs-buy question cheaply. If we later find we must reverse-engineer legacy behavior, use this bundle as documentation only, not as a dependency — and pin it, because a patch-level bump that changes class-resolution mechanics is exactly the kind of churn you don't want silently landing during a security-sensitive migration.

Decision to make now: pick the protocol (SAML vs OIDC) and the owner (hosted vs in-house) for enterprise SSO. This package is the evidence against the in-house-on-legacy option, not a candidate to adopt.