...
See also the Yale CAS meeting on this subject.
Authentication object contains a collection of AuthenticationEntries
The Authentication in the head bore an Object for additional information. An idea of what this object would be would be a Set of these AuthenticationEntries.
(Maybe these are Subjects, in "SAML"-parlance, rather than AuthenticationEntries. Again, maybe we could be using Open-SAML objects directly.)
An authentication entry expresses a type of thing that was authenticated (Netid, DN, k5 principal, AD UPN), a value ("awp9", "YALE/awp9", "awp9@NET.YALE.EDU", "awp9@yale.edu"), how (Cert over SSL, password over SSL, could both be ways of authenticating a NetID), and a timestamp at which this authentication occured.
CAS2 renew=true is true when there exists an AuthenticationEntry that is "of the right kind" (plausibly, authenticates a NetID via a username and password) that has a timestamp that is after when the /login?service=foo&renew=true request arrived.
AuthenticationManager with PAM style function for managing handlers
PAM has concepts of "optional", "required", "requisite", and "sufficient". We hope we don't need "sufficient".
The AuthenticationManager creates and populates a RequestContext object. This object stores such things as Authentications until we have a TGT into which to shove them, and the TGT until we have a ST. It also stores accumulated errors that can inform the controller and views. The AuthenticationManager accumulates information from individual AuthenticationHandlers which may be failing or may be indicating successful authentication or may even be contributing information about the Principal itself (attributes). It considers the results from all these AuthenticationHandlers as well as any TGT presented and populates the RequestContext which it then returns.
Allowing AuthenticationHandlers to provide more information than just was authentication successful (boolean), more information than just about the Principal (who was authenticated), but who and how that person was authenticated, requires returning a more expressive object (Authentication).
RequestContext
The RequestContext bears accumulated errors, Authentication, TicketGrantingTicket, and ServiceTicket. The Controller needs this information to decide where to go next (is this ST sufficient? Do I have some errors to inform an error view?) and the views need this information (the cookie bearing the TGT ID is part of the view. The redirect to a service (identified by the service entry in the ST) with a ST id (from the ST) is a view. A page obtaining the user's informed consent (because warn=true) might render information about how and what was authenticated, which it would read from the Authentication hung off of the TGT.
AuthenticationException hierarchy
...