...
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
...