skip to main content

Authentication & Authorization Services

Central Authentication Service (CAS)

CAS Architecture

A CAS server provides the following service URIs:

List of CAS URIs and their description
URI Description
/cas/ Redirects to /cas/login
/cas/login Login service
/cas/logout Logout service
/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)

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.

Diagram of steps in CAS authentication event

Preliminary Step: Service Provider CAS-enables their site

To rely on the CAS service for authentication, the Service Provider:

  • Registers the site with the CAS service.
  • Adds a CAS client to the core service code. CAS clients are available in many programming languages to allow the Service Provider to select one written in the same programming language used by their service.
  • 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. Possible redirect parameter customizations are reviewed in the next section.

Step 1: Subject attempts to access a CAS-protected Service Provider site

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.

http(s)://cas_server/cas/login?service=http(s)://your_server/yourApplication

Step 2: Subject logs in 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 the 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.

What is a cookie?

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:

  • An expiration timestamp for the cookie. Without an expires option, the cookie has a lifespan of a single session.
  • The domain to which the cookie should be sent. The default value for the domain option is the host name of the web site setting the cookie; a domain value specified in the Set-Cookie header must be part of the default value or it is ignored.
  • A path on the web server can be specified to further control when the cookie is sent. The default value for the path option is the path of the URL that sent the Set-Cookie header.
  • A secure flag indicating that the cookie is sent only when a request is made using SSL and the HTTPS protocol.

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:

  • CASTGC - the ticket granting cookie
  • csrftoken - use to protect against CSRF attacks
  • sessionid - the session cookie
  • CASMFA - the 2-factor trusted computer token

Step 4: CAS verifies Service Provider is registered

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 back to Service Provider site

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.

http(s)://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 to login process

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=http%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/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.