Shibboleth Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is a Symfony2 bundle, not a Laravel package. It assumes a Symfony bundle registry, container compiler passes, and Symfony2's security layer — none of which exist in Laravel. There is no adapter layer that makes this installable in a Laravel application, so "architecture fit" for adoption is effectively zero. What does fit is the pattern: a Shibboleth Service Provider (mod_shib or an equivalent reverse proxy) authenticates the user upstream and emits attributes (Shib-Identity-Provider, eppn, mail, displayName, affiliation, persistent-id); the application trusts those attributes to resolve or provision a local user and issue a session. That is the actual integration shape for a Laravel app, and it is roughly a guard plus middleware — not a dependency.

Integration feasibility. Feasible as a reference, not as an install. The reusable asset is an inventory of attribute handling, logout/session edge cases, and the IdP-configuration surface the bundle exposes; a TPM should treat it as a requirements checklist for a small in-house implementation. Attempting to install it is not a compatibility question — composer resolution against PHP 8.1+ and Laravel 10/11 will fail outright on the Symfony2 constraints and PHP 5.x/7.0 era dependencies.

Technical risk — high. The framework branch is EOL (Symfony2 end-of-life since November 2019), there is no release cadence, one author, zero dependents, and no security advisory channel. For an authentication surface, an unmaintained upstream is disqualifying independent of the code quality. The design risk is inherent to the model rather than the package: header-trust authentication assumes the SP sits in front of every request; any direct-to-origin path — a misconfigured load balancer, container ingress, a debug route — lets a client forge eppn and impersonate a user. Attribute release is also configured by a third party (the campus identity team), so the contract can change silently and either break login or map the wrong identifier.

Key questions for the business owner.

1. Is the target stack genuinely Laravel, or is there a legacy Symfony service in the estate? The recommendation splits sharply on this.
2. Which federation and IdP are in scope (InCommon, eduGAIN, UK AMF, a single campus IdP), and is there an existing SP registration and metadata exchange, or does that need to be initiated?
3. What is the authoritative identifier — eppn, persistent-id, or pairwise-id? Pseudonymous identifiers change the account-linking and de-provisioning design.
4. Is Just-In-Time provisioning required, or must we reconcile against an existing user store?
5. Is Single Logout in scope? Shibboleth SLO is routinely out of scope, leaving a known UX gap the business must accept.
6. Who operates the SP on the customer/institution side, and what is their change lead time?

Integration Approach

Stack fit. For a Laravel target, do not install this bundle. Two viable paths:

• Preferred — SP-terminated, app-trusted headers. Run mod_shib (or a Shibboleth-aware reverse proxy) in front of the app and write a Laravel guard that reads the SP-injected attributes, resolves or provisions a local user, and issues a normal session. SAML stays entirely out of PHP; the application code stays small and auditable. This is the closest analogue to what the bundle actually does.
• Alternative — pure-PHP SAML. Use a maintained SAML2 library (SimpleSAMLphp, or a maintained Laravel SAML2 package) when the hosting environment cannot provide an Apache module or a proxy. Higher application-side cost and more moving parts, but portable across PHP hosting.

Migration path. Four independently shippable phases:

1. Environment spike (1–2 weeks). Stand up the SP in staging, complete metadata exchange with the IdP, and confirm the attribute set actually released — not what federation documentation claims.
2. Attribute mapping and guard. Implement the guard and middleware including a trusted-proxy check that rejects requests carrying Shibboleth headers from untrusted sources. Unit-test with synthetic attribute sets.
3. Provisioning. JIT creation, identifier linking, and — frequently forgotten — a de-provisioning and attribute-change path.
4. Cutover. Dual-run alongside existing auth, then retire the legacy path.

Compatibility. Confirm PHP 8.1+, Composer 2, and the target framework version. Because the bundle is not consumed, its Symfony2 constraints are irrelevant — but that also removes fork-and-patch as a fallback. You own the replacement code outright.

Sequencing. External dependencies gate the schedule. IdP metadata exchange and attribute-release negotiation sit outside the engineering team's control and routinely take longer than the code. Start the IdP conversation before writing the guard; do not sequence implementation ahead of attribute confirmation.

Operational Impact

Maintenance. The package is unmaintained; forking it would mean owning security patching on an EOL framework indefinitely. The recommended SP-plus-thin-guard approach concentrates security-critical code in mod_shib, maintained by the Shibboleth Consortium, and keeps the in-house surface small enough for routine review.

Support. No vendor, SLA, or community around this package specifically. Escalation paths are the Shibboleth mailing lists, the federation operator, and the campus identity team. Budget an internal runbook covering SP certificate rotation, metadata refresh, and named IdP escalation contacts.

Scaling. Header-based authentication is stateless per request and scales horizontally — provided every node sits behind the SP. The stateful component is the SP session cache; multi-node deployments need sticky sessions or a shared session backend, or users will see intermittent re-authentication. Load-balancer configuration is part of the design, not an afterthought.

Failure modes, roughly by severity:

• Direct-origin access with forged headers — total auth bypass. Mitigate with network policy and an explicit trusted-proxy allowlist; verify in a penetration test.
• IdP outage — hard external dependency; no fallback unless deliberately built. Agree outage posture with the business.
• Silent attribute drift — IdP renames or rescopes an attribute; logins fail or users are misidentified. Alert on authentication failure rate.
• Certificate and metadata expiry — SP or IdP signing cert rotation breaks federation. Put expiry monitoring on the calendar.
• Clock skew — assertions are time-bounded; NTP is load-bearing.
• SLO gaps — session ends at the app but persists at the IdP, or vice versa.
• SAPI variance — environment-variable propagation differs across mod_php, PHP-FPM, and container runtimes. Verify on the production runtime, not locally.

Ramp-up. Most product teams lack SAML/Shibboleth literacy. Assume 2–4 weeks of effective ramp for an unfamiliar engineer, plus an ongoing dependency on an external IdP administrator. The engineering effort is modest; the coordination effort is not.

Recommendation (TPM position). Do not adopt this package as a dependency — score 0, zero dependents, EOL framework, and a Symfony2/Laravel mismatch are each individually disqualifying for an auth surface. Leverage the repository as a reference for attribute handling and edge cases, and fund the capability through an SP-terminated, trusted-header integration with a small maintained in-house guard.