Skip to main content

Architecture

Parts of the CAS protocol & server architecture are documented here for ease of use.

Authentication Flow​

For a comprehensive description of CAS features, please review the Central Authentication Service documentation.

  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

  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.

  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.

  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.

  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

  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.

Notes After Initial Authentication​

  • 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.

Service URI Reference​

CAS uses several common URIs in the protocol. Texas A&M's implementation has unique values for development and production environments.

URIDescription
/casRedirects to /cas/login
/cas/loginLogin service
/cas/logoutLogout service
/cas/validateCAS 1.0 service ticket validation URI
/cas/serviceValidateCAS 2.0 service ticket validation URI
/cas/proxyValidateCAS 2.0 service ticket and proxy ticket validation URI
/cas/proxyCAS 2.0 proxy ticket service
/cas/p3/serviceValidateCAS 3.0 service ticket validation URI
/cas/p3/proxyValidateCAS 3.0 service ticket and proxy ticket validation URI
/cas/samlValidateSAML service ticket validation URI (Jasig CAS feature, not in CAS protocol)