Simplesamlphp Bundle Laravel Package

Technical Evaluation

What changed in v1.1.1. A new tag was published, which supersedes the prior assessment's "no release since 2017" finding — the package is not fully dormant. However, the release notes are empty: no changelog entry, no diff summary, no compatibility statement, no linked PRs or issues. A patch-level bump with no notes tells us a tag exists and nothing else. It does not establish that the two disqualifying technical facts have changed: (1) the bundle still targets the removed SimplePreAuthenticatorInterface / AbstractPreAuthenticatedListener model rather than AbstractAuthenticator, and (2) it still references un-namespaced SimpleSAML_* classes incompatible with SimpleSAMLphp 2.x. Until a diff proves otherwise, the architecture, feasibility, and risk conclusions below stand unchanged.

Architecture fit. The bundle is a thin Symfony bridge over SimpleSAMLphp, which is not really a library but a standalone PHP application with its own front controller, config tree (config/config.php, metadata/, cert/), and session handling. The bundle's model assumes this runs as a sibling app in the same PHP process and same cookie domain, and that Symfony's security layer can be driven from a pre-authentication listener. That is the core architectural constraint: shared runtime, shared session, shared hostname. Modern SAML SP integration generally takes one of two shapes instead — (a) an in-process Composer library with no second front controller, or (b) an out-of-process gateway (SimpleSAMLphp v2, Keycloak, oauth2-proxy, Authelia) that terminates SAML and hands Symfony an OIDC token or trusted header. This bundle only fits shape (a), and only under 2016-era assumptions about Symfony's security API.

Integration feasibility: low, pending verification. A v1.1.1 tag is a reason to re-check, not a reason to believe. The spike must pin the tag and diff it against the last pre-2017 tag on exactly four things: the symfony/security-bundle constraint, whether AbstractAuthenticator appears anywhere, whether SimpleSAML_* symbols were replaced with the namespaced API, and whether the SimpleSAMLphp config path lookup now respects Symfony's config/secrets pipeline. Absent those changes, the bundle remains a non-starter on Symfony 6/7 and on PHP 8.1+ with SimpleSAMLphp 2.x. Note also what an unannotated patch release implies about process maturity: no CHANGELOG, no upgrade guidance, and no way for a consumer to reason about risk between tags.

Technical risk: very high. The dominant number is still zero dependents — no downstream consumers means no canary, no de facto integration testing, no issue traffic surfacing breakage, and no one else to notice a regression introduced in 1.1.1. SAML is a security-critical surface (assertion signature validation, XML canonicalization, signature-wrapping defenses, XXE), and we would be relying on a wrapper plus whatever SimpleSAMLphp version it pins — potentially 1.x, EOL. There is still no advisory feed, no maintainer SLA, and Dependabot/Renovate will flag this permanently. A patch release with silent contents is arguably a worse signal than no release at all: it creates the appearance of maintenance without the evidence, and it means any future pin can shift under us with an unexplained diff.

Key questions.

• Does the v1.1.1 diff touch composer.json, the security listener, or the SimpleSAML_* call sites — and is there a CHANGELOG or tagged issue anywhere explaining it?
• Which Symfony LTS are we on, and are we committed to it for the next 24 months?
• Does the IdP speak OIDC as well as SAML? (If yes, the calculus changes entirely — OIDC via knpuniversity/oauth2-client-bundle is a solved problem.)
• Do we require SP-initiated and IdP-initiated flows, single logout, encrypted assertions, or specific attribute/group mappings?
• Is there an existing SimpleSAMLphp deployment in the org whose ops team already owns certs and metadata?
• Multi-tenant (per-customer IdP metadata) or single IdP?
• Is SAML a contractual/compliance requirement or an internal SSO preference?
• Who owns signing-cert rotation and metadata refresh — and are those monitored?

What would change the recommendation. Explicit evidence, not a tag: Symfony 6/7 in the constraint, AbstractAuthenticator in the source, namespaced SimpleSAMLphp 2.x usage, a real CHANGELOG describing 1.1.1, and CI running against a supported matrix. Two or three of those together justify reopening the ADR. None of them alone, and certainly not an empty release note, does.

Integration Approach

Stack fit. Fits PHP 5.6–7.x with Symfony 2.8/3.x/4.0-era security. Does not fit Symfony 5.3+ authenticators, and is a non-starter on Symfony 6/7 without a fork. If the fleet is on PHP 8.1+/Symfony 6+, this package is out before the first spike — v1.1.1 does not change that unless the diff proves otherwise.

Migration path — three options, in preference order:

1. In-process, maintained library (recommended). nbgrp/saml-sp-bundle (actively maintained, Symfony 6/7 support, php-saml/LightSAML-based) or a thin custom AbstractAuthenticator wrapping onelogin/php-saml directly (~200–300 LOC including attribute mapping and tests). Config lives in Symfony's config tree; no second front controller; secrets flow through the normal env/secrets mechanism; fully unit-testable with a mock IdP.

2. Out-of-process SAML gateway. Run SimpleSAMLphp v2 (or Keycloak/Authelia/oauth2-proxy) as the SP/broker on its own hostname, terminate SAML there, and have Symfony consume an OIDC token or a signed header from a trusted proxy. Best fit when the org already runs a broker, when non-PHP services also need SAML, or when we want the auth path to scale and fail independently of the app.

3. Fork and port. Only justified if we have a hard dependency on a SimpleSAMLphp-specific feature (complex authproc filters, metaedit, attribute-release policy) that php-saml doesn't replicate. Budget 2–4 weeks engineering plus permanent ownership of a security-critical fork.

Compatibility checks before committing — now including the 1.1.1 diff. composer why-not symfony/security-bundle, grep for removed pre-auth interfaces, grep for SimpleSAML_*, git diff <previous-tag>..v1.1.1 -- composer.json src/, and — if SimpleSAMLphp runs in-process — audit session.save_handler, session cookie domain/path, and phpsession handling for collisions with Symfony's session. Timebox this to half a day; it is a gate, not a project.

Sequencing.

1. Tag diff (0.5 day): establish what v1.1.1 actually contains. Record it in the ADR whether or not it changes the decision — the next reviewer will ask.
2. Spike (3–5 days): stand up Keycloak or SimpleSAMLphp exampleauth in Docker as a mock IdP; prove end-to-end login, attribute mapping, and logout with the candidate approach.
3. ADR: in-process library vs. gateway, with the fork option explicitly rejected or scoped.
4. Build authenticator + user provider + attribute→role mapping behind a feature flag.
5. Dual-run old and new auth for one release with instrumentation on both paths.
6. Cut over, keep the legacy path dark for one sprint, then delete it.

Operational Impact

Maintenance. Still effectively zero upstream maintenance, and the 1.1.1 tag does not alter that: an unannotated patch release is a version number, not a support commitment. Every Symfony major becomes our migration. Ownership must be explicit and named — a team, a fork under org control, or a documented decision to use a maintained alternative. Adopting as-is means we are the vendor of last resort for authentication.

Support. No vendor, no SLA, no CVE feed. "Community support" is GitHub issues on a near-dormant repo. The new release adds a specific operational wrinkle: an unexplained version bump means any tooling that auto-bumps patch versions (Renovate/Dependabot) could silently pull unreviewed changes into a security-critical path. Pin the exact version and require manual review of auth-library bumps. Internal runbooks remain mandatory regardless of path: signing-cert rotation, IdP metadata refresh, clock-skew triage, ACS URL misconfiguration, and IdP-initiated flow debugging.

Scaling. In-process SimpleSAMLphp adds per-request bootstrap overhead (config load, metadata parse, separate session handler) — usually tolerable — but the real constraint is session topology: SAML SP sessions are cookie-bound to the SP domain, so we need shared session storage or sticky routing, and if SimpleSAMLphp maintains its own session store alongside Symfony's we inherit two session lifetimes and inconsistent logout semantics. A gateway scales independently of the app and keeps the app stateless.

Failure modes.

• IdP metadata past validUntil → total login outage. Requires monitoring on metadata expiry.
• Uncoordinated signing-cert rotation → assertion validation failures surfacing as a generic error page.
• Clock skew outside NotBefore/NotOnOrAfter → intermittent, hard-to-reproduce failures.
• Cookie domain / session collision → login loop (auth succeeds, app sees anonymous).
• SimpleSAMLphp path misconfiguration → fatal at bootstrap rather than graceful degradation.
• Unpatched XML/SAML parsing stack → signature-wrapping / XXE exposure.
• Silent attribute drift (IdP renames a group claim) → authorization failures, not login failures — the worst kind, because users get in and then can't do anything.
• Unreviewed patch upgrade (the 1.1.1 pattern) → an unexplained diff on the login path, discovered at deploy time or not at all.

Blast radius is uniformly "nobody can log in." That asymmetry is the strongest argument for the gateway option, where the auth component is a known, independently monitored hop and the app consumes a token.

Ramp-up. For a team already fluent in Symfony security and SAML: in-process maintained library, ~1–2 weeks to production-grade including tests and runbooks. Adopting this bundle as-is is a false economy — two days to wire, then unbounded porting cost at every framework bump. Gateway path, ~3–4 weeks including infra, TLS, monitoring, and the OIDC client work — a one-time cost that does not reset at each Symfony major.

Recommendation for the decision record. Do not adopt hslavich/simplesamlphp-bundle for new work. The v1.1.1 tag is noted and does not lift the disqualifiers: a 1.60 score, an unexplained patch release, no evidence of Symfony 6/7 support or a namespaced SimpleSAMLphp API, and zero dependents. Spend half a day diffing the tag, record the result, then run a 3–5 day spike on nbgrp/saml-sp-bundle (or a thin php-saml authenticator), write an ADR comparing it against a SAML→OIDC gateway, and treat any SimpleSAMLphp dependency as an infrastructure component with its own owner, monitoring, and upgrade cadence rather than a Composer line item.