Central Authentication Service (CAS) Protocol Explained

Okta's cloud-based authentication gives users high-assurance with simple-to-use factors like biometrics and push notifications.

Updated: 09/12/2024 - 10:56

Time to read: 6 minutes

Central authentication service, or CAS, is a single sign-on (SSO) protocol that allows websites to authenticate users.

Login credentials are only used once for multiple applications for authentication without revealing the secure password. The application requiring authorisation will redirect a user to a centralised trusted single server, the CAS server.

The CAS protocol can be used to authenticate untrusted web applications requiring a service ticket for access. CAS is a tool to authenticate a user, but this is not the same as authorising one. Authorisation is specific to the actual application.

The CAS approach can be simple to maintain and distribute to a large network of computers after the initial configuration. It can offer users convenience, consistency, and a high level of security.

Understanding central authentication service (CAS)

CAS can provide an SSO (single sign-on) solution for multiple web applications to provide a more seamless end-user experience. The centralised authentication server, the CAS server, is a trusted source that can be used for authentication purposes.

The CAS protocol and authorisation flow looks like this:

A user attempts to access a web application that is not already verified. This is the first time attempting to access a CASified application (web application using the CAS service).
The user is redirected to the CAS server.
The user then inputs their login credentials one time on the CAS server, and the CAS server determines if the user is authentic.
Once the user is authenticated through the CAS server, a service ticket is attached to the URL.
The application then sends a request to the CAS server, validating the service ticket. If the ticket is valid, the user is authenticated and returned back to the application.

With CAS, the user does not have to repeat this process when toggling between applications within a single sign-on session. Once the user signs in to the centralised authentication system, a cookie or system data is set to indicate authentication status without need for re-authentication multiple times in the same session

Key components of CAS

The CAS protocol and authentication flow involves three (or four) parties.

Client web browser: This is software that is embedded into the web application using the CAS service.
Web application: This is the application seeking authentication.
CAS server: This is the standalone component used to authenticate users and grant access to web applications using the CAS service.
Back-end service: CAS protocol can also involve a database server that does not have its own HTTP interface but still can communicate with a web application.

CAS refers to a software package that also uses the CAS protocol.

How to use CAS in your website

To integrate applications with the CAS protocol, you will first designate your CAS server. Everyone seeking authentication for these applications will need to have a login on the CAS server. CAS can be integrated into virtually any web application and supports a multitude of programming languages, including Java, Python, PHP, and PL/SQL.

There are also many different client libraries available that can authenticate using CAS. For PHP, you can use the phpCAS library. For Python, which includes Flask and Django, the python-cas library is optimal. If you are using a different language, you can institute a search for existing libraries.

The CAS protocol is open-source and publicly available. For more information on the inner workings of the CAS protocol and how to implement it, check here.

Authentication vs. authorisation

Authentication and authorisation are not the same thing.

The CAS protocol merely authenticates users’ access to web applications and does not serve to authorise users. When a user logs in to the CAS server with their login credentials, the CAS authentication will determine who the user is, documenting who is logging in, but the application will not “see” the password and login information directly.

You will have to determine and set up in the system the users who have authorisation access and privileges within the application. For example, you can set specific user IDs to have “administrator” privileges that will allow them to read and write within specific files. This is a form of authorisation.

In short, authentication verifies a user’s identity, while authorisation verifies what specific access to data and privileges a user has. Your system will require both authentication and authorisation. The CAS service only provides the authentication piece, and authorisation will need to be implemented on another layer as well.

Benefits of CAS

The CAS protocol has many benefits for use, which include the following:

Convenience: Users only need to log into the CAS server one time during a session to access multiple web applications without the need for additional logins.
Consistency: Every user has the same login page on the CAS server.
Less effort needed for applications: Web applications do not need to have or continue to invent their own authentication infrastructure and processes.
Security: Web applications do not have access to the login credentials or passwords.

The CAS protocol can take a little extra time to set up initially, but it can provide an end-user experience that has less friction. It can also be easier to maintain over time, as there is a centralised server to deal with in one system instead of managing authentication processes within each individual web application.

You do not have to embed authentication protocols one at a time. Instead, you can manage multiple web applications, including webmail servers and webmail clients, in one centralised and trusted location.

Key takeaways

The CAS protocol is a single sign-on open-source service that allows users to sign in to one trusted server one time in a session and still be able to access multiple applications without signing in over and over again. This can increase productivity, speed, and the end-user experience.

The CAS protocol involves a trusted and centralised CAS server that all users will log into directly. Once logged in, the system will “remember” the user for the rest of the session by using cookies.

When a user attempts to access a web application that requires authorisation, they are initially redirected to the CAS server for authorisation. If authorised, a service ticket is attached to the URL. When a user accesses another web application, the authorisation is handled on the back end, and the user does not even have to be involved.

The CAS protocol is secure, hiding passwords from the web applications. It is also convenient and user-friendly.