...
- the user interactions part is not totally clear to me : do you want to have one screen with multiple user interactions or several screens with just one user interaction ? I think also that each interaction should be attached to credentials for further authentication
- I still belive we can get rid of parameters just by using supports() method on authentication handler : I would say that the supports() method could have more input than just the credentials, but also Authentication, HttpServletRequest... Don't you think ?
NEW 2 Nathan:
- I was imagining that each interaction has a particular "starting screen", which could lead to subsequent screens based on Spring Web Flow and controllers that are triggered from the first screen.
- If two authentication handlers are required for the requested LOA, then CAS would show the interaction for each LOA in sequence. In this case the user would see two screens, one for the first authentication handler and one for the second. This allows easy mix-and-match of authentication handlers.
- The thought is this:
- Authentication Handler is requested
- Interaction is selected as defined by the authentication handler
- First screen of interaction is displayed as defined by the interactionSpring Web Flow and controllers might show additional screens
- If alternate Interactions (for alternate Authentication Handlers) are available, list links to the alternates on the screen.
- Spring Web Flow and controllers might show additional screens
- The interaction results in Credentials
- The Credentials are handled by the Authentication Handler, producing an Authentication
- Repeat these steps for any other authentication handlers required for this LOA
- One thing I'm trying to avoid is having to define multiple copies of an authentication handler in order to support things like multiple password policies. We probably could make that work successfully, but it feels like more work than necessary for deployers.
- It might be OK to start this way (no parameters but with multiple auth handlers to support multiple password policies) and then sometime in the future re-evaluate options that would make it easier to define LOAs based on password policy strength. I'll look through our use cases again to determine whether this will work well for us in the short-to-medium time-frame.
B) Level of assurance (new)
...