Central Authentication Service – CAS: concepts and examples
The Central Authentication Service (CAS) is a single sign-on protocol for the web. Its purpose is to permit a user to log into multiple applications simultaneously and automatically. It also allows untrusted web applications to authenticate users without gaining access to a user’s security credentials, such as a password. The name CAS also refers to a software package that implements this protocol.
The Central Authentication Server (CAS) is designed as a standalone web application. It is currently implemented as several Java servlets and runs through the HTTPS server on secure.its.yale.edu. It is accessed through three URLs described below: the login URL, the validation URL, and the optional logout URL.
To use the central authentication service, an application redirects its users, or simply creates a hyperlink, to the login URL, which for general-purpose Yale users is https://secure.its.yale.edu/cas/servlet/login. Users may also access this URL manually if they wish to pre-authenticate their sessions.
The login URL handles actual, “primary” authentication. That is, it prompts the user for a NetID and a password and validates the pair against Yale’s Kerberos server. (More specifically, it determines whether or not it can decode a Kerberos IV ticket-granting ticket for the given NetID with a given password; if it can, it accepts the pair and throws away the ticket.) To allow for the possibility of automatic re-authentication later, the CAS also attempts to send an in-memory cookie (one that expires automatically when the browser closes) back to the browser. This cookie, which we call a “ticket-granting cookie,” identifies the user as one who has already logged in successfully. (more)
Why Adopt CAS?
While the most prominent appeal of CAS that is centralizes the user login implementation and experience, there are many other advantages, including these listed below.
- Participating applications do not touch the end user’s password, and therefore cannot expose this password if they are compromised
- Offers features for proxy authentication
- Ability to enforce uniform enterprise authentication and authorization policies across the system
- End to end user audit sessions to improve security reporting and auditing
- Removes application developers from having to understand and implement identity security in their applications
- Usually results in significant password help desk cost savings
How to get CAS up quickly in Windows
This tutorial is to demonstrate how to get CAS up quickly in Windows -> and testing it works.
1. Apache tomcat is installed and running
2. Java(JDK) is installed.
1. Download Apache directory server from http://directory.apache.org/
Run the setup with all the defaults and test that the server is working on localhost (default is port 10389)
Alternatively you can test with telnet
In the telnet console, type open localhost 10389 -> if you get a screen that lets you type (Apache Directory is configured properly), close telnet if you get this screen
2. Download the CAS installation and find the war file e.g. \cas-server-3.2.1\modules\cas-server-webapp-3.2.1.war
3. Start the Tomcat server, and after it is started..add the war file (cas-server-webapp-3.2.1.war) to the webapps folder e.g. C:\apache-tomcat-6.0.14\webapps\cas-server-webapp-3.2.1.war
Now that CAS is deployed you should have an unpacked directory in your webapps folder e.g. C:\apache-tomcat-6.0.14\webapps\cas-server-webapp-3.2.1
4. Stop the tomcat server
5. Now you have to add the following to the pom.xml file in the META-INF folder (e.g. C:\apache-tomcat-6.0.14\webapps\cas-server-webapp-3.2.1\META-INF\maven\org.jasig.cas\cas-server-webapp)
6. Add the following to the deployerConfigContext.xml file in the WEB-INF directory e.g. C:\apache-tomcat-6.0.14\webapps\cas-server-webapp-3.2.1\WEB-INF (Connects to the default Apache Directory Server configuration)
7. Add the corresponding AuthenticationHandler to the deployerConfigContext.xml file (Remove the SimpleAuthenticationHandler) and Add the following in it’s place
Acegi as CAS Client
The Spring Framework is a popular, layered Java/J2EE application framework, with features including powerful JavaBeans-based configuration management; generic abstraction for transaction management; JDBC abstraction layer; integration with Hibernate, JDO and iBATIS SQL Maps; rich AOP functionality; and a flexible web MVC framework. Spring provides packages that assist in building complex web applications, web services endpoints, and Swing-based rich clients.
The Acegi Security System for Spring provides a wide range of security services for Spring-based applications, including method interception, web request interception and redirection, and rich client (Swing) integration. Acegi Security maintains packages which provide full integration with CAS. The packages also allow (but do not require) Acegi Security’s AuthenticationProviders – which include JDBC, in-memory and JAAS wrapper providers – to be used as CAS PasswordHandlers, easing migration from stand-alone Acegi Security applications to a CAS-managed environment.
Ruby on Rails CAS Client
A Ruby implementation of the CAS client is now available at http://rubyforge.org/projects/rubycas-client/
The library is designed to easily integrate with Rails as an ActionController filter, but may be adapted for other purposes. The easiest way to install the client is via ruby gems, by typing the following at a shell prompt (you will probably need root access):
gem install rubycas-client
It can also be installed into a Rails application as a plugin:
script/plugin install http://rubycas-client.googlecode.com/svn/trunk/rubycas-client
Documentation and example usage is available at http://rubycas-client.rubyforge.org/
A simple CAS client
phpCAS can be used the simplest way, as a CAS client (example_simple.php):
When setting up a CAS proxy client, some runtime behaviour can be easily configured.
HTML output (example_html.php)