The CAS Server is a Spring Web Application, but it is designed according to standard layers or functional components that can be plugged into a standard J2EE diagram. There are three main components, each of which can be subdivided into subcomponents.
- The front end is a "Presentation Layer" that handles arriving HTTP requests. In addition to presenting and processing the Login form (containing userid and password), this layer also handles non-interactive forms of login (X.509 Certificates), and the Service Ticket validation and Proxy ticket calls.
- The Business Layer (where J2EE would have EJBs) validates the login (by verifying the userid/password against a backend system such as Kerberos or LDAP), and it creates Tickets including the Login TGT and Service Tickets.
- Tickets are stored in a Ticket Cache. Normally this is just an in-memory collection, although it can be replicated (for clustered failover) or stored in a shared database. Since Tickets can be persisted (even though they frequently aren't) they become Entities in a logical Persistence Layer.
Presentation Layer
CAS 3 uses two different Spring APIs to configure and code the Presentation Layer.
The calls to validate Service Tickets and issue Proxy Tickets are processed by "Spring MVC". This is the Spring version of a standard Web frontend framework (like Struts) in which Spring provides the actual Servlet object and the application (CAS) provides POJO objects called Action Beans that expose methods that are called when specific mapped URLs arrive and are passed the Request, Response, and Session objects. In other words, they are Servlets under a different name. There are various reasons given by the different frameworks for this behavior. In Spring, the basic reason is that real Servlets operate outside the ApplicationContext and cannot get dependency injections, but MVC Action Beans are defined inside the ApplicationContext and therefore have access to dependency injection and all the other Spring services.
However, the most visible CAS function