TL;DR
Central Authentication Service (CAS) is an open-source single sign-on (SSO) protocol that lets users authenticate once on a trusted central server to access multiple web applications. It separates authentication (verifying identity) from authorization (granting privileges), improving security by keeping passwords hidden from individual apps. CAS is valued for its convenience, consistency, and reduced maintenance burden across large application networks.
How does central authentication service (CAS) work?
Login credentials are only used once for multiple applications for authentication without revealing the secure password. The application requiring authorization will redirect a user to a centralized 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 authorizing one. Authorization 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.
CAS can provide an SSO solution for multiple web applications to provide a more seamless end-user experience. The centralized authentication server, the CAS server, is a trusted source that can be used for authentication purposes.
The CAS protocol and authorization 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 centralized 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 Hypertext Transfer Protocol (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 (including Flask and Django) — use the python-cas library
- PHP — use the phpCAS library
- PL/SQL
Which client libraries are available for CAS integration?
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.
What is the difference between authentication and authorization?
Authentication and authorization are not the same thing.
How does CAS handle authentication without authorization?
The CAS protocol merely authenticates users' access to web applications and does not serve to authorize 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.
How do you set up authorization separately?
You will have to determine and set up in the system the users who have authorization 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 authorization.
In short, authentication verifies a user's identity, while authorization verifies what specific access to data and privileges a user has. Your system will require both authentication and authorization. The CAS service only provides the authentication piece, and authorization will need to be implemented on another layer as well.
| Authentication | Authorization |
|---|---|
| Verifies a user's identity (who the user is) | Verifies what specific access to data and privileges a user has |
| Handled by the CAS server | Must be configured separately within each application |
| Passwords are hidden from individual web applications | Specific user IDs can be granted roles such as "administrator" privileges |
What are the benefits of using 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.
How does CAS simplify long-term maintenance?
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 centralized 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 centralized and trusted location.
Frequently asked questions
What is the difference between Central Authentication Service (CAS) authentication and application-level authorization?
CAS verifies who a user is (authentication) but does not control what that user can access within an application (authorization). Authorization must be configured separately within each application.
Does a user need to log in again when switching between applications in a Central Authentication Service (CAS) session?
No. Once a user authenticates on the CAS server, a cookie or session data is set. Subsequent application access is handled on the back end without requiring the user to re-enter credentials.
What happens if a service ticket is invalid?
The application sends the service ticket to the CAS server for validation. If the ticket is not valid, the user will not be authenticated and access to the application will be denied.
Which programming languages and libraries support Central Authentication Service (CAS) integration?
CAS supports many languages including Java, Python, PHP, and PL/SQL. For PHP, the phpCAS library is available; for Python (including Flask and Django), the python-cas library is recommended.
Is the Central Authentication Service (CAS) protocol open-source?
Yes, the CAS protocol is open-source and publicly available, with documentation and getting-started guides provided by the Apereo Foundation.
How does Central Authentication Service (CAS) improve security compared to application-specific login systems?
CAS improves security because individual web applications never have direct access to a user's login credentials or passwords. Authentication is handled entirely on the centralized CAS server.
References
Central Authentication Service. Microsoft Academic.
CAS Enterprise Single Sign-On. Apereo Foundation.
Python-cas/ Python-cas. (2021). GitHub, Inc.
Getting Started. Apereo Foundation.
