A CAS server provides the following service URIs:
|/cas/||Redirects to /cas/login|
|/cas/validate||CAS 1.0 service ticket validation URI|
|/cas/serviceValidate||CAS 2.0 service ticket validation URI|
|/cas/proxyValidate||CAS 2.0 service ticket and proxy ticket validation URI|
|/cas/proxy||CAS 2.0 proxy ticket service|
|/cas/p3/serviceValidate||CAS 3.0 service ticket validation URI|
|/cas/p3/proxyValidate||CAS 3.0 service ticket and proxy ticket validation URI|
|/cas/samlValidate||SAML service ticket validation URI (Jasig CAS feature, not in CAS protocol)|
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.
To rely on the CAS service for authentication, the 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.
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.
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.
A cookie is a small text file that is stored by a browser on the Subject's machine. Cookies are plain text; they contain no executable code.
A cookie is created when a web server sends an HTTP response containing a Set-Cookie header to the browser. Anytime the browser accesses a page on the web server after the cookie is created, the cookie value will be included in the request.
A Set-Cookie header at a minimum contains the cookie value. The value can be assigned a name using the cookieName=cookieValue syntax. In addition to the value, a Set-Cookie header may contain:
The Ticket Granting cookie created by CAS stores the Ticket Granting Ticket value. The domain is allowed to default to the web server hosting the CAS service, but the path is set to '/cas' rather than being allowed to default to '/cas/login' so that the Ticket Granting Ticket value will be sent to any of the CAS URIs. The secure flag is set to ensure the Ticket Granting Ticket value is sent only via an encrypted connection.
The full list of cookies that can be created and stored by the CAS server are:
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.
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.
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.
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.
The Service Provider's CAS client may include one or more of the following parameters: