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.

Pre-requisites:

1. Apache tomcat is installed and running

2. Java(JDK) is installed.
Guide:

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

(Start->Run->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)

<dependency>
             <groupId>${project.groupId}</groupId>
             <artifactId>cas-server-support-ldap</artifactId>
             <version>${project.version}</version>
        </dependency>

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)

<bean id="contextSource" class="org.jasig.cas.adaptors.ldap.util.AuthenticatedLdapContextSource">

              <property name="pooled" value="true"/>

              <property name="urls">

                  <list>

                      <value>ldap://localhost:10389</value>

                  </list>

              </property>

              <property name="userName" value="uid=admin,ou=system"/>

              <property name="password" value="secret"/>

              <property name="baseEnvironmentProperties">

                  <map>

                      <entry>

                          <key>

                              <value>java.naming.security.authentication</value>

                          </key>

                          <value>simple</value>

                      </entry>

                  </map>

              </property>

        </bean>

7.      Add the corresponding AuthenticationHandler to the deployerConfigContext.xml file (Remove the SimpleAuthenticationHandler) and Add the following in it’s place

<bean

            class="org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler" >

                                <property name="filter" value="uid=%u,ou=system" />

                                <property name="contextSource" ref="contextSource" />

            </bean>

(more)

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/

phpCAS

A simple CAS client

phpCAS can be used the simplest way, as a CAS client (example_simple.php):

<?php

//
// phpCAS simple client
//

// import phpCAS lib
include_once('CAS.php');

phpCAS::setDebug();

// initialize phpCAS
phpCAS::client(CAS_VERSION_2_0,'sso-cas.univ-rennes1.fr',443,'');

// no SSL validation for the CAS server
phpCAS::setNoCasServerValidation();

// force CAS authentication
phpCAS::forceAuthentication();

// at this step, the user has been authenticated by the CAS server
// and the user's login name can be read with phpCAS::getUser().

// logout if desired
if (isset($_REQUEST['logout'])) {
	phpCAS::logout();
}

// for this test, simply print that the authentication was successfull
?>
<html>
  <head>
    <title>phpCAS simple client</title>
  </head>
  <body>
    <h1>Successfull Authentication!</h1>
    <p>the user's login is <b><?php echo phpCAS::getUser(); ?></b>.</p>
    <p>phpCAS version is <b><?php echo phpCAS::getVersion(); ?></b>.</p>
    <p><a href="?logout=">Logout</a></p>
  </body>
</html>

Run-time behaviour configuration

When setting up a CAS proxy client, some runtime behaviour can be easily configured.

Language (example_lang.php)

<?php

//
// phpCAS simple client configured with another language
//

// import phpCAS lib
include_once('CAS.php');

// initialize phpCAS
phpCAS::client(CAS_VERSION_2_0,'sso-cas.univ-rennes1.fr',443,'');

// no SSL validation for the CAS server
phpCAS::setNoCasServerValidation();

// set the language to french
phpCAS::setLang(PHPCAS_LANG_FRENCH);

// force CAS authentication
phpCAS::forceAuthentication();

// at this step, the user has been authenticated by the CAS server
// and the user's login name can be read with phpCAS::getUser().

// moreover, a PGT was retrieved from the CAS server that will
// permit to gain accesses to new services.

// for this test, simply print that the authentication was successfull
?>
<html>
  <head>
    <title>Exemple d'internationalisation de phpCAS</title>
  </head>
  <body>
    <h1>Authentification r&eacute;ussie&nbsp;!</h1>
    <p>L'utilisateur connect&eacute; est <b><?php echo phpCAS::getUser(); ?></b>.</p>
    <p>La version de phpCAS est <b><?php echo phpCAS::getVersion(); ?></b>.</p>
  </body>
</html>

HTML output (example_html.php)

<?php

//
// phpCAS simple client with HTML output customization
//

// import phpCAS lib
include_once('CAS.php');

// initialize phpCAS
phpCAS::client(CAS_VERSION_2_0,'sso-cas.univ-rennes1.fr',443,'');

// no SSL validation for the CAS server
phpCAS::setNoCasServerValidation();

// customize HTML output
phpCAS::setHTMLHeader('
<html>
  <head>
    <title>__TITLE__</title>
  </head>
  <body>
  <h1>__TITLE__</h1>
');
phpCAS::setHTMLFooter('
    <hr>
    <address>
      phpCAS __PHPCAS_VERSION__,
      CAS __CAS_VERSION__ (__SERVER_BASE_URL__)
    </address>
  </body>
</html>
');

// force CAS authentication
phpCAS::forceAuthentication();

// at this step, the user has been authenticated by the CAS server
// and the user's login name can be read with phpCAS::getUser().

// for this test, simply print that the authentication was successfull
?>
<html>
  <head>
    <title>phpCAS simple client with HTML output customization</title>
  </head>
  <body>
    <h1>Successfull Authentication!</h1>
    <p>the user's login is <b><?php echo phpCAS::getUser(); ?></b>.</p>
    <p>phpCAS version is <b><?php echo phpCAS::getVersion(); ?></b>.</p>
  </body>
</html>

(more)

Background for Developers

How does the user navigate between CAS and your application

In order to reach CAS and then your application, a URL must be provided to the browser with a service parameter. The service parameter would be the login location of your application. This would usually be done as a redirect from an application requiring login. For instance, to enter the application https://www.ucalgary.ca/itutil?process=CASMenu with a CAS ticket, the browser would need to open CAS with https://cas.ucalgary.ca/cas/login?service=https://www.ucalgary.ca/itutil?process=CASMenu

When successfully authenticated, the user’s browser will be redirected back with a ticket parameter

https://www.ucalgary.ca/itutil?process=CASMenu&ticket=ST-18988-Ka7nKVnuFQ8s2kScT6WC

Ticket authentication and possible service points

Your application can validate a ticket using a few different service URLs on the CAS server depending on the data you need and the client API you are using. To avoid rewriting basic partsin code, a number of client API’s are available for general download at http://www.ja-sig.org/products/cas/client/index.html with the Java API being the most mature. There is also a local custom client API for .Net developers which can be requested from cas@ucalgary.ca. In addition you can write your own client API that makes an https request and parses the response. These are the service points available for validating CAS tickets with example responses. The examples show sample responses for eid e.pilgrim with a username of epilgrim. (more)

Blogs reaction on CAS

CAS JDBC Service registry trouble

mod-auth-cas and slow logins

OpenID Server Integrated with CAS

To Cluster or Not to Cluster CAs

[wikipedia.org]
[http://www.ja-sig.org]
[http://www.yale.edu/its/]
[http://www.unicon.net/opensource/cas]
[http://www.ucalgary.ca/it/help/articles/3054]