Apereo CAS: a Java single sign-on server you extend through a WAR overlay

The problem Apereo CAS solves, and who ends up running it

Apereo CAS is an enterprise identity provider and single sign-on solution for the web, in the project's own words. The practical problem it addresses is the one that appears when an organisation has accumulated a dozen web applications, each with its own login form, and each with its own idea of who a user is. CAS puts one Java server in front of them: applications redirect a browser to CAS, the user authenticates once, and the applications receive a validated assertion about that user. The repository topics list the protocols it covers, including saml2, oauth2, openidconnect, mfa and ldap-authentication.

The audience is narrower than the README's tone suggests. This is a server that expects a servlet container, Java build tooling and an operations team. The README names Spring Boot and Spring Cloud as the foundations, and the top-level layout includes gradle build files, a webapp directory and a support directory. Someone who wants a login box for a weekend side project will find the surface area far larger than the task. Someone running a university or enterprise portfolio of applications, where the identity layer has to outlive several generations of those applications, is the intended operator.

How CAS actually works: protocol endpoints on top of Spring Boot

The mechanism is a server that terminates authentication and then issues protocol-specific responses. CAS v1, v2 and v3 are supported, alongside SAML v1 and v2, OAuth v2, OpenID Connect and the WS-Federation Passive Requester Protocol. A client application does not talk to a CAS library in the abstract; it redirects to a CAS endpoint and validates what comes back, or it treats CAS as a SAML or OIDC provider.

Authentication itself is pluggable. The README lists JAAS, LDAP, RDBMS, X.509, Radius, SPNEGO, JWT, Remote, Apache Cassandra, Trusted, BASIC and MongoDB, among others. Multifactor authentication is a separate layer with Duo Security, Simple MFA, YubiKey, RSA, Google Authenticator and WebAuthn FIDO2. Authorization is a third layer, with Heimdall, OpenFGA, OPA, ABAC, time and date rules, REST, and Internet2's Grouper named. Service registration, meaning the list of applications allowed to use this CAS server, can be backed by JSON, LDAP, YAML, Google Cloud, JPA, MongoDB, DynamoDb or Redis.

That layering is the architecture. Each concern has multiple storage and provider options, and the deployment wires them together through configuration rather than code. High availability follows the same pattern: Hazelcast, JPA, Memcached, Apache Ignite, MongoDB, Redis and DynamoDb are all listed as clustering options. The cost of this design is that a CAS deployment is a configuration artefact as much as a program, and the number of combinations is large.

Installing Apereo CAS with the WAR overlay method

The README is explicit about the deployment path. It recommends deploying CAS locally using the WAR Overlay method, and it states that cloning or downloading the CAS codebase is ONLY required if you wish to contribute to the development of the project. That sentence is the single most useful line for a new operator, because it rules out the approach most people try first.

The overlay is a Maven project of your own that depends on the published CAS webapp artefact and layers your configuration on top. The README links the Maven Central coordinates for org.apereo.cas:cas-server-webapp, and the Getting Started section carries the Maven Central badge for that group and artefact. The version you depend on is the release you intend to run, taken from the project's release list.

The project also publishes Docker images, and the README lists Docker containers as a deployment option alongside Apache Tomcat and Jetty. The repository contains a testcas.sh script at the top level, which is the closest thing to a runnable smoke test in the tree; the README does not document what it does, so read it before you rely on it.

For a first real use, the sequence the README points at is: read the Getting Started page, build the overlay, place your configuration under the overlay's resources, and deploy the resulting WAR to Tomcat or Jetty. Build commands are not in the README; the build guide is linked from the Development section as the Build Process page, and the repository root carries gradlew and gradlew.bat for the CAS codebase itself, which the README says you only need if you are contributing.

Where Apereo CAS is the wrong tool

The clearest failure mode is treating CAS as a lightweight login service. The README's feature list runs from delegated social authentication through administrative UIs to email and SMS notification via Twilio, Mailgun, SendGrid and Amazon SES. Every one of those is optional, but the configuration surface they imply does not disappear when you disable them. A single-application deployment that needs a username and password check will spend more time on CAS wiring than on the application.

A second boundary is operational. CAS is a Java server you host. If your organisation has no servlet container, no Java build pipeline and no one who can read Spring configuration, the deployment becomes a dependency on a person rather than on a platform. The README points to commercial support options and to Apereo's mailing lists and Slack for community help, which is an honest signal that self-support is the default.

A third is version migration. The release list shows two lines in flight at once: 8.1.0-RC1 on 2026-08-28, and 7.3.8.2 on 2026-09-07. Running a release candidate in production is a decision the README does not make for you, and the project publishes a maintenance policy and a release schedule rather than a compatibility promise. The last push to the repository was on 2026-09-21, but that says nothing about whether your specific configuration keys survive the next major version. The documentation is versioned by branch, with a development link and an 8.0.x link, so pin your reading to the version you deploy.

Apereo CAS compared with Keycloak

The related searches include a direct comparison with Keycloak, and the difference is worth stating plainly because both are Java identity servers. Keycloak is not described in the CAS material, so the comparison here is limited to what the CAS README claims for itself.

CAS positions itself as a protocol hub first: CAS v1, v2 and v3, SAML v1 and v2, OAuth v2, OpenID Connect and WS-Federation are all listed as supported protocols. Its extension model is the overlay, a Maven project you own, which means upgrades are merges of your configuration against a new dependency version rather than an in-place server upgrade. Its integrations section names Apache Syncope, SCIM, Swagger, Shibboleth IdP, Keycloak, Okta and more, so CAS is designed to sit alongside other identity systems rather than replace them outright.

That is the real difference in approach. CAS expects to be one component in a heterogeneous identity estate, with delegated authentication to external providers such as WS-FED, SAML2, OpenID Connect and OAuth CAS. If your requirement is a single self-contained server with a built-in admin console and no build step in the upgrade path, the overlay model will feel like overhead. If your requirement is to keep a legacy CAS protocol alive while adding OIDC and SAML for new applications, the protocol coverage is the reason to pick it.

Licence, maintenance and what an upgrade really costs

CAS is licensed under Apache v2, and the README states it is 100 percent free open source software managed by Apereo. The NOTICE and LICENSE files sit at the top level of the repository. For an organisation embedding CAS in a product, Apache-2.0 is a permissive licence with a patent grant, but the details depend on your own distribution and legal review; nothing here is legal advice.

The maintenance model is volunteer-driven. The README says the time and effort to develop and maintain the project is dedicated by a group of volunteers and contributors, and it asks benefiting organisations to consider becoming a Friend of Apereo. Commercial support options exist and are linked from the support page. Read that as a governance fact rather than a warning: the project publishes a maintenance policy and a release schedule, and the release list shows both a current 8.x line and a maintained 7.3.x line with patch releases on 2026-09-01 and 2026-09-07.

The upgrade cost lives in the overlay. Because your deployment is a Maven project depending on cas-server-webapp, moving from 7.3.8.2 to an 8.x release means changing that version and rebuilding, then finding which of your configuration keys changed. The README does not document rollback, and it does not publish a configuration compatibility matrix. The mitigation is to keep your overlay small and your customisations in configuration rather than forked source, so the diff between versions is something you can read.

Editorial conclusion

Adopt Apereo CAS if you need one Java server fronting CAS, SAML2, OAuth 2 and OpenID Connect for many applications, and if you have Maven and servlet container experience in house. Do not adopt it as a small internal login page for a single app, and do not clone the repository to run it: the README states cloning is only required if you wish to contribute. Verify first that the WAR overlay guide at apereo.github.io/cas/development/installation/WAR-Overlay-Installation.html matches your container, and check the maintenance policy page before you plan an upgrade cadence.

Frequently asked questions

Official sources

1. apereo/cas on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases