...
D) Actions and Web Flow (updated)
The logic for authentication actions (such as AuthenticationViaFormAction) and corresponding web flows might need to be be updated and generalized. I'm not quite sure how yet, but the goal would be to allow pluggable actions and credential gatherers without the need for updating the spring web flow or duplicating any of the login found in AuthenticationViaFormAction. Probably generalize in a way similar to AbstractNonInteractiveCredentialsAction. Here's a possible type hierarchy:
- AbstractCredentialsAction
- AbstractNonInteractiveCredentialsAction
- AbstractInteractiveCredentialsAction
- AbstractAuthenticationViaFormPostAction
- AbstractAuthenticationViaRedirectAction - note that this maybe could be handled on the "non-interactive" side better (consider existing OpenID and OAuth variations)
It might be good to re-
----- NOTE: THIS DOCUMENT IS CURRENTLY INCOMPLETE... TEMPORARILY STOPPED EDITING HERE.... ------...
think this whole concept in order to make it pluggable without the need to change the web flow. Maybe there would be one extension point in the web flow where CAS calls a list of all installed non-interactive actions and associated handlers. (The actions extract credentials from the HttpRequest and the handlers process those credentials.) Then there would be a second extension point...
E) Interaction manager (new)
An InteractionManager is in charge of finding the right CredentialsGatherer to try for a given CredentialRequirement.
The InteractionManager provides the following methods:
- getGathererForCredentials(CredentialRequirement) - given a particular credentials requirement, find an appropriate gatherer
F) Ticket Granting Ticket (update)
The ticket granting ticket needs to be updated to support a list of Authentication objects instead of only a single Authentication object.
FG) Authentication manager (update)
So far, an The authentication manager takes credentials as input.
To support LOA, it will now take a numeric level of assurance as input also.
Gand returns an authentication. The actions (see D) are responsible for gathering
H) Registered service (update)
So far, a registered service supports attributes : id, name, theme, description, isAnonymous...
To support LOA, it will now define what authentication handlers it supports. None selected means all.
I think it would be better for the registered service to define a list of assurance levels (from the server's policy) that it accepts. -Nathan
H) Assurance evaluator (new)
The assurance evaluator is in charge of evaluating the LOA of the authentication given as input. It returns a numeric value.
Generally, it returns the numeric value of the LOA associated with the authentication handler used to authenticate previously the user and stored in the authentication.
In case of remember-me, the LOA returned is not the one of the authentication handler but is computed.
...