Apereo CAS is the open-source Java server that implements the Central Authentication Service protocol and serves as an enterprise identity provider and single sign-on platform for the web, aimed at organizations that need one authentication and authorization layer across many applications.

What it is

Apereo CAS is an enterprise multilingual identity provider and single sign-on solution for the web, built as an open-source Java server component and distributed as the primary implementation of the CAS protocol. It positions itself as a comprehensive platform for authentication and authorization needs, and the same server speaks a broad set of additional protocols beyond CAS itself, including SAML2, OAuth v2, OpenID Connect, and WS-Federation Passive Requester.

The concrete problem it solves is the fragmentation of credentials and sessions across an application estate. Instead of every application maintaining its own login, the CAS server centralizes authentication, then issues the assertions and tokens applications consume. Where a commercial identity product would otherwise sit in that position, CAS replaces it with an Apache-2.0-licensed server the operator runs, backed by a documentation set hosted at apereo.github.io/cas, a Slack channel, and project mailing lists for support.

Key capabilities

• Protocol support spans CAS v1, v2 and v3, SAML v1 and v2, OAuth v2, OpenID Connect, and the WS-Federation Passive Requester Protocol.
• Authentication backends include JAAS, LDAP, RDBMS, X.509, Radius, SPNEGO, JWT, Remote, Apache Cassandra, Trusted, BASIC, and MongoDB.
• Multifactor authentication is available through Duo Security, Simple MFA, YubiKey, RSA, Google Authenticator, and WebAuthn FIDO2.
• Authorization integrates with Heimdall, OpenFGA, OPA, ABAC, Time/Date, REST, and Internet2's Grouper.
• High-availability clustered deployments rely on Hazelcast, JPA, Memcached, Apache Ignite, MongoDB, Redis, or DynamoDb.
• Application registration can be backed by JSON, LDAP, YAML, Google Cloud, JPA, MongoDB, DynamoDb, or Redis.
• Delegated social authentication connects to external identity providers over WS-FED, SAML2, OpenID Connect, and OAuth, while administrative UIs manage logging, monitoring, statistics, configuration, and client registration.

Who uses it and how

• Organizations that need one credential per user across a portfolio of web applications deploy CAS as the central identity provider and let each application delegate login to it.
• Teams with existing directory infrastructure authenticate against LDAP, RDBMS, or MongoDB rather than migrating user records, since those backends are first-class authentication sources.
• Operations groups that must enforce a second factor configure Duo Security, YubiKey, WebAuthn FIDO2, or Google Authenticator as multifactor providers.
• Sites needing availability under load run clustered deployments backed by Hazelcast, Redis, Memcached, or Apache Ignite.
• Administrators who prefer delegated login configure CAS to trust an external WS-FED, SAML2, or OpenID Connect provider instead of holding credentials directly.

Getting started

The README recommends deploying CAS locally using the WAR Overlay method, with the artifact published in Maven Central as org.apereo.cas:cas-server-webapp. Cloning or downloading the codebase is only required if the intent is to contribute to the project itself.

How it compares

No list of paid products replaced by this project is provided in the facts, and no comparable similarly licensed tools are named either. On the evidence available, CAS stands alone in this registry as the recognized open-source implementation of the CAS protocol.

When to use it — and when not to

A self-hoster takes on a Java web application that must be wired to authentication backends, application registration stores, clustering infrastructure, and notification providers such as Twilio, Mailgun, SendGrid, or Amazon SES if those features are needed. The README points contributors and would-be developers at the full codebase, but deployers are steered toward the WAR Overlay, so teams without Java web operations experience should weigh that cost. Support flows through Slack and mailing lists rather than a vendor contract, so organizations requiring a commercial SLA should look elsewhere.