Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

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.

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.

  • No labels