How CAS Works | CalNet (2024)

CAS web flow

https://apereo.github.io/cas/development/images/cas_flow_diagram.png

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.SeeRe-authentication or renew=truefor information about the renew=trueprotocol 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 theCAS Login and Logout Scenariospage.

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:

Notice the&pgtUrl=part. This is what CAS calls aCall-BackURL. 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.

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

Additional information about proxy authentication is found in the CAS project'sProxy AuthenticationandCAS Protocol documents.

Shim-based Authentication: AuthCAS or mod_auth_cas

Please see A shim based approach to authentication using CASby 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.