Apereo CAS

Last reviewed Aug 26, 2026 · 837 words

Do not run Apereo CAS at home. Run it if you are a university, a large nonprofit or a company that already has CAS-protocol applications on the network and needs the identity provider those apps expect. That is the entire audience, and CAS serves it exceptionally well: over two decades of continuous development since the Yale original, every protocol that matters (CAS, SAML 2, OAuth 2, OpenID Connect), multi-factor, delegation to upstream identity providers, and a configuration surface with thousands of documented properties. The "Hard" difficulty rating in the catalogue is honest, and the reasons are structural rather than fixable with a better tutorial.

CAS is a build, not an install

Most self-hosted identity servers ship a container you configure with environment variables. CAS ships a Gradle project. The supported way to deploy it is the "WAR overlay": you clone the overlay template, declare which feature modules you want in build.gradle, add your properties to etc/cas/config/cas.properties, and build a WAR that embeds Tomcat. A first build pulls a few hundred megabytes of Spring dependencies and takes several minutes:

git clone https://github.com/apereo/cas-overlay-template
cd cas-overlay-template
./gradlew clean build
java -jar build/libs/cas.war

Java 21 is the requirement for the current 7.x line. The server listens on 8443 with a self-signed certificate by default, and the login page appears at /cas/login. The apereo/cas Docker image exists, but it is the overlay pre-built with default modules; anyone who needs LDAP, SAML or OIDC ends up building their own image on top of it, which is the same Gradle process wearing a different hat.

Configuration is properties, not a UI

There is no admin panel in the Keycloak sense. Authentication handlers, service registrations, MFA policies and protocol settings are all cas.* properties or JSON service definition files, and the reference documentation is a long list of them. A minimal LDAP setup looks like:

cas.server.name=https://sso.example.edu
cas.server.prefix=${cas.server.name}/cas
cas.authn.ldap[0].type=AUTHENTICATED
cas.authn.ldap[0].ldap-url=ldaps://ldap.example.edu
cas.authn.ldap[0].base-dn=ou=people,dc=example,dc=edu
cas.authn.ldap[0].search-filter=(uid={user})
cas.authn.ldap[0].bind-dn=cn=cas,ou=svc,dc=example,dc=edu
cas.authn.ldap[0].bind-credential=secret

Every application that may use CAS must be registered as a service, typically as a JSON file matching the app's URL pattern; unregistered services are refused. This is a feature (nothing can ride your SSO without permission) and the number one cause of "it worked yesterday" tickets when someone changes a hostname. Multi-factor comes as modules for TOTP, WebAuthn, Duo and others, with policies that can trigger by service, group or IP range.

The protocol is why it still exists

The CAS protocol itself is a ticket exchange: the browser gets a ticket-granting cookie from the server, applications receive a short-lived service ticket in the URL and validate it server-side. It predates SAML's dominance and OIDC's existence, and a generation of academic software (learning management systems, library portals, research tools) speaks it natively. If you inherit that estate, running CAS is far cheaper than teaching 40 legacy apps a new protocol. The same server can then expose OIDC and SAML to newer applications, which is the actual migration path most institutions take: CAS as the single IdP, protocols mixed per app, for years.

When Keycloak or Authentik wins

For anyone without existing CAS-protocol clients, Keycloak delivers the same protocol breadth with an admin UI, a single container and a realm model that maps to how organisations actually delegate control. Authentik is friendlier again and is the right default for a homelab or a small company wanting SSO in front of Grafana, Nextcloud and Git; the Authentik and Authelia guide covers that setup. Both accept LDAP from lldap as a user directory. CAS is not worse than these, and its academic pedigree means its LDAP and Shibboleth-style federation are unusually mature, but it asks for a Java build engineer's afternoon where the others ask for a compose file.

What I'd do

If the estate has CAS clients, run CAS 7 on Java 21 from the overlay, in a container you build in CI, with the properties and service JSON files in Git and a Redis or JDBC ticket registry so two nodes can share sessions. Register services explicitly, turn on WebAuthn MFA for staff, and expose OIDC for anything new. If the estate has no CAS clients, install Keycloak or Authentik and never look back; the identity category lists both. CAS is the best tool for a specific institutional job and a poor fit for everyone else, and I would rather say that plainly than pretend the difficulty rating is a tutorial problem.