Shibboleth Bundle Laravel Package

Product Decisions This Supports

• Segment expansion into higher-ed and research. Shibboleth is the dominant federated identity standard across academia (InCommon, UKAMF, eduGAIN, DFN-AAI). "Sign in with your university account" is frequently a hard procurement gate for university, consortium, and research buyers. This package is a compact reference implementation of that integration pattern — it shows the capability is small, not a platform-sized investment.

• Build vs. buy for authentication. The code demonstrates the minimum viable shape: trust the Service Provider (SP), read the environment headers it emits (Shib-Session-Id, Shib-Identity-Provider, eppn, mail, displayName, affiliation, entitlement, persistent-id), map attributes to a local user, and gate requests that arrive without the SP. That's roughly 100–200 lines of guard/middleware in Laravel. It is a strong input into the decision not to build a SAML stack in-house, and instead to lean on an existing SP or a managed identity vendor.

• Roadmap scoping for an "Institutional Login" epic. Informs estimation and sequencing: the transport is trivial, the real work is attribute mapping, just-in-time provisioning, de-provisioning, and the operational dependency on an external IdP team (metadata exchange, attribute release negotiation, certificate rotation).

• Architecture fit check — and a needed correction. Despite being catalogued as a Laravel/PHP package, this is a Symfony 2 bundle, not a Laravel package. It registers via Symfony's bundle/kernel mechanism and depends on Symfony2's security layer; Laravel's guard/service-provider model has no equivalent. It cannot be installed into a Laravel app in any meaningful way. This must be settled before any engineering time is spent — the answer changes the recommendation entirely.

• Use cases it validates: campus SSO for SaaS sold to universities, consortium and collaboratory portals, library/publisher access gated by institutional entitlement, and internal tools already sitting behind an institutional SP.

• Risk-register and policy input. Zero stars, zero dependents, zero score, no release cadence, single author, and an EOL framework (Symfony 2, EOL since 2018/2019). This is the canonical example for an explicit "no abandoned dependencies in the auth path" policy — authentication is the one place where unmaintained third-party code is least acceptable.

• Competitive intelligence. It tells us what a university IT reviewer will expect to see during evaluation (attribute release list, federation membership, SP metadata URL, SLO posture). That informs sales enablement and requirements, not the shipping plan.

When to Consider This Package

Consider it as a reading reference, not a dependency, when:

• Your team is inheriting or maintaining a legacy Symfony 2 application already sitting behind a Shibboleth SP, and needs to understand or re-implement the header-trust flow.
• You want a concrete inventory of which Shibboleth attributes teams typically map, to inform your own attribute-mapping specification.
• You have an existing SP operated by central IT or a federation team, and your application only needs to consume what it emits.
• You are scoping an institutional-login epic and need a cheap way to demonstrate the pattern's size to stakeholders.

Look elsewhere when:

• You are on Laravel. Use a maintained SAML package (e.g., a php-saml/OneLogin toolkit wrapper such as aacotroneo/laravel-saml2 or 24slides/laravel-saml2), or an OIDC bridge. Do not port a Symfony 2 bundle.
• You are on Symfony 5/6/7. Use the native authenticator system with a custom header-based authenticator; a handful of well-tested in-house classes beats an unmaintained bundle.
• You need real SAML. SP-initiated flows, metadata exchange, assertion signature validation, encrypted assertions, single logout — use SimpleSAMLphp or a maintained library. Header trust only works when the SP is guaranteed to sit in front of every request; that assumption breaks with direct-to-origin traffic, misconfigured load balancers, or container ingress.
• You need security maintenance. No stars, no dependents, no recent commits, dead framework branch — disqualifying for an auth surface.
• You need IdP-side capability (you are the institution issuing identities) — entirely out of scope.

How to Pitch It (Stakeholders)

To executives. This package is a reference, not a candidate dependency. It demonstrates that support for "sign in with your university account" — a common procurement requirement for higher-ed and research buyers — can be a small, low-risk feature when the customer's institution already operates a Shibboleth identity provider. The package itself is abandoned: Symfony 2 is end-of-life, and it has no stars, no dependents, and no maintenance. Adopting it would put unmaintained code in our authentication path, which is the single worst place to carry that risk. Recommendation: treat it as a design input and fund the capability via a maintained library or a managed identity vendor. Note also that it is a Symfony bundle, not a Laravel package — it was never installable in our stack.

To engineering. The pattern is "trust the SP, map attributes, provision just-in-time." It is roughly a listener/guard plus a user provider plus middleware — small. The cost is not code, it is operations: SP deployment, federation metadata registration, attribute release negotiation with each institution's IT, and certificate rotation. If we build, build on Laravel's native guard and middleware primitives with a maintained SAML/OIDC library behind the SP; do not vendor this bundle. Two viable paths: (1) preferred — run mod_shib or a Shibboleth-aware reverse proxy in front of the app and write a thin guard that reads the SP-injected attributes, resolving or provisioning a local User; (2) fallback — pure-PHP SAML2 via a maintained library when the hosting environment cannot provide an Apache module or proxy. Either way, include a trusted-proxy check that rejects requests carrying Shibboleth headers from an untrusted source, and unit-test with synthetic attribute sets. Flag this repository in the dependency policy as the canonical example of an auth dependency we would decline.

To sales/CS. Keep it as a competitive-intelligence artifact. It tells us what a university IT reviewer will expect to see when they evaluate us — attribute release list, federation membership, SP metadata URL, logout behavior. It does not tell us what to ship.

Key questions to settle before committing roadmap. Which federation and IdP are in scope (InCommon, eduGAIN, UK AMF, a single campus IdP)? Is there an existing SP registration and metadata exchange, or does that need to be initiated? Is the target stack genuinely Laravel, or is there a Symfony service in the estate? What is the authoritative identifier — eppn, persistent-id, or pairwise-id — and how does that affect account linking and de-provisioning? Is JIT provisioning required, or is there an existing user store to reconcile against? Is single logout in scope (Shibboleth SLO is frequently out of scope, producing a known UX gap)? And does the campus identity team have bandwidth, and what is their change lead time? That last item routinely gates the schedule more than the engineering does.