Yale CAS Customizations

Generally speaking, one should try not to make modifications to off the shelf software. However, the advantage of Open Source software is that you have access to the source code if you need it. Sometime a single line change to the source accomplishes quickly something that could otherwise only be done with weeks or months of trial and error through the poorly documented Spring Configuration. Sometimes Yale has special needs for which the JASIG code has no solution.

The good news is that CAS has a logical modular design based on well defined, if sometimes poorly documented, interfaces. If you understand the architecture of Authentication Managers, Authentication Handlers, Credential to Principal Resolvers, and Ticket Caches, then you can create your own implementation of any specific interface and generate custom code that will easily migrate to new releases.

There are several problems that trigger a need for customization:

Yale Production Services runs Java applications under JBoss. CAS was designed to run under the simpler Tomcat. This can produce a conflict in the Maven POM configuration file between the Version number of a dependency JAR library that was used to develop a particular release of CAS and a different Version number of the same library that was embedded in the version of JBoss you are deploying CAS under. So the standard JASIG POM has to be tweaked to change the version number and to mark certain libraries as "provided by the container" rather than as a library to be included with the application.

CAS added a password expiration mechanism that works well with Active Directory. While Yale uses AD to authenticate passwords, the Netid system that creates, activates, and changes passwords for Netids is driven by databases external to AD. In the past Yale has had its own custom version of Password Expiration logic, although in the future we may attempt to change AD enough to allow us to use the standard JASIG CAS module.

CAS uses Spring Webflow to manage the browser interface during login. Each login proceeds through a sequence of steps that handle the non-interactive tests (for a certificate or AD Kerberos authentication), then the userid/password form, and finally the Cookie and ticket generation. However, when a user opens a bunch of different applications at once, as happens when Firefox opens a large number of Tabs at once, more than one Webflow from the same browser under the same HTTP session arrive in different threads of the CAS Webserver. We have observed that occasionally Spring Webflow loses its memory of an individual flow. The JASIG CAS code stored a piece of information in "Flow" related storage and loss of the flow memory forced the user to reenter his userid and password when that should not have been necessary. The solution was to store this particular variable in a hidden field of the Form, then add code to the standard Webflow to detect the case when the userid/password data arrives in a HTTP POST but no Webflow history is found to match up to that POST. Rather than starting back at the beginning, the new logic jumps ahead to the middle fo the flow at the point where the password entered by the user is authenticated.