- Can I install l3/cas-bundle in a Laravel application?
- No. l3/cas-bundle is a Symfony bundle, not a Laravel package: it ships a Symfony bundle class and DI extension, with no Laravel service provider, facade, or publishable config. Composer will install it, but Laravel will not auto-discover anything useful and you will pull in symfony/http-kernel, symfony/dependency-injection, and symfony/config for zero runtime benefit. Treat it as reference code for wiring phpCAS, not as an installable dependency.
- Is l3/cas-bundle compatible with Laravel 10 and Laravel 11?
- Not in any supported way. The bundle targets Symfony 2 through Symfony 5, and there is no Symfony 6 or 7 support, which also caps the PHP versions it can run on. Laravel 10 and 11 require PHP 8.1+ and modern Symfony components, so those constraints do not line up. Even if Composer resolved the dependency graph, there is no Laravel integration layer to use.
- How do I install and register l3/cas-bundle?
- In a Symfony app you run composer require l3/cas-bundle, register the bundle in AppKernel or bundles.php, then configure the l3_cas / cas settings for server host, port, context, and service base URL. In Laravel there is nothing to register, because no service provider is auto-discovered and there is no config/cas.php to publish. That asymmetry is the core reason the package is a poor fit for a Laravel target.
- How do I add CAS single sign-on to a Laravel app without this package?
- Implement CAS as a custom Laravel auth guard backed directly by apereo/phpcas, or evaluate a maintained Laravel-native CAS or SAML wrapper first. The bundle's real value is its configuration schema: service base URL, server host, port and context, certificate validation toggle, and logout behaviour. Reproduce that schema in config/cas.php, bootstrap phpCAS inside the guard, and keep it confined to the web guard. A competent Laravel engineer can cover the useful part in a few days.
- Is l3/cas-bundle actively maintained?
- Barely. It has roughly 32 GitHub stars, zero dependents, and its last release was August 2023, which predates Symfony 6 maturity. It is effectively a single-maintainer wrapper around phpCAS with a thin test and commit history. If you adopt it, budget to own it across the next Symfony and PHP upgrade cycles.
- What license does l3/cas-bundle use and can I use it commercially?
- GitHub reports the license as NOASSERTION, meaning no verifiable OSI license text could be identified. In organisations with dependency-review or SBOM policies that fails procurement by default and is a blocking legal gate rather than a checkbox. Clear it with legal, or vendor or fork the code under a known license, before writing any integration code.
- What does the l3_cas configuration actually cover?
- The bundle is a thin configuration and DI adapter over phpCAS: server host, port, context path, service base URL, certificate validation, and logout behaviour, exposed under the l3_cas / cas namespace. The actual protocol work, including ticket validation, service URL construction, proxy tickets, and SAML assertions, is done by phpCAS itself. That is exactly why the package is cheap to replicate natively in Laravel.
- Can I use phpCAS with Laravel Sanctum or Passport token auth?
- Not safely. phpCAS uses static global state via phpCAS::client(), assumes session_start(), and relies on HTTP redirects, which conflicts with stateless token auth and queue or CLI contexts. Any Laravel integration should confine phpCAS to the web guard and keep Sanctum or Passport token flows completely separate. Do not call phpCAS from queued jobs, Artisan commands, or API middleware.
- Does l3/cas-bundle support CAS 2.0, CAS 3.0, SAML, and proxy tickets?
- Protocol support comes from phpCAS, not from the bundle, so CAS 2.0 and 3.0, SAML 1.1 assertions, and proxy granting tickets depend entirely on how phpCAS is configured. The bundle only exposes the configuration surface it wires into the Symfony container. Check which CAS level your IdP actually exposes and whether that config covers it, or whether you need to work with phpCAS directly.
- Should I build a CAS guard in-house or use a Laravel-native package?
- For a Laravel estate, build the guard in-house over phpCAS or pick a maintained Laravel-native package, scoring candidates on release recency, license clarity, and test coverage. This bundle's replacement cost is low because its contribution is DI wiring rather than protocol logic, so porting the pattern costs days, not weeks. If your IdP has a SAML or OIDC roadmap inside 18 months, avoid investing heavily in CAS glue at all.