What is
The main MODEL (hierarchy of different Ticket types) is in "ticket" package. So a separate class diagram of this MODEL would be useful. In addition to the core MODEL there are supporting service layer interfaces in the "ticket" package e.g. TicketManager (the main facade into the ticket MODEL), TicketRegistry (internal ticket cache), TicketFactory (internal factory for vending tickets), TicketCreator (TicketFactory's helper interface for instantiating a particular type of a Ticket), ExpirationPolicy (Ticket's strategy collaborator to define different expiration policies for tickets), etc., etc.
Ideas
Server-side, we can simplify the set of Ticket types we need to model.
There are really only two kinds of tickets. There are GrantingTickets, and there are ServiceTickets. Each of these are a type of (extend) Ticket.
Tickets have two properties. They have a "grantor" property, that is either null or the GrantingTicket that granted them. They also have a String identifier which uniquely identifies the ticket from a large namespace. Part of the identifier is drawn from a large space uniformly at random. This is key to CAS's security.
public Interface Ticket {
/**
* Get a String uniquely identifying this Ticket within this instance of CAS Server.
* The id must contain a substring that is drawn uniformly at random from a large space --
* this is vital to the security of a CAS implementation.
*/
public String getId();
/**
* Get the GrantingTicket from which this Ticket was generated.
* Returns null in the case where this Ticket was not created from a GrantingTicket.
*/
public GrantingTicket getGrantor();
}
GrantingTickets add to Ticket an additional property: the immediate authenticated Principal to which the GrantingTicket was issued. This might be a user Principal, in the case of the GrantingTicket that is stored into a secure cookie in a user's web browser, or this might be a service Principal, in the case of a GrantingTicket that was issued by secure callback to an application or to an otherwise authenticated application out there on the Internet.
ServiceTickets add to Ticket an additional property: the Target to which the ServiceTicket is intended to authenticate.
What is authenticated by a ServiceTicket? When a ServiceTicket is validated, the validation response is a representation of the chain of Principals from associated with the GrantingTicket that granted the ServiceTicket, and the GrantingTicket (if any) that granted that GrantingTicket, and the GrantingTicket (if any) that granted that GrantingTicket, and so forth up the chain until we reach a GrantingTicket that was the first in the chain.
It's turtles all the way down.