Single Sign On with CAS (Central Authentication Service)
Central Authentication Service, which is usually referred as CAS, is a simple, yet powerful ticket-based single sign-on (SSO) protocol designed for the web. Just like any other SSO protocol, CAS allows a user to access multiple applications by providing the user credentials to a central authentication server (CAS server) only once.
The CAS authentication flow mainly involves two parties. Before going into further details about the CAS authentication flow, let’s identify those parties.
CAS Server : This is a standalone component that authenticates the users and grant access to the applications that utilize CAS service (CASified applications).
CAS Client : This is a software component embedded in a web application that utilizes CAS service. CAS client is responsible for protecting the web application and retrieving the identity of the authenticated users from the CAS server.
Now that we know the main parties involved in CAS authentication process, let’s have a look at how these parties interact with each other.
The CAS clients interact with the CAS server via CAS protocol. The following diagram illustrates the message flow of the CAS SSO process.
1 : User tries to access a CASified app called “sample-app”.
2 : Browser sends a GET request to “https://sample-app.com/”.
3, 4 : Access to the app is not authorized yet, so redirected to the CAS server for authentication.
5 : Since this is the first access, the user does not have an SSO session. Hence server requests the user to login.
6 : The login form is displayed to the user.
7, 8 : User submits the login credentials. Username and password are sent as a POST request to the CAS server.
9 : CAS server authenticates the user. If the authentication is successful, server creates an SSO session with a ticket granting cookie. This cookie contains a Ticket Granting Ticket (TGT) which represents the SSO session for a user.
10 : The browser sends a GET request to the app along with a Service Ticket. This service ticket stands for the access granted to the CAsified app for a particular user.
11 : Now the protected app needs to validate the service ticket. Hence it sends a GET request to the CAS server along with the service ticket to get it validated.
12 : CAS server validates the service ticket, and returns a response indicating the validation success, authenticated subject, and optionally the additional claims. These information are returned as an XML content.
13 : Now a session cookie is set, and a redirection happens back to the app to avoid the service ticket from being displayed in the address bar. Finally, the content of the CASified app is displayed to the user.
This is the steps in the CAS authentication flow during the first access to a CASified app by a user.
When trying to access the same CASified app for the second time, the resource request contains the session cookie created previously. Hence, the user is granted access to the resource after validating the session cookie. So, it is not required to log in again.
When accessing a second CASified app by the same user, steps 1,2,3 happen as explained above. However, when the browser redirects to the CAS server for authentication, the request contains the Ticket Granting Ticket which represents the SSO session for a user. The CAS server can validate the TGT, so it is not required to log in again. The other steps are similar as explained above. This is how CAS Single Sign On works.
If you want to try out the CAS flow and see how it works in action, you can use the WSO2 Identity Server CAS Inbound Authenticator. You can download WSO2 Identity Server from the below link.
The CAS authenticator is available as a connector in WSO2 Identity Server Connector Store.
You can find more about CAS authenticator of WSO2 Identity Server through the link below:
References :
[1] https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol-Specification.html
[2] https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol.html
