- Can I install l3/cas-guard-bundle in a Laravel app to get CAS login?
- No. Despite being described as a CAS authentication guard for Laravel, this package is a Symfony Bundle that registers through Symfony's kernel and dependency injection container and hooks into security.firewalls. Laravel has no bundle registration, no firewall configuration surface, and a different container lifecycle, so Composer will install it but nothing will wire up. For Laravel you should use apereo/phpcas directly behind a custom Auth::extend guard, or port the ticket-validation and attribute-mapping logic from this bundle as a reference.
- How do I install and configure l3/cas-guard-bundle for CAS single sign-on in Symfony?
- Install it with Composer, register the bundle in your kernel or bundles.php, then configure the CAS host, port and context path in the bundle configuration. You then protect a firewall with the CAS guard so unauthenticated users are redirected to the Central Authentication Service login page and validated on ticket return. Finally point the firewall at a user provider so the identifier released by CAS resolves to your application user. It is explicitly a thin wrapper, so most protocol behaviour is delegated to apereo/phpcas.
- Which Symfony and PHP versions does cas-guard-bundle support?
- The package declares support for Symfony 3, 4, 5, 6, 7 and 8, with PHP 7.x through 8.4. Because Symfony 8 implies PHP 8.4, a single bundle version will not realistically serve both a legacy Symfony 3 application and a new Symfony 8 application on one runtime, so expect to pin different bundle versions per application. Also confirm with the maintainer whether newer Symfony majors use the deprecated Guard system or AuthenticatorInterface, since that determines your upgrade path.
- Is there a Laravel package equivalent to a CAS guard driver?
- There is no drop-in Laravel equivalent in this repository. The practical approach is to require apereo/phpcas and wrap it in a custom guard registered with Auth::extend, or use the phpCAS client inside a middleware and log the user in manually after ticket validation. The porting work is small, roughly a few hundred lines covering phpCAS initialisation, service URL configuration, ticket validation and attribute-to-user mapping. Treat this bundle as a specification for that guard rather than as a dependency.
- Does l3/cas-guard-bundle support CAS 1.0, 2.0, 3.0, SAML and proxy tickets?
- Because the bundle is a thin phpCAS wrapper, protocol version, SAML attribute release and proxy ticket behaviour are governed by how phpCAS is configured rather than by the bundle itself. CAS 2.0 and 3.0 with attribute release cover the vast majority of university deployments, but you should verify in a spike that the bundle exposes the phpCAS settings you need. Confirm single logout support separately, since SLO is an optional CAS behaviour and is often the piece a thin wrapper leaves unwired.
- Is l3/cas-guard-bundle production-ready and actively maintained?
- Signals are thin: around nine stars, no dependents, a single community maintainer and no published security policy or SLA. That points to niche utility rather than broken code, and the risk is partly mitigated because the load-bearing component is apereo/phpcas, which is mature and widely deployed in higher education. The real concerns are bus factor and inheriting phpCAS security cadence, since CAS ticket-validation flaws are authentication bypasses. Pin the phpCAS version explicitly and keep a documented exit path to using phpCAS directly.
- How do I map CAS attributes to my Symfony user provider with this bundle?
- After CAS validates a ticket, the released attributes are used to identify and load the user, so the firewall's user provider must be able to resolve the identifier CAS returns. Typical mapping covers uid, mail and display name, and you usually implement or override a user provider if you need to create users on first login or sync roles from LDAP-backed attributes. Check the bundle configuration for which attributes it exposes and whether you can supply a custom user provider before assuming attribute mapping is configurable.
- Why does a CAS login work but leave the user with no session or a session fixation warning?
- phpCAS historically manages its own session state, which can collide with Symfony's session handler, producing classic symptoms such as being authenticated yet seeing no session, or session fixation warnings after the ticket redirect. The fix is normally to configure phpCAS so it does not start or hijack a separate session and to ensure the session is regenerated on successful authentication. Test the full redirect, ticket validation and logout cycle against a real CAS server, because this class of bug rarely appears in unit tests.
- How do I test CAS authentication without a real CAS server?
- There is no prominently documented test suite, so assume you will need to build coverage yourself. The usual approach is to mock or stub the phpCAS client class so ticket validation returns a fixed attribute set, then assert that the firewall authenticates and loads the expected user. For end-to-end checks, run a lightweight CAS server stub or use an institutional test IdP, and always exercise the service URL, ticket consumption and logout paths.
- What are the alternatives to l3/cas-guard-bundle?
- The main alternatives are using apereo/phpcas directly with a custom Symfony authenticator or Laravel guard, or moving the integration to a broader protocol library such as SimpleSAMLphp or pac4j. Organisations that control the identity provider often find migrating to OIDC or SAML avoids the CAS wrapper layer entirely. If the bundle goes unmaintained, the escape hatch is cheap: because it is thin, replacing it with phpCAS plus a custom authenticator is a contained change rather than a rewrite.