Shibboleth Bundle Laravel Package

Product Decisions This Supports

• Roadmap: is federated institutional login a real requirement? Shibboleth is the SAML-based identity federation standard across higher education and research (the maintainer is KU Leuven). If your roadmap includes universities, research consortia, hospitals, or government labs as buyers, "can we accept their campus credentials?" is a gating question in RFPs. This package is a working artifact of that requirement and helps size the story.
• Build vs. buy for identity. Identity is almost never a build. The decision this package informs is integrate vs. outsource: stand up a Shibboleth Service Provider ourselves (config, metadata, certs, attribute release negotiation with each IdP), versus buying a managed identity layer (Okta, Auth0, WorkOS, Entra) that speaks SAML. This repo is evidence for the "integrate" cost column, not a component you'd ship.
• Attribute mapping and user provisioning spec. The genuinely reusable output here is the design pattern: how IdP-supplied attributes (eduPersonPrincipalName, eduPersonAffiliation, mail, displayName, persistent-id) map to your user record, how you handle first-login JIT provisioning, how you reconcile an SSO identity with an existing email-based account, and how role/affiliation drives authorization. That's a product decision about onboarding UX and account model, and it's the part worth copying.
• Scope framing for a spike. The package makes visible that the bundle is thin — it reads Shibboleth-populated request headers/environment set by mod_shib in Apache. The real work is SP configuration, IdP federation enrollment (e.g., eduGAIN, InCommon), and per-customer metadata exchange. That reframes the estimate from "a few days of PHP" to "a multi-week integration plus per-customer onboarding ops."
• Enterprise/security review inputs. A dependency with a last release in 2016, 0 dependents, 17 stars, and no security maintenance is a finding your security team will raise. Surfacing it now forces the "do we vendor, fork, or buy?" conversation before it becomes a launch blocker.

When to Consider This Package

First, a scoping correction that matters for the decision: this is not a Laravel package. kuleuven/shibboleth-bundle is a Symfony 2 bundle. Its service provider, DI container, and security firewall integration are all Symfony-specific and will not drop into a Laravel application. Treat it as a reference implementation and requirements document, not an installable dependency.

Consider it when:

• You maintain a legacy Symfony 2.x application (long EOL) and need institutional SSO with minimal change — and even then, plan to fork and own it.
• You need a concrete, readable example of mapping Shibboleth attributes to application users, roles, and JIT provisioning. This is the strongest reason to open the repo.
• You already terminate Shibboleth at the web server (mod_shib) and only need PHP-side session/user hydration.
• You are scoping effort for a higher-education go-to-market motion and want a realistic picture of the SP-side work.

Look elsewhere when:

• You are on Laravel (per your framing). Reach for laravel-saml2 / aacotroneo/laravel-saml2, a Socialite SAML driver, or SimpleSAMLphp as the SP — or, better, a managed IdP.
• You need maintained code. 2016 last release, 17 stars, zero dependents, no advisory history: assume no patches, no PHP 8 compatibility guarantees, no upstream support.
• You need actual SAML protocol handling rather than header reading. This bundle delegates all protocol work to the Shibboleth SP; if you can't run Apache + mod_shib, it's not applicable.
• You're selling to enterprises broadly. Shibboleth is a higher-ed/research pattern; commercial buyers expect generic SAML 2.0 / OIDC. A Shibboleth-only integration narrows your addressable market rather than widening it.
• Legal flags LGPL-3.0. As a PHP library it's interpreted code, so the copyleft boundary is less clear-cut than dynamic linking in C. If you fork and embed it, get counsel's read before shipping in a closed product.

How to Pitch It (Stakeholders)

To executives: Institutional SSO is a market-access question, not a code question. If higher education or research is a target segment, buyers will ask whether we accept their campus identities; if we don't, we're disqualifying ourselves in procurement. The good news is we don't need to build identity — we integrate or buy it. This specific package is a 2016-era Symfony component with no maintenance and no user base; we should not take it as a dependency. What we should take is its attribute-mapping design and its implicit cost model: server-side SP configuration plus per-customer federation onboarding is where the effort actually lives. Recommend a short spike to validate demand and a buy-leaning recommendation (managed IdP) unless a specific customer contract justifies the integration cost.

To engineering: Not a Laravel package — it's Symfony 2, EOL, unmaintained since 2016, 17 stars, zero dependents, LGPL-3.0. Do not composer require. Read it for the attribute-to-user mapping and JIT provisioning flow; expect the Shibboleth SP (mod_shib) to do the protocol work and the app to consume headers. If we proceed on Laravel, the candidates are laravel-saml2, a Socialite SAML driver, or SimpleSAMLphp as SP — and we should budget explicitly for SP config, certificate/metadata rotation, and per-IdP attribute release negotiation, which is the bulk of the schedule.