How CAS Works

As of June 28, 2017, there is a change to the CAS server’s behavior when manually entering URLs in a browser. The URL "https://auth.berkeley.edu/cas/login" when entered alone will no longer bring up a CAS login screen. One must also specify the ?service= parameter as part of the URL to test a CAS login. CAS client applications automatically specify this service parameter when redirecting the browser to the CAS server so that the CAS server can later send the browser back to the application's protected page following authentication.

To manually test your CAS/CalNetID login credentials, you could use or bookmark a hyperlink such as this: CAM

Adding the service parameter for a berkeley.edu site after the base login URL, for example, "https://auth.berkeley.edu/cas/login?service=http://www.berkeley.edu", will display the specified site following succesful authentication to the CAS server, also providing for a test of login credentials.

To get the most up-to-date information on how CAS works, please visit the Apereo CAS website and in particular the CAS documentation site.

The CAS protocol and web flow are decribed in the CAS Protocol page.

CAS web flow

https://apereo.github.io/cas/development/images/cas_flow_diagram.pngWeb flow diagram

  1. A user, via a web browser, requests a resource from a particular web application or service.
  2. The web application or service, via the application's security mechanism, determines if the user has already been authenticated (authN) and authorized (authZ) to use the application. It should be noted that all applications should implement local sessions for managing the interaction between the application and the user. If a user comes to the web application and the application does not know who the user is, then the application should redirect the user to the CAS server.
    1. If the user has a local session, authN and authZ, then the user can have access to the resource which was requested and the flow ends here.
    2. If the user does not have a local session, then the web application should check to see if the URL contains a CAS ticket. If the URL does not contain a CAS ticket, then the web application needs to redirect the browser to the CAS server with the return service URL as a ?service= argument so that the user can get a ticket and return. For example:https://auth.berkeley.edu/cas/login?service=https://myservice.berkeley.edu/myapp
  3. Once the user's browser gets to CAS, CAS looks to see if the user has already authenticated with CAS. It does this by looking to see if the browser sent a CAS cookie with the request. If the user does not have a cookie because they have not already authenticated, then CAS displays the login screen. See Re-authentication or renew=true for information about the renew=true protocol option which forces CAS to request credentials regardless of the presence of the CAS cookie.
  4. Upon successful authentication, CAS will look up the user in the CalNet LDAP directory and store the user's CalNet UID in its memory for future reference. After it has done this, it will set a CAS ticket granting cookie (TGC) in the user's browser, and then redirect the user back to the original service with a ticket. For example:

    https://myservice.berkeley.edu/myapp?ticket=QQIMux0k2Em

    This ticket is only valid for the service to which CAS redirects the browser, and can only be used once. Also, the ticket has a limited lifespan (about 12 s) and is tied to the UID mentioned above.
  5. Once back at the application, the security component of the web application again checks for a valid session. This time, however, the web application sees that the URL has a ticket. At this point, the web application needs to take that ticket and verify with CAS that it is a legitimate ticket. Using the CAS protocol 3.0 endpoint, for example:

    https://auth.berkeley.edu/cas/p3/serviceValidate?service=https://myservice.berkeley.edu/myapp&ticket=QQIMux0k2Em

    Here, the web application makes an HTTP request which must be over TLS to the CAS server.
  6. When CAS receives this request, it validates the ticket with the following two tests:
    1. Is this the first time this ticket is being presented back to CAS?
    2. Is the ticket actually valid for the service listed in the URL?
  7. If both tests are true, then CAS looks up the UID that is associated with the ticket and responds back to the application with a success response and includes the UID of the user, and optionally with protocol 3.0, any allowed attributes. If either test is false, CAS responds back to the application with a failure response.
  8. The web application needs to parse the response and determine if it should let the user have access to the resource originally requested.

If the web application only requires that the user has successfully authenticated with CAS, then the application can create a local session for the user, and allow the user to continue onto the resource requested. If the web application needs to do further verification of the user's identity to authorize access, then the web application, via its support for the SAML 1.1 or CAS 3.0 protocols, can examine any additional attributes that the CAS server asserts for the authenticated principal subject.

For a more in-depth look at how the above works, please read the official Apereo CAS protocol documentation.

CAS Login and Logout

Please see the CAS Login and Logout Scenarios page.

CAS Authentication Overview

For an overview of simple authentication with CAS, see: CAS Authentication Overview

CAS Proxy Authentication

Proxy authentication starts out just like regular CAS authentication, but instead of just validating a service ticket (ST), the web application also asks for a proxy ticket. Also, the application tells CAS where to send the Proxy Granting Ticket IOU (PGTIOU) and the Proxy Granting Ticket ID (PGTID). For example:


https://auth.berkeley.edu/cas/serviceValidate?ticket=ST-956-Lyg0BdLkgdrBO9W17bXS &service=http://localhost/bling&pgtUrl=https://localhost/pgtCallback

Notice the &pgtUrl= part. This is what CAS calls a Call-Back URL. This URL can be on the same application, and, in fact, this is how most CAS clients that implement proxy authentication, work.

Along with responding to your request, CAS will send a GET request to the call-back URL which you specified with &pgtUrl= parameter.

Your application now has to contact the call-back URL and get the PGTID by passing it the PGTIOU. Any CAS client that supports proxy authentication will do this step. Refer to the CAS Proxy Authentication figure below:

CAS Proxy Authentication

See also this PPT presentation CAS Proxying and Web Services by Joseph Mitola.

Additional information about proxy authentication is found in the CAS project's Proxy Authentication and CAS Protocol documents.

Shim-based Authentication: AuthCAS or mod_auth_cas

Please see A shim based approach to authentication using CAS by Erik Klavon.

CAS Availability

The CAS service is made highly available so that both on-premises and public cloud applications may rely on it.  This is accomplished via both load balancing and DNS failover.

In a scenario where DNS failover occurs, there will be up to a 90 second delay before client requests are routed to a different physical location.  After that users will be required to re-authenticate to their applications.

Under normal conditions an application that depends on CAS will follow a flow similar to the following.

  1. A CAS client attempts to authenticate.
  2. The berkeley.edu DNS resolvers at either San Diego or Berkeley return a referral to offsite resolvers.
  3. The client queries the offsite resolvers are and given the IP address of the Berkeley VIP because it is configured as the primary in a failover pair.
  4. The client's request will go to the VIP at UC Berkeley.
  5. Traffic will be load balanced to a cluster of servers.

In the case where the Berkeley data center is unavailable the health checks configured in our hosted zone will mark Berkeley as unavailable and return the virtual IP of the CAS cluster in San Diego.

  1. A CAS client attempts to authenticate, the DNS client will use a name server at San Diego.
  2. The berkeley.edu DNS resolvers at San Diego return a referral to offsite resolvers.
  3. The client queries the offsite resolvers are and given the IP address of the San Diego VIP because it is configured as the secondary in a failover pair.
  4. The client's request will go to the VIP at San Diego.
  5. Traffic will be load balanced to a cluster of servers.