Shibboleth Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the framing needs correcting. This is not a Laravel package. It is a Symfony 2 bundle: it registers a custom authentication provider and listener that plugs into Symfony's security.firewall configuration and reads Shibboleth Service Provider (SP)–injected request headers (Shib-Identity-Provider, eppn, mail, persistent-id, etc.) to construct an authenticated token. Laravel has no equivalent bundle/firewall/provider extension point — its guard, user-provider, and middleware contracts are structurally different. There is no path where this package is composer required into a Laravel app and works; the only realistic reuse is as a reference implementation for the header-trust pattern, reimplemented as a Laravel guard plus middleware.

Integration feasibility — low as-is, moderate as a pattern. Hard blockers: last release 2016-11-02, zero dependents, 17 stars, and Composer constraints pinned to the Symfony 2.x era and PHP 5.x. Symfony 2.8 reached end of life in November 2018; modern Laravel (10/11) requires PHP 8.1+, so Composer will refuse the install on dependency resolution alone. The repository referenced (rmoreas/ShibbolethBundle) is a fork of the KU Leuven original — provenance should be verified before treating any code as canonical.

Technical risk — concentrated in the security model, not the code. The bundle's core assumption is that an upstream SP has already authenticated the user and sanitized headers. If the application is ever reachable without traversing the SP — a misconfigured vhost, a direct-to-container health check, a staging host — any client can forge eppn and impersonate a user. This class of vulnerability is well known in header-based SSO and must be treated as a first-class threat model item, not a configuration detail. Secondary risks: unmaintained code with no CVE monitoring, no test suite exercising modern PHP, and LGPL-3.0 copyleft — typically acceptable for internal/SaaS use (no distribution), but redistribution of modified sources triggers obligations and requires legal sign-off.

Key questions for the discovery phase:

• Is the identity provider actually Shibboleth/SAML, or has the institution standardized on OIDC (Shibboleth IdP supports both)?
• Do we control the SP deployment, or is it operated by a central IT team with its own change cadence?
• What guarantees exist that client-supplied headers are stripped at the edge (Apache mod_shib + RequestHeader unset patterns, or a trusted reverse proxy)?
• What is the attribute contract — eduPersonPrincipalName, eduPersonAffiliation, mail, displayName — and how stable is it?
• Is LGPL-3.0 compatible with our distribution model?
• Is there a maintained alternative (Laravel SAML/OIDC packages, SimpleSAMLphp, an OIDC bridge in front of the IdP) that removes the need to own this code?

Integration Approach

Stack fit — effectively zero for Laravel, narrow for Symfony. The code is viable only inside a legacy Symfony 2.8/3.x application still running the old firewall API. For any Laravel target, treat the repository as documentation: the value is the attribute-mapping configuration and the authentication-token construction, roughly a few hundred lines of logic, not a reusable dependency.

Migration path — two distinct routes depending on where you are.

• Legacy Symfony in place: Do not extend the existing bundle. Plan a move to a supported Symfony LTS with either a maintained Shibboleth bundle or, preferably, an OIDC bridge, since most IdPs now expose OIDC and it avoids header-trust entirely.
• Laravel target: Build a thin custom integration. Implement Illuminate\Contracts\Auth\Guard (or a RequestGuard registered via Auth::extend) that reads a fixed allowlist of Shibboleth headers, resolves them through a user provider that maps eppn to a local user record, and performs just-in-time provisioning if the institution permits it. Pair it with middleware that enforces the presence of the SP header on every protected route, and a login controller that redirects to the SP's Login endpoint and handles the Shibboleth.sso/Logout return path.

Compatibility. Assume nothing installs on PHP 8.1+. If any reuse is attempted, expect to rewrite type hints, replace deprecated Symfony 2 APIs, and drop the symfony/symfony meta-package constraint entirely. Budget for a fork-and-own outcome — upstream will not merge or release.

Sequencing:

1. Confirm IdP protocol and the exact attribute release set with central IT.
2. Confirm SP topology: where mod_shib terminates, which proxy strips inbound headers, and how non-production environments are protected.
3. Implement header-allowlist middleware and fail-closed behavior before any user-mapping code exists.
4. Map attributes to the user provider; decide JIT provisioning vs. pre-provisioned accounts.
5. Build a local development harness that simulates SP headers so engineers are not dependent on the IdP.
6. Security review and penetration test specifically targeting header spoofing and direct-origin access.
7. Roll out with a break-glass local admin path and a documented fallback if the SP is unavailable.

Operational Impact

Maintenance. This is a buy-versus-build decision that is really build. With 17 stars, zero dependents, and no release in roughly nine years, there is no upstream to depend on — the organization owns the code, the security posture, and the upgrade treadmill from day one. The initial port is small (estimate one to two engineer-weeks including tests and security review); the ongoing cost is low in hours but non-trivial in attention, because federated auth failures are high-severity and often surface at the worst possible time.

Support. No vendor, no community, no maintainer. Support means an internal on-call engineer who understands Shibboleth SP configuration, SAML attribute release, and the application's user-mapping logic. LGPL-3.0 compliance needs a documented internal position before any code is copied or modified.

Scaling. Not a concern at the application layer. The Shibboleth SP terminates sessions and the app merely reads headers per request, so horizontal scaling is straightforward and stateless assuming the SP session is shared or the SP is behind a load balancer that routes consistently. The real scaling question is IdP-side: attribute release policy, session lifetime, and SP metadata management across every environment.

Failure modes to design for explicitly:

• Header absent — must fail closed with a clear error, never fall through to an anonymous or default user.
• Header forged — mitigations are network-level (deny direct origin access, strip inbound Shib-* headers at the edge); the application cannot defend itself here.
• SP outage or misconfiguration — total login outage; requires a break-glass admin path and status-page visibility.
• IdP attribute change — silent user-mapping breakage; mitigate with allowlist validation and alerting on unmapped principals.
• Session lifetime mismatch between SP and application — produces confusing partial-logout states.

Ramp-up. The conceptual surface is small: one guard, one middleware, one user provider, plus SP configuration. An engineer comfortable with Laravel authentication can be productive in one to two days; the steeper learning curve is Shibboleth itself — metadata exchange, attribute release, and certificate rotation — which is central IT territory and should be treated as an external dependency with its own SLA.

Overall read. The low package score (1.80) accurately reflects abandonment and stack obsolescence, while the higher opportunity score (2.60) reflects that federated institutional login remains a real, recurring need. My recommendation is to not adopt this package in any form, but to mine it for its attribute-mapping conventions and implement a small, owned, fail-closed integration on the target framework — or better, evaluate an OIDC bridge that eliminates header trust as an attack surface entirely.