The CAS Server is a Spring Web Application. It tries to use every possible feature of Spring, so even people who know Spring discover there are extra manuals to read if they want to understand CAS. This page is designed to quickstart a new CAS administrator or developer with high level pointers to where things are and how they fit together. Maybe you don't need the details.
Spring is a Java framework that loads Java classes and creates Java objects based on XML configuration files. A reference to the object is then "injected" to another Java object by calling the method that sets a property value. For example, when tickets are generated they have to be assigned an ID. The class that creates tickets has a property that holds a reference to an object that generates the ID string. JASIG provides an ID generation class that should satisfy most requirements, but if you find it inadequate you can write your own ID generation class with special local properties. Then you change the XML file that creates the ID generation bean to use your classname instead of the JASIG classname. Spring now creates an object of your class instead of the JASIG standard class and sets the property in the ticket generation object to point to it. Ticket ID strings are now generated by your classCAS 2 was written at Yale and was a Servlet. It was tiny compared to subsequent versions of CAS, but it just did the basic features and that was enough.
CAS 3 was a replacement that performed the same functions and used the same protocol, but provided a base to add additional optional features. The Spring Framework was selected as the base technology. Spring is good because it creates an application that can be reconfigured by changing some XML files without writing new code. If you are a Java programmer, then Spring provides its own richer API for doing lots of things that can be done with vanilla Java, but you have to read a new manual to understand them. This is not a place where I can reasonably introduce Spring, so either you know it or you can pick up a book.
CAS 5 has been released as a simpler configuration solution. The problem with CAS 3 is that every Bean of Java code was connected to every other Bean with an explicit XML configuration element. This is very powerful, but it produces massive configuration files that take time to learn and use. Subsequent generations of Spring have adopted an "autowire" approach, where default configuration is done with annotations in the Java source. CAS 5 can be configured with one very large properties file. You specify the properties of the options you select, and any option where you specify no properties simply doesn't get used.
Since we are currently using CAS 3, this document will tend to show XML configuration of Beans. The same Beans are still there in CAS 5, but some element will be configured differently.
CAS was designed to be flexible. In the original design, flexible meant that it would be easy to add new function by adding new Java code. Later releases were targeted to campuses with no Java development capability, so more recently flexibility is the opportunity to select from prepackaged options. Since Yale has had Java developers and has worked with CAS from the beginning, we have not been scared to write a little code and make CAS work exactly the way we want it to.
So to get along with CAS at Yale, you need to know a bit of the design that normally only developers care about.
Java creates objects with the "new" statement, and if the object requires parameters in order to fill in required fields, then they are passed to the "constructor". Spring creates Beans, which is an instance of a named class represented by an XML "Bean" element in some Spring configuration file. If the object requires parameters to fill in the values of required fields, then those parameters are in the XML as either Attributes of the Bean element of child elements of the Bean.
Java classes may require that a field be assigned a reference to another Bean. This is called "injection". Typically there will be an interface that defines the function that the Bean provides, and if in the entire application there is only one Bean that implements this interface then there is no problem figuring out what type of class has to be injected. However, there are several different ways that a password can be validated, and several different ways to store Ticket information for future use, and several ways to configure Services. In these cases you have to configure one specific choice from the many types of Beans that could provide the functions needed by the interface. In CAS 3 you would generate one XML element that names the class you have selected to perform the function. In CAS 5, you provide initialization parameters for the one class that could be used to satisfy the interface, and if you did not provide parameters that would allow any of the alternatives you might have selected to actually be loaded and run, then the only Bean that can be initialized must be the one that provides the required interface services.
There are a few objects that are created by the Tomcat container (a Request, a Response, a Session, and the things connected to them). There are also a few data objects that CAS creates during normal request processing: Credentials (a userid and password), Tickets (login or service tickets), Services. Everything else is a Spring Bean.
The good news is that CAS has a well defined set of layers represented by interfaces, and these layers can be described using the standard J2EE terminology. The next step is then to identify the key configuration components for each layer or interface and how they fit into the overall CAS process.
...