Chapter 2: Architecture

The CAS architecture can be described in terms of system components including the clients and server that communicate via supported protocols. It would be helpful to keep the following diagram in mind for the discussion of CAS architecture.

2.1. System Components

The CAS server and clients comprise the two physical components of the CAS system architecture that communicate by means of various protocols.

2.1.1. CAS Server

The CAS server application is Java servlet built on the Spring Framework whose primary responsibility is to authenticate users and grant access to CAS-enabled services, commonly called CAS clients, by issuing and validating tickets. An SSO session is created when the server issues a ticket-granting ticket (TGT) to the user upon successful login. A service ticket (ST) is issued to a service at the user's request via browser redirects using the TGT as a token. The ST is subsequently validated at the CAS server via back-channel communication. These interactions are described in great detail in the CAS Protocol document.

2.1.2. CAS Clients

The term "CAS client" has two distinct meanings in its common use. A CAS client is any CAS-enabled application that can communicate with the server via a supported protocol. A CAS client is also a software package that can be integrated with various software platforms and applications in order to communicate with the CAS server using or or more supported protocols. CAS clients supporting a number of software platforms and products have been developed.

Software Platforms

• Apache httpd Server (mod_auth_cas)
• Java (Jasig Java CAS Client)
• .NET (Jasig .NET CAS Client)
• PHP (phpCAS)
• Perl (PerlCAS)
• Python (pycas)
• Ruby (rubycas-client)

Applications

• Outlook Web Access (via ClearPass extension)
• Atlassian Confluence
• Atlassian Jira
• Drupal

When the term "CAS client" appears in this manual without further qualification, it refers to the integration components such as the Jasig Java CAS Client.

2.2. Protocols

Clients communicate with the server by any one of several supported protocols. All the supported protocols are conceptually similar, yet some have features or characteristics that make them desirable for particular applications or use cases. For example, the CAS protocol supports delegated (proxy) authentication, and the SAML protocol supports attribute release and single sign-out.

2.2.1. CAS Protocol

The CAS protocol is a simple and powerful ticket-based protocol developed exclusively for CAS. The CAS protocol has two general versions, version 1 is a simple text-based protocol, while version 2 is an XML-based protocol that supports a novel form of delegated authentication called "proxy authentication." CAS is one of the few SSO products to support this kind of feature. A complete protocol specification, including versions 1 and 2, may be found at http://www.jasig.org/cas/protocol.

2.2.2. SAML 1.1 Protocol

CAS provides limited support for the SAML 1.1 protocol. SAML support was adopted to leverage a standardized protocol for two important use cases:

• Attribute release, where attributes describe the authenticated principal
• Single sign out

2.2.3. OpenID Protocol

The CAS server has limited support for the OpenID identity provider functionality, which allows integration with applications and services such as Google Apps and Salesforce.com. The OpenID protocol spefication is maintained as a set of specifications for different protocol aspects that can be found at http://openid.net/developers/specs/.

2.3. Server Software Components

In order to facilitate discussion of configuration and deployment in following chapters, it is helpful to provide an overview of server software components. CAS server software components are described in terms of Java interfaces that form an API that organizes the application source code and provides configuration and extension points for deployers. The following sections discuss the core interfaces of the CAS server API.

2.3.1. Authentication

CAS supports two distinct notions of authentication, user and service authentication. For the purposes of this user manual, "authentication" means user authentication where a user presents some credential(s) to be validated. The service authentication process will be referred to as an "access." There are a number of components that deal with user authentication that are described in detail in the following sections.

2.3.1.1. Authentication Handlers

The AuthenticationHandler interface describes the contract by which users present credentials for validation and simply return a boolean true/false value for success/failure. Authentication handlers are the integration point with identity management systems including directories and databases.

2.3.1.2. Authentication Managers

The AuthenticationManager interface describes the strategy by which AuthenticationHandlers will be evaulated to determine authentication success or failure.

2.3.1.3. Principals

A principal describes an authenticated user, including a unique identifier over one or more identity management systems. The principal may also contain arbitrary attributes describing the user, such as display name and security groups. These attributes are commonly used to facilitate authorization and personalization in CAS client applications.

2.3.1.4. Credential-to-Principal Resolvers

Upon successful authentication, CAS leverages CredentialsToPrincipalResolver components to attempt to map credential attributes onto a principal. A common use case is to map the username of a username/password pair onto an email address or other distinct namespace that is needed or expected by CAS client applications.

2.3.1.5. Principal Name Transformers

The PrincipalNameTransformer interface allows customization of the provided user name prior to authentication. A common use case of this component is to add a domain suffix to the username such that a fully-qualified username will be used to perform authentication.

2.3.1.6. Authentication Meta Data Populators

The AuthenticationMetaDataPopulator interface supports adding arbitrary meta data to the CAS authentication event. A common use case would be to store the authentication method or level of assurance of the user's credential.

2.3.1.7. Authentication Workflow

The CAS authentication workflow is not an interface per se, but is a workflow implemented in Spring WebFlow that can be customized to support novel use cases. Customizing logical transitions, decision points, and start/end states is straightforward and can generally be done by editing XML, while defining new actions typically requires development of actions in Java.

2.3.2. Security Policy

CAS provides a number of configurable and extensible components to control various aspects of security policy including SSO session timeouts, cryptographic strength of tickets/identifiers, and pre-authentication/post-authentication actions.

2.3.2.1. Service Registry

The ServiceRegistry component is responsible for defining the allowed services that may request and validate tickets provided by CAS as well as other service-specific concerns:

• Authorization to perform delegated authentication (proxy)
• Attribute release policy
• Whether or not service can participate in SSO session
• UI theming

2.3.2.2. Ticket Expiration Policy

The TicketExpirationPolicy component defines the lifecycle policy for various types of tickets. Common expiration policies are supported including finite timeout expiration, sliding scale expiration, expiration exceeding N uses, and everlasting tickets. The policy contract is simple to facilitate development of custom policies.

2.3.2.3. Identifier Generators

There are a number of generator interfaces that specify the generation of various identifiers:

• NumericGenerator - Generates sequential integer identifiers
• RandomStringGenerator - Generates random string identifiers
• UniqueTicketIdGenerator - Generates unique identifiers for use in tickets

2.3.2.4. Handler Interceptors

CAS supports the use of the Spring HandlerInterceptor component to instrument certain operations such as authentication and ticket validation. CAS leverages this component to implement security policies such as login throttling, although other security policies could easily be developed.

2.3.3. Ticket Registry

The TicketRegistry component is a ticket storage abstraction layer. CAS supports a number of implementations out of the box where all except the default in-memory storage are suitable for HA environments:

• Memory - DefaultTicketRegistry (default)
• Database - JpaTicketRegistry
• Memcached - MemCacheTicketRegistry
• JBoss Cache - JBossCacheTicketRegistry
• Berkeley DB - BerkeleyDbTicketRegistry