Login, authentication exceptions, M2

Proposed agenda

Discussion of handling non-interactive authentication mechanisms, with particular attention to the concrete code proof of concept / facility / whatever deliverables were produced by Yale by the time of this meeting.
Milestone 2
AuthenticationException hierarchy: schedule time and resources (vid conf? conf call? discussion?) for progress on defining AuthenticationException hierarchy.

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 (has dipped).
Continuous Integration: permission from Clearinghouse and enthusiasm for using Clearinghouse resources in support of this effort.
Dates for expected milestones.

Browser not supported