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