Shibboleth Bundle Laravel Package

Product Decisions This Supports

• Market entry into higher-ed / research (eduGAIN, InCommon, RENATER): institutions in these federations often require federated identity (Shibboleth/SAML) as a procurement gate. This package is a reference for what "federated login" costs to build — a thin glue layer, not a platform.
• Build vs. buy vs. adopt for enterprise SSO: the package only solves the consumption side — it assumes a Shibboleth Service Provider (Apache mod_shib or FastCGI) is already running in front of the app and reads the attributes/headers that SP injects (eppn, mail, displayName, eduPersonAffiliation, schacHomeOrganization). That forces an explicit decision: do we run an SP per environment, or buy a managed SAML/SSO provider?
• Attribute-driven entitlement design: the useful product primitive here is mapping federation attributes to roles, seat counts, and license tiers (e.g., eduPersonAffiliation=staff → department admin). Decide early whether provisioning is JIT-on-first-login or admin-approved.
• Feature scoping for "Login with your university account": good input for a spike estimate — days, not a quarter — for a single known IdP. Not a substitute for self-serve multi-tenant SSO.
• Roadmap sequencing: because the package is Symfony-only, choosing it implicitly commits the team to Symfony for the auth-adjacent services. That's an architecture decision, not a library decision.
• Risk register item: 3 stars, 0 dependents, single-institution stewardship (Unice-SIL) means no community security-advisory channel and a bus factor of roughly one. Treat as fork-and-own if adopted, and budget maintenance accordingly.

When to Consider This Package

Consider it when all of the following hold:

• The stack is Symfony (this is a bundle, not a Laravel package — on Laravel it is at best a reference implementation to port, so look at laravel-saml2, a Socialite custom provider over onelogin/php-saml, or a managed IdP instead).
• You are serving one or a small number of known institutions with a negotiated attribute release, not self-serve onboarding of arbitrary IdPs.
• You already operate (or are willing to operate) a Shibboleth SP at the web-server layer and want the app to do attribute mapping, user provisioning, and session handling only.
• You are inside a consortium/university context where you can fork and maintain the bundle, or you're running a short-lived proof of concept to validate demand.

Look elsewhere when:

• You need Laravel-native support, PHP 8.3+/Symfony 7 compatibility guarantees, or an actively maintained release cadence.
• You need a real SP in PHP: signed AuthnRequests, encrypted assertions, Single Logout, metadata endpoints — use onelogin/php-saml, SimpleSAMLphp, or a commercial/self-hosted IdP (Keycloak, Authentik, WorkOS, Auth0).
• You need multi-tenant, self-serve SSO (per-customer metadata upload, SCIM, JIT provisioning, admin UI). This package does none of that.
• Security review flags header spoofing risk: if the app is reachable without the SP in front, injected Shib-* headers are trivially forgeable. That's an infrastructure control, not something the bundle enforces.
• The score profile (overall ~0.77, opportunity ~22.7, no dependents) matters: there is no meaningful ecosystem momentum to ride, so adoption cost is essentially "we now own this code."

How to Pitch It (Stakeholders)

To executives: Federated login is a checkbox that unlocks the university and research segment — many of those buyers cannot approve a vendor that only offers local passwords. This package proves the integration is small: it's a thin adapter over an identity system the customer already runs. But it is a 3-star, zero-dependent, single-institution project with no support contract. Recommendation: fund a two-week spike using it as a reference, and make the real investment decision on either a maintained SAML library or a managed identity vendor. Do not put it on the critical path of a revenue commitment.

To engineering: It's a Symfony bundle that consumes Shibboleth SP attributes and provisions users from them. If we're on Laravel, it's a design reference, not a dependency. If we adopt it, we fork it, pin it, own the security patches, and require a hard network boundary so only the SP can reach the app. Estimate the fork-and-own cost as permanent, not one-off.