New CAS documentation site

CAS documentation has moved over to apereo.github.io/cas, starting with CAS version 4.x. The wiki will no longer be maintained. For the most recent version of the documentation, please refer to the aforementioned link.

The CAS User Manual is the primary source of documentation for implementers of the Jasig CAS server component.

New to CAS

For readers unfamiliar with CAS, the Overall Architecture section is a good starting point to learn what CAS is and how it works. Readers will learn that CAS is a multi-protocol SSO solution and they will want to review protocols to learn the use cases under which a particular protocol applies. Once review of background material is complete, readers should consider working through the CAS demonstration, which will provide a working product and an introduction to configuration.

Configuration

There are a few fundamental considerations to CAS configuration:

Integration with an authentication provider
Security policy
Authorization
Availability considerations
Attribute release

Authentication

CAS integrates with the following authentication mechanisms:

Security Policy

CAS uses tickets to implement supported authentication protocols, so it follows that ticket behavior determines most aspects of security policy. In its default configuration (as of CAS 3.3.3), CAS provides for the following:

Ticket-granting tickets (TGT) that expire after more than 2 hours of inactivity.
One-time-use service tickets (ST) that must be validated within 5 minutes.

The default behavior can be modified by tuning expiration policy parameters, or by choosing alternative expiration policies. See the Ticket Expiration Policy section for more information.

Authorization

Authorization in CAS determines what services may request and validate service tickets. By default there are no restrictions and any service at any URL may request and validate a service ticket. This may be undesirable for a number of reasons, so CAS provides a Services Management administrative tool to control what services may use the CAS server. Additionally, the services management tool allows fine-grained control of what attributes may be released to services.

Availability

CAS provides for high availability by placing client authenticated state data in tickets stored in a TicketRegistry component that has a number of implementations that support distributed environments:

Default is Not Distributed

The DefaultTicketRegistry, which is enabled by default, is not suitable for high availability environments unless combined with tool such as Terracotta.

For all the high-availability ticket registries above, any number of CAS server instances may be backed by a distributed registry and load balanced in an active-active configuration. Additionally, session state replication is unnecessary since tickets stored in the registry contain the authenticated state of users, which allows a CAS server node to fail without users losing their SSO session state.

Attribute Release

CAS is strictly an SSO product without explicit support for authorization. This is a strategic design feature for the highly-distributed, decentralized environments in which CAS excels. The solution to providing support for authorization needs arose around CAS 3.1.0 which provided support for attribute release. CAS queries a source of attributes when a user authenticates and stores the attributes for later release. If a service successfully validates a ticket by POST to the /samlValidate URI, user attributes, possibly scoped for that service via the Services Management admin tool, are delivered to the service via the SAML 1.1 protocol. The attribute release strategy may be used for authorization, personalization, and other arbitrary needs as determined by the requesting service. Note that the meaning of the attributes is largely determined by what the requesting service does with them.