...
There are several problems that trigger a need for customization:
JBoss (not Tomcat)
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.
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. Each login proceeds through Webflow is one of several technologies (like JBoss Weld and the new Java standard CDI) that organize information across 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 authenticatedpages 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.