Central Authentication Service (CAS)

Central Authentication Service (CAS) is an open-source platform that provides single sign-on (SSO) authentication for web applications and services. This means that users can log in once and gain access to multiple applications and services without having to provide their credentials multiple times. CAS is widely used in educational institutions and other organizations to simplify the process of accessing web-based resources.

Overview of CAS

CAS is based on the SAML specification and provides a centralized way to authenticate users. It is composed of two main components: the CAS server and the CAS client. The CAS server is responsible for authenticating users and providing them with a service ticket, which acts as proof of authentication. The CAS client is integrated into the web application or service and is responsible for requesting service tickets from the CAS server and validating them.

CAS Server

The CAS server is responsible for handling user authentication and issuing service tickets. It can authenticate users using a variety of methods, such as LDAP, Kerberos, and database authentication. CAS also supports multi-factor authentication (MFA) using different MFA providers such as google, yubikey, etc.

CAS uses a simple protocol to communicate with the CAS client. The client sends a request for a service ticket to the CAS server, which prompts the user to authenticate. Once the user has been authenticated, the CAS server issues a service ticket, which is sent back to the client.

CAS Client

The CAS client is integrated into the web application or service and is responsible for requesting service tickets from the CAS server and validating them. It is a simple library that can be added to any web application or service written in any programming language.

The CAS client uses the service ticket to request access to the protected resources of the web application or service. The CAS server validates the service ticket and, if it is valid, grants the client access to the protected resources.


CAS supports proxying, which allows a CAS service to act as a proxy for another service. This allows for a level of indirection, where the client authenticates to the CAS service, which in turn authenticates to the target service on behalf of the client. This can be useful in situations where the target service does not support CAS authentication directly, or where the client is not able to authenticate to the target service for some reason.

To use proxying, the CAS server and the target service must be configured to trust each other, and the client must request a proxy-granting ticket (PGT) from the CAS server. The PGT is then used to request a proxy ticket from the CAS server, which can be used to access the target service.

Delegated Authentication

CAS also supports delegated authentication, which allows a client to authenticate to a CAS service using a different authentication mechanism than the one provided by the CAS service. This can be useful in situations where the client has already authenticated to a different service, and wants to use that authentication to access a CAS-protected service.

Delegated authentication is accomplished using a special type of service ticket called a proxy-authenticating ticket (PAT). The PAT is issued by the CAS server after the client has authenticated to the delegated authentication service. The client can then present the PAT to the CAS server in order to request a service ticket for a CAS-protected service.


CAS provides support for Single Sign-Out (SLO) feature. It allows the user to log out of all the services at once rather than logging out of each service separately. Once user logs out of any of the service which is CAS enabled, it sends logout request to CAS server and CAS server in turn sends logout request to all other services where this user has logged in. In this way all the services that user has logged in, get logged out at once.

To enable Single Sign-Out feature on CAS server, you have to configure LogoutFilter, SingleSignOutFilter and SingleSignOutHttpSessionListener on your application server.

CAS Attributes

CAS also supports the release of user attributes, which can be used to carry additional information about the authenticated user. These attributes can be used by CAS clients to make authorization decisions, or to personalize the user experience. CAS attributes are returned in the form of key-value pairs, and can be requested as part of the CAS service ticket validation process.

Overall, CAS is a robust, flexible, and feature-rich solution for SSO authentication that can be easily integrated into any web application or service. While these features can be helpful depending on the use case and business requirement, but it is important to understand how to properly use and configure them.


Here is an example of how to add CAS authentication to a Java web application using the CAS client library −

import org.jasig.cas.client.authentication.AuthenticationFilter; import org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter; ... public class SecurityConfig extends WebSecurityConfigurerAdapter { @Autowired private CasProperties casProperties; @Autowired private CasAuthenticationProvider casAuthenticationProvider; @Override protected void configure(HttpSecurity http) throws Exception { http .addFilter(casAuthenticationFilter()) .addFilter(casValidationFilter()) .addFilterBefore(singleSignOutFilter(), CasAuthenticationFilter.class); } private AuthenticationFilter casAuthenticationFilter() { AuthenticationFilter filter = new AuthenticationFilter(); filter.setCasServerUrlPrefix(casProperties.getServerUrlPrefix()); filter.setServerName(casProperties.getServerName()); return filter; } private Cas20ProxyReceivingTicketValidationFilter casValidationFilter() { Cas20ProxyReceivingTicketValidationFilter filter = new Cas20ProxyReceivingTicketValidationFilter(); filter.setCasServerUrlPrefix(casProperties.getServerUrlPrefix()); filter.setTicketValidator(new Cas20ServiceTicketValidator(casProperties.getServerUrlPrefix())); filter.setAuthenticationUserDetailsService(new UserDetailsByNameServiceWrapper<>(new RemoteUserDetailsService(casProperties))); return filter; } private Cas20ServiceTicketValidator cas20ServiceTicketValidator() { return new Cas20ServiceTicketValidator(casProperties.getServerUrlPrefix()); } private AuthenticationUserDetailsService authenticationUserDetailsService() { return new UserDetailsByNameServiceWrapper<>(new RemoteUserDetailsService(casProperties)); } }

In this example, we are using the AuthenticationFilter and Cas20ProxyReceivingTicketValidationFilter classes from the CAS client library to handle the authentication and validation of service tickets. We also have additional classes like Cas20ServiceTicketValidator, authenticationUserDetailsService that are being instantiated.

We are also using a CasProperties bean, which contains configuration information for the CAS server and client. This allows us to easily configure the server URL prefix and server name for the authentication filter and the validation filter.

We also have added the filter singleSignOutFilter which will take care of the single sign-out feature and it will be added before CasAuthenticationFilter.


CAS is a powerful and widely-used solution for providing SSO authentication for web applications and services. It is easy to integrate into any web application or service and supports a variety of authentication methods and protocols. With the help of CAS, users can log in once and gain access to multiple applications and services without having to provide their credentials multiple times, this makes the system more secure, manageable and less prone to user errors.

Updated on: 16-Jan-2023


Kickstart Your Career

Get certified by completing the course

Get Started