Weave Code
Shibboleth Bundle Laravel Package
kuleuven/shibboleth-bundle
A Symfony bundle that adds Shibboleth single sign-on authentication to your application, handling service provider setup, attribute mapping, and user sessions so you can integrate institutional SSO with minimal configuration.
kuleuven/shibboleth-bundle integrates Shibboleth single sign-on into Symfony applications, letting you authenticate users through federated identity providers without handling credentials directly. It reads trusted attributes from the Shibboleth SP environment and maps them to your application's users.
- Configurable attribute mapping for usernames, roles, and email addresses
- Multiple authentication guards and firewall integration
- Support for logout and session handling with Shibboleth
- Flexible user provider and role assignment via attributes
- Easy setup through bundle configuration and service definitions
Frequently asked questions about Shibboleth Bundle
- Can I use kuleuven/shibboleth-bundle in a Laravel application?
- No. It is a Symfony 2 bundle that plugs into Symfony's security.firewall, custom authentication provider, and listener extension points, which Laravel does not have. Laravel's guard, user-provider, and middleware contracts are structurally different, so there is no path where Composer requires this package into a Laravel app and it works. The only realistic reuse is as a reference implementation for the header-trust pattern, reimplemented as a Laravel guard plus middleware.
- What does kuleuven/shibboleth-bundle actually do?
- It adds Shibboleth single sign-on to a Symfony 2 application by registering an authentication provider and listener inside the security firewall. It reads Service Provider-injected request headers such as Shib-Identity-Provider, eppn, mail, and persistent-id to construct an authenticated token. It also handles session setup and attribute mapping so federated login works inside Symfony's security layer.
- Is kuleuven/shibboleth-bundle maintained?
- No. The last release was 2016-11-02, it has zero dependents and 17 stars, and its Composer constraints are pinned to the Symfony 2.x era and PHP 5.x. Symfony 2.8 reached end of life in November 2018, and there is no CVE monitoring or test suite exercising modern PHP. The repository referenced is a fork of the KU Leuven original, so verify provenance before treating any code as canonical.
- Why does Composer fail when I require kuleuven/shibboleth-bundle in Laravel?
- The package's dependency constraints target Symfony 2.x and PHP 5.x. Modern Laravel 10 and 11 require PHP 8.1 or newer, so Composer refuses the install during dependency resolution. This is a hard blocker, not a configuration issue, and it confirms the package is not a Laravel dependency.
- How do I implement Shibboleth SSO in Laravel without this bundle?
- Build a thin custom integration instead of trying to install the bundle. Implement Illuminate\Contracts\Auth\Guard, or a RequestGuard registered through Auth::extend, that reads a fixed allowlist of Shibboleth headers and resolves them through a user provider mapping eppn to a local user record. Add middleware that enforces the presence of the SP header on every protected route, and add just-in-time provisioning only if your institution permits it.
- Is it safe to trust Shibboleth headers like eppn in my application?
- Only if an upstream Service Provider has already authenticated the user and sanitized the headers. If the application is ever reachable without traversing the SP, for example through a misconfigured vhost, a direct-to-container health check, or a staging host, any client can forge eppn and impersonate a user. Treat this as a first-class threat model item and strip client-supplied headers at the edge using Apache mod_shib with RequestHeader unset patterns or a trusted reverse proxy.
- What is the license of kuleuven/shibboleth-bundle and can I use it commercially?
- The package is LGPL-3.0 copyleft. That is typically acceptable for internal or SaaS use where you do not distribute the software, but redistributing modified sources triggers obligations and requires legal sign-off. Confirm both the license implications and the fork's provenance before relying on the code.
- How can I test Shibboleth authentication locally?
- For a Laravel reimplementation, simulate the Service Provider headers in feature tests by setting trusted server variables and asserting that your guard resolves the expected user. Never enable header trust in production without edge stripping, and keep a test that proves forged headers are rejected when the SP marker is absent. The original Symfony bundle has no modern test suite, so it offers little testing guidance.
- What alternatives exist for Shibboleth or federated login in Laravel?
- Use a maintained Laravel SAML or OIDC package, SimpleSAMLphp, or an OIDC bridge in front of the identity provider. Many identity providers, including Shibboleth, now support OIDC, which avoids header-trust entirely. For a legacy Symfony application, move to a supported Symfony LTS with a maintained Shibboleth bundle or an OIDC bridge rather than extending this one.
- What should I verify before reusing this bundle as a reference in a legacy Symfony app?
- Confirm whether the identity provider is actually Shibboleth/SAML or has standardized on OIDC, who operates the Service Provider and on what change cadence, and what guarantees exist that client-supplied headers are stripped at the edge. Document the attribute contract, such as eduPersonPrincipalName, eduPersonAffiliation, mail, and displayName, and check that LGPL-3.0 fits your distribution model. Treat the repository as documentation for the attribute-mapping and token-construction logic, not as a reusable dependency.
Weaver
How can I help you explore Laravel packages today?