Architecture

The architecture for CAS 3.5 and higher is different than the original CAS3 architecture. This page describes the new architecture.

CAS is a traditional web application with a presentation tier, service tier, and data access layer. For most users the presentation layer consists of a combination of Spring Web MVC Controllers and Spring Web Flow.

Flow

The LoginRequestFactory is used to construct an implementation of a LoginRequest (when no service is present) or a ServiceAccessRequest when a service is present. Protocols that integrate with CAS will extend the interface. ServiceAccessRequests are instantiated by a ServiceAccessRequestFactory. The LoginRequest can hold multiple Credentials to be passed for validation.
If there is no existing single sign on session, the CentralAuthenticationService login method is called first. The default implementation of the login method does the following:
1. Calls the PreAuthenticationPlugins to determine if the attempt to log in should continue (i.e. one can implement throttling here).
2. Delegate authentication to the AuthenticationManager via an AuthenticationRequest. There are multiple implementations of the AuthenticationManager, but they all have the same basic flow:
  1. For each of the credentials present, it will attempt to authenticate them via the traditional AuthenticationHandler.
  2. Successful authentication results in a CredentialsToPrincipalResolver being used to construct the principal and his or her attributes.
  3. AuthenticationMetaDataResolvers then attempt to extract information about the authentication.
  4. MessageResolvers attempt to locate any messages associated with an account (not necessarily with the principal). These messages may include things like password expiration, etc.
  5. All of this is constructed into an Authentication object via an AuthenticationFactory.
  6. An AuthenticationResponse is then returned whether the authentications were successful or not. If successful, they will contain the Authentications, the Principal, and any messages. Failure should return the failures as GeneralSecurityExceptions. All principals from the credentials MUST resolve to the same Principal.
3. The AuthenticationResponsePlugin is then called to perform some actions after authentication.
4. If the authentication was successful, a session is created.
5. Either way, a LoginResponse is returned. The response includes the session, any errors, and any messages.