Login, authentication exceptions, M2
Notes from meeting
Who and When
1pm - 3pm
Rutgers: Bill, Scott, Dmitriy
Yale: Susan, Andrew, Howard, Drew, Andy
Non-interactive login / Yale speculative code
Discussion of Noninteractive login.
Word document discussed attached.
Functional requirements
- Multiple credentials (certificate, password, cookie, IP address)
- Multiple subjects (entries resulting from authenticating using various credentials)
- Multiple applications (services using CAS) with differing requirements
- Non-interactive logon experience where non-interactive credentials are sufficient
- Multi-step logon experience where only interactively solicited credentials are sufficient
Design requirement
- Institutional custom logic to pre-scan request, set processing options (renew, gateway), and at return determine sufficiency for need for further processing
New and changed elements
LoginController extension point between static logic and request-specific logic
Called LoginCongfig in the speculative code. The LoginController depends upon a RequestToLoginConfig instance which it uses to generate a LoginConfig for a given HttpServletRequest. The RequestToLoginConfig considers the request as well as configuration, user preferences, instutional policy, whatever. The LoginConfig it delivers is then interrogated to determine what service, if any, we're trying to obtain a ServiceTicket to access. It advises whether a ServiceTicket obtained for that service is likely to be sufficient (and so we should consider whether to redirect to the service with the ticket) or is likely to be insufficient (and so we should solicit some additional, probably interactively obtained, credentials). The LoginConfig also advises about whether we need to warn the user that single sign on has occured and / or whether we are in gateway mode (and so the service would prefer that we not solicit additional credentials if the credentials we have obtained thusfar are insufficient).
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
Discussion of AuthenticationException Heirarchy. Howard to post to Wiki thoughts about / exceptions for the ways in which cert authentication can fail.
Milestone 2
Discussion of Milestone 2. Testcase coverage.