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:

JBoss (not Tomcat)

Yale Production Services runs Java applications under JBoss, while JASIG releases CAS for the simpler Tomcat environment.

A Web Application like CAS is packaged in a WAR file. The WAR file contains a bunch of JAR files in the WEB-INF/lib directory and the Java standard says that these JAR files are used first, and only then does the application server search its own libraries. That used to work fine and in Tomcat where the application server provides almost nothing in the way of library services it still works.

However, the modern J2EE standard requires that a full function server provides a wide range of built in services. Sometimes the server (JBoss) has to create a certain type of object and pass it to the application. When the server creates something, it uses its own JAR library files. However, because Tomcat doesn't provide a full set of services, programs like CAS are often packaged up with their own copies of some version of the same JAR files that CAS uses in Tomcat because the server doesn't provide that function itself.

With each new version of JBoss and each new release of CAS, one has to use trial and error to discover conflicts between the JBoss version of a particular service and the version of the same function that comes built into the CAS WAR. Frequently it is just a matter of deleting a JAR file from WEB-INF/lib in CAS. Alternately, you can add an XML element in the JBoss configuration file in CAS to override the normal JBoss processing and absolutely require that JBoss use the CAS JAR and not its own JAR.

The most perplexing problem, but one that everyone can understand, comes from the generic problem of logging errors.

First, there are lots of different ways to do logging and long ago Java gave up trying to develop any standard. Instead there is log4J, slf4j, Commons Logging, and about a dozen other competing solutions to the same problem. Even within a single application, CAS has to consider that different libraries it uses will each have selected a different logging interface. So all the different logging systems get along with each other quite nicely within any application.

However, when you run a bunch of applications inside a server like JBoss, there are two different ways you might like to operate. If the administrator of the JBoss server is also the person expected to read the logs and debug problems, then he wants to control all the logging at the JBoss server level and control what he sees. On the other hand, if five different applications written by five different developers share the same server, and each developer is responsible for his application, then each developer wants to control his own log files and logging options.

JBoss EAP 6.1 tries to leave both options available, but in our experience it is almost impossible to really get the CAS logging details you want if you try to configure the logging at the JBoss server level. However, to transfer 100% of CAS logging control to the configuration files in the CAS application, you have to include a JBoss configuration file in the CAS application that lists absolutely every possible log related JAR file that JBoss and CAS could both know about. That turns out to be 4 jboss logging jars, 4 slf4j jars, the log4j jar, and the commons logging jar. If you forget one of them, then JBoss ends up trying to hook some of the logging and CAS tries to hook some of the logging and you end up with no log messages anywhere.

Yale has a Netid System (not just AD)

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.

Occasional Loss of "Flow" Variables during Login

CAS uses Spring Webflow to manage the browser interface during login. Webflow is one of several technologies (like JBoss Weld and the new Java standard CDI) that organize information across a sequence of pages that perform a single transaction (like the checkout pages when you buy something over the Web). CAS has only the one userid and password page, but before and after that page there are a sequence of non-interactive processing steps to look for a user certificate presented by the browser, or generate the cookie and service ticket ID string. Using a Webflow configured in XML allows CAS customers to insert additional optional steps in the process though configuration rather than coding.

Like Weld and CDI, Spring Webflow maintains the values of previously set variables through the duration of a "Flow". They are discarded when the Flow is done. This is similar to the HTTP Session variables, but it operates on a subset of the Session activity. The browser maintains one Session with the Web server, but if you are doing two different things at the same time to the same Web server (say in two different tabs of the same browser) you can run two open Flows at the same time. So something has to keep them separate and keep their variables separate.

Unfortunately, this fails sometimes at Yale. It is not clear if anyone else experiences this problem with CAS, and it may be due to some local network problem or the way we configure the network. However, frequently enough the Flow seems to get broken when the user hits Enter on the page where he submits the userid and password. The JASIG CAS code stores one important piece of data in a Webflow variable (the service= string) that has to be available after this form is submitted, and it has no logic that can recover if the Flow is broken by some network problem. It is relatively trivial to program around this, because the service string could just as easily be stored in a hidden field of the form as in a Flow variable. However, this is a modification of the JASIG code that makes CAS more robust against failure of the Webflow mechanism for whatever reason.

Preferences

CAS has a large number of optional features, but they are all configured by the central administrator. There is no provision for the User to select optional CAS behavior. It seemed that this feature would be required in the future, so a "proof of concept" module has been created called CAS preferences. When the user goes to the /cas/preferences URL he is presented with a Form where he can select various check boxes and radio buttons. These choices are then written to a Cookie scoped to the CAS server and are available at the beginning of the login Webflow to influence the path through subsequent login sequences. This could be used to enable additional forms of authentication, special processing, or even additional logging to debug a problem someone else is having.

Statistics

There is a standard CAS page with basic server information, but Yale Production Services has a standard format expected for Opsview. So we used the requirement to add Yale specific monitoring data.