CAS Architecture

A CAS server provides the following service URIs:

Basic Authentication Scenario

The illustration below outlines the basic steps in a successful CAS authentication event. For a comprehensive description of CAS features, please review the Central Authentication Service protocol documentation.

Preliminary Step: Service Provider CAS-Enables Site

• Register the site with the CAS service.
• Add a CAS client to the core service code.
• Configure the CAS client, specifying the portion of the site to be CAS-protected, and any parameter values to be included in the redirect to the CAS service.

Step 1: Subject Browses To CAS-protected Service Provider

When a Subject navigates to a CAS-protected Service Provider site, the Service Provider's CAS client redirects the Subject's browser to the CAS service /cas/login URI. The identifier for the Service Provider is included as a parameter so that CAS knows which Service Provider is requesting authentication.

https://cas_server/cas/login?service=https://your_server/yourApplication

Step 2: Subject Authenticates To CAS

The first time a Subject is redirected to /cas/login, CAS will respond by displaying a login screen, requesting the Subject's Credentials. When the Subject enters his Credential, the login form submits the Credential to /cas/login using the HTTP POST method.

Step 3: CAS Validates Credential

CAS submits the Credential to the Credential Store for verification. If the Credential is valid, CAS retrieves a set of attributes about the Subject to be included in the response to the Service Provider site. CAS uses the attributes to create a Ticket Granting Ticket which it stores in a cookie on the Subject's browser.

Step 4: CAS Verifies Service Provider

After the Subject successfully authenticates, CAS compares the value of the service parameter to the list of Service Provider sites in the CAS service registry. If the value matches an entry in the registry, CAS proceeds to the next step. Otherwise, CAS displays an error informing the Subject that the Service Provider site is not eligible to use CAS for authentication.

Step 5: CAS Generates Service Ticket & Redirects Browser

For a legitimate service, CAS creates a Service Ticket and redirects the Subject's browser back to the service URL, including the Service Ticket as a parameter in the URL.

https://your_server/yourApplication?ticket=ST-9781-123cvUwGGkp980

Step 6: Service Provider Validates Service Ticket

The Service Provider's CAS client starts a new connection to /cas/serviceValidate or /cas/p3/serviceValidate including the Service Ticket in the connection string. CAS verifies that the Service Ticket is valid (the Service Ticket value exists in CAS database, the Service Ticket is less than 2 minutes old, and the Service Provider site validating the ticket is the site that was sent the ticket). If the Service Ticket is valid, CAS responds with the Subject's username and any additional Subject attributes the Service Provider is authorized to receive.

After Initial Authentication Event

If the Subject attempts to access a different CAS-protected Service Provider site, the second site will once again redirect the Subject's browser to /cas/login URL as described in Step 1 above.

When the browser attempts to access the /cas/login site, the Ticket Granting Ticket previously stored in a cookie on the Subject's browser by the CAS service is included in the request. CAS checks the validity of the Ticket Granting Ticket by verifying the ticket value is present in its database and that the Ticket Granting Ticket has been used in the last 6 hours.

If the Ticket Granting Ticket is valid, CAS considers the Subject to be authenticated and skips Steps 2 and 3 as outlined above. If the Ticket Granting Ticket is invalid, CAS completes all the steps listed above.

Service Provider Modifications

The Service Provider's CAS client may include one or more of the following parameters:

• service - The Service Provider identifier, usually the URL of the Service Provider site. CAS will redirect the Subject back to the URL upon completion of a successful authentication event. Example: https://server/cas/login?service=https%3A%2F%2FmySite.edu If this parameter is not included, CAS displays a message notifying the Subject that they have successfully logged in.

• renew - Boolean value indicating whether or not the Service Provider wants to bypass Single Sign-On. This value is defaulted to False, so the renew parameter is required only when it should be set to True. When set to False, CAS checks for an existing Single SignOn session (managed using the cookie storing the Ticket Granting Ticket) for the Subject. Only when the Subject does not have an active Single SignOn session does CAS require a Credential to be presented.

  When set to True, CAS requests a Credential to be presented regardless of whether or not an active Single Sign-On session exists. Example: https://server/cas/login?service=http%3A%2F%2FmySite.edu&renew=true

• gateway - Boolean value indicating whether or not the Service Provider wants CAS to only check for a Single-Sign On session. This value is defaulted to False, so the gateway parameter is required only when it should be set to True.

When set to False, CAS checks for an existing single sign-on session for the Subject. If the Subject does not have an active Single Sign-On session, CAS will prompt the Subject for a Credential. When set to True, CAS checks for an existing Single Sign-On session for the Subject.

• If a Single Sign-On session exists, CAS creates a Service Ticket and redirects the Subject's browser back to the service URL, including the Service Ticket as a parameter in the URL.

• If a Single Sign-On session does not exist, CAS redirects the Subject's browser back to the Service Provider URL without requesting a Credential to be presented and/or including a Service Ticket.

Example: https://server/cas/login?service=http%3A%2F%2FmySite.edu&gateway=true

The gateway parameter is used for landing pages, where the Subject is not required to be authenticated to view content. This parameter allows sites to customize page content depending on whether or not a Single Sign-On session exists.