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 README lists the protocols it covers, including CAS, SAML2, OAuth2 and OpenID Connect.

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, 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 points to a Quick Start that goes from a Docker trial to a configured WAR overlay, and it states that you do not need to clone the repository to run CAS; that is only required to contribute to 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 project of your own that holds your configuration on top of CAS. The version you build against is the release you intend to run.

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 the README does not document, so read it before you rely on it.

For a first real use, the README's "Try it in a minute" section runs the official apereo/cas image with Docker, using a version tagged on Docker Hub, then you open http://localhost:8080/cas/login and log in as casuser with the password Mellon. The Quick Start then takes you to a configured WAR overlay with a registered application in eight short steps, and Getting Started explains how to plan a deployment.

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: v8.0.3 and v8.1.0-RC3, both on 2026-10-24. 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-11-02, 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

Keycloak is named in the CAS README only as an integration, 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 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 documentation table lists 8.0.x and 7.3.x as maintenance releases alongside the development line.

The upgrade cost lives in the overlay. Because your deployment is a WAR overlay of your own, moving between versions means changing the CAS version you build against and rebuilding, then finding which of your configuration keys changed. 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 Java build and deployment 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 Quick Start at apereo.github.io/cas/development/planning/Quick-Start.html matches your environment, 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