Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 7 Current »

Yale CAS Customizations

Yale has a small number of customizations to CAS. They are installed using standard CAS conventions for adding code and changing configuration.

To understand the way the customizations integrate to CAS you need to understand the CAS architecture, interfaces, and Spring configuration. This is not, however, a place to review the vanilla CAS design.

JBoss (not Tomcat)

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

Tomcat only supports the basic Servlet functions while JBoss supports the entire suite of J2EE standard services. When an application decides to use a standard API that is part of J2EE but is not installed in Tomcat, they have to include their own copy of the support library. For example, CAS has JPA support for the Ticket Cache. JPA is built into JBoss and every other J2EE server, but to get that service in Tomcat you have to include a copy of Hibernate (or another JPA implementation) in your WAR.

JBoss complains when CAS attempts to include in WEB-INF/lib:

  • Libraries that should not be explicitly included because they are now part of Java (XML libraries like xalan and xerces).
  • Libraries that duplicate function that is built into JBoss and any other full J2EE server (hibernate, JAXB).

So any library that causes trouble is excluded during the Yale Maven project that builds the final WAR. In addition, the JASIG code add a persistence.xml file in WEB-INF/classes that causes trouble for JBoss, so it is removed.

JBoss provides a number of optional libraries that are not part of the J2EE standard but are commonly used by applications. The biggest problem is JAR files associated with any of the dozen or so "logging" frameworks (log4j, slf4j, commons logging) which all come in JBoss along with its own JBoss logging. JBoss by default tends to replace your logging jar file with its own, but that doesn't generally work. The only way to reliably get all the logs you want is to include a WEB-INF/jboss-deployment-structure.xml with exclude statements for all the log related JAR files. Then logging for CAS is controlled by the CAS log4j.xml file and not the JBoss logging configuration.

Maven Dependency MisManagement

After all the processing, we occasionally find two different versions of the same library included in WEB-INF/lib (example: commons.io Version 2.0 and 2.4). Probably one version was added by the vanilla CAS build process, and then a second version number was unintentionally added during the Yale customizations. You might spend a week of trial and error trying to figure out what you don't understand about Maven Dependency Management syntax, but there is a brute force solution to delete the libraries you don't want (and while you are at it the libraries that conflict with the JBoss enviroment) by specifying the undesirable JAR files in the "packagingExcludes" tag of the maven-war-plugin configuration in the Yale Webapp POM. Basically, this is a place to put in a last minute override and delete of files that you do not want copied to the final WAR artifact.

Project Structure

CAS is distributed as a "parent" Maven project contains a set of "subprojects" in subdirectories. The POM at the top "parent" level lists the subprojects that are to be compiled.

Every CAS Server requires the cas-server-core subproject which contains about 95% of the CAS code.  Yale also uses the cas-server-support-ldap optional subproject to access Active Directory using LDAP protocol to authenticate users and passwords.

Yale includes the cas-server-integration-ehcache project to use Ehcache as the ticket replication mechanism for CAS clustering.

CAS includes the cas-server-support-trusted project, although at any given time it may not be used. "Trusted" means that CAS allows some external agency to authenticate users. If we ever use the ability of the F5 to validate X.509 User Certificates and to turn the validated netid into an extended HTTP Header, then the code in this project will provide the support or at least provide a model for the use of this support.

The only Yale optional subproject that is fully used is cas-server-expired-password-change. This supports the Yale custom mechanism to check if passwords have been changed in the last year and redirect the user to the Netid (Change your Password) application if necessary.

The cas-server-preferences module is a Yale customization that was never used but which poses no particular problem if the user navigates to /cas/preferences he is supposed to be presented with a menu of options to customize CAS behavior on this browser. Selections are saved as a Cookie, which is then available to customize the CAS behavior in all subsequent logins. It could be used to enable CAS options that we don't want to present to a user unless he specifically requested them.

Yale developed a package of optional CAS code under the brand name CUSHY. All the CUSHY code is in the cas-server-support-CusyTicketRegistry project, but while the entire project is built, currently CAS at Yale only uses one bean based on one class (CushyClusterConfiguration) and ignores the rest of the code. The CushyClusterConfiguration bean is added to the TicketRegistry XML Spring configuration file to configure Ehcache after discovering the current environment (sandbox, dev, test, prod). Echache needs a configuration file that lists all the other nodes in the cluster. Without this bean, we would need to keep a separate configuration file for each server and the Jenkins install job would have to install the correct file on each machine. Automatically configuring the file based on discovering the hostname of the current machine is much simpler.

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.

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.

WAR Overlay

The standard CAS Build sequence first complies Core and all the optional JAR files and stores them in the Maven Repository. Then a vanilla cas-server-webapp project build an uncustomized CAS WAR file that contains all the standard HTML and XML files and includes all the previous modules and dependencies in the lib directory.

The last step uses a Maven technique called a WAR Overlay. This is a Maven project that contains only the Yale customization files. Replacement HTML and CSS files, replacement Spring XML configuration files, and the source of a small number of Java classes. This project depends on the vanilla WAR file built in the previous step. That WAR file provides a template for the final CAS WAR, but any files in the WAR Overlay project replace files with the same name in the vanilla template.

While large blocks of Yale Java code are in the the previously mentioned Yale JAR projects, the WAR Overlay contains all the Yale customizations. Thanks to the overlay mechanism, it does not have to duplicate any of the standard CAS files that require no changes. Every file in this project is Yale specific. Any CAS file that is not in the project is supplied by the vanilla CAS release and has not been modified by Yale.

  • No labels