Shibboleth Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is a Symfony bundle (Unice\ShibbolethBundle), not a Laravel package. It plugs into the Symfony Security component and DI container: it registers a bundle, a firewall listener, and a user provider that reads Shibboleth Service Provider attributes from $_SERVER (Shib-Identity-Provider, eppn, mail, displayName, affiliation, etc.). No part of that bootstrap survives in a Laravel application — service providers, guards, and the auth manager are different abstractions. As-is, it will neither install nor boot under Laravel.

What is portable is the domain logic, and it is small: read SP-injected server attributes, normalize them, map to a local user, just-in-time provision on first login, key on a stable identifier. That is a few hundred lines, not a library. Treat the repository as a reference specification, not a dependency.

Integration feasibility. Feasible only with a Shibboleth SP (Apache mod_shib, or FastCGI/shibauthorizer for nginx) sitting in front of the app so attributes arrive as server variables on every request. The application never parses a SAML assertion itself — that is a genuine security-surface advantage: no XML signature validation in our code, no per-request crypto, no assertion-replay store. The cost is a hard deployment coupling to the SP and to whoever operates it (usually central IT at a university).

Technical risk. High, on three axes:

• Adoption / bus factor: 3 stars, 0 dependents, single-institution maintainer. This is effectively abandoned-source software, and it would sit on the authentication path — the worst place for an unmaintained dependency.
• Framework drift: expect no guarantees for current Symfony (6/7), let alone PHP 8.3+. The manifest and security-listener API surface churn regularly.
• Header spoofing: the highest-severity issue. Because authentication is "trust these Shib-* request headers," any path that reaches the app without traversing the SP lets a client forge eppn and impersonate any user. This is an infrastructure control, not a code control, and it must be owned explicitly.

The composite score (0.769) is carried by documentation/legibility, not by leverage — opportunity at 22.69 with zero dependents confirms there is no ecosystem to inherit fixes from.

Key questions.

1. Which framework is actually in scope? If Laravel, this package is a non-starter as a dependency and we should say so to the requester now.
2. Is the identity provider in a federation (eduGAIN / InCommon / RENATER)? What is the written, agreed attribute release policy — specifically eppn vs persistent-id, mail, displayName, affiliation?
3. Who operates the SP — us or central IT? What is their change lead time?
4. SP-initiated, IdP-initiated, or both? What are the single-logout expectations?
5. Do we need just-in-time provisioning, or must SSO accounts link to pre-existing local records?
6. Is there a multi-IdP or guest-account requirement?
7. Is the app ever reachable outside the SP (health checks, API clients, internal VPC traffic)? That determines the spoofing blast radius.

Integration Approach

Stack fit. Three viable paths, in order of preference:

1. Reimplement the pattern in a thin Laravel guard + user provider (~200–400 LOC) using the bundle as a documented reference for attribute names and mapping semantics. No dependency on unmaintained code; full control of the user model and provisioning rules. Lowest total cost for a Laravel target.
2. Use a maintained SAML library (slackhq/laravel-saml2, onelogin/php-saml) if standing up an SP is not operationally possible. This pushes XML/crypto into the app and adds a session store and metadata-rotation burden — a real step up in complexity, justified only if the SP is off the table.
3. Vendor/fork the bundle only if the estate is already Symfony and the target version is explicitly supported. Pin the commit, own the patches, and budget for the fork going stale.

Migration path. There is no schema and no data to migrate — this is greenfield auth, so "migration" means the login flow and the user records behind it. Sequence it as: local password auth continues in parallel → SSO enabled for a pilot cohort → SSO enforced for all standard users → local login retained solely as break-glass for a named admin group. Provisioning key should be the federation persistent-id if released, falling back to eppn; storing both prevents a re-keying incident later.

Compatibility. Blockers to verify before any commitment: supported PHP and Symfony versions in composer.json; Shibboleth SP 3.x vs. older module behavior (Apache vs. FastCGI attribute exposure differs); and whether the deployment target terminates TLS in a way that preserves the SP's injected variables. Under Laravel, this check collapses to "does the deployment front the app with an SP" — the package version question disappears.

Sequencing.

1. Confirm IdP, federation membership, and attribute release policy in writing. This is the long pole — institutional IT tickets routinely take 2–6 weeks.
2. Stand up the SP in staging; log and verify the actual attribute set (do not trust the documented set).
3. Build the mapping/provisioning layer; unit-test against captured attribute payloads.
4. Enforce ingress isolation and strip inbound Shib-*/eppn headers at the edge.
5. Dual-mode rollout, then enforcement, with break-glass tested.

Operational Impact

Maintenance. We own the code under every option. Upstream is effectively static, so the realistic plan is fork-and-patch or clean-room reimplementation — either way, allocate an owner. The ongoing work is not the auth logic; it is tracking IdP metadata changes and federation policy updates.

Support. No vendor, no SLA, no CVE feed. Escalation for an auth outage runs through the IdP operator (central IT / federation helpdesk), which is a different org chart and a different response clock than normal application incidents. Budget for that in the on-call runbook: "who do we page at 07:00 when nobody can log in" needs a name.

Scaling. Runtime cost is effectively zero — attributes are read from the request, no network call, no crypto, no shared session store. This scales better than app-level SAML, which does signature validation and metadata fetching per login. Scaling risk is entirely organizational, not technical.

Failure modes.

• SP misconfiguration or outage → total lockout, including admins. Break-glass local credentials are mandatory, not optional.
• Header spoofing → impersonation of any user, including privilege escalation. Mitigated only by network isolation and edge header stripping; must be a validated control, not an assumption.
• Attribute drift → IdP silently stops releasing mail or changes eppn scope; results in mass login failures or, worse, duplicate account creation under a new key. Detect with a mapping assertion at login and an alert on new-user-creation spikes.
• Logout asymmetry → Shibboleth single-logout is notoriously partial; the app session can outlive the IdP session. Set short app session TTLs and be explicit that "logout" means local logout.
• Framework upgrade breakage → acute if the bundle is vendored; non-existent under reimplementation.

Ramp-up. Two distinct costs. Engineering needs Shibboleth/SAML federation literacy — metadata, entity IDs, attribute release, SP config — which is uncommon in general web teams; budget 1–2 weeks and expect the first integration to be slow. Product/ops needs the IdP coordination path, which is calendar time rather than effort and is the dominant schedule risk. The package itself reduces ramp-up only as documentation: it is a legible example of the attribute-mapping contract, and that is its honest value here.

Recommendation. Do not adopt as a dependency. Use it as a reference implementation and build the mapping layer directly, or route through a maintained SAML library if an SP is not operationally achievable. The three-star, zero-dependent profile is disqualifying for anything on the authentication path.