Authentication Actions present a tool for orchestrating what happens after authentication but before the session is committed. In other words. the user has authenticated, but the system hasn’t yet produced an authenticated session, which later can be used for Single Sign-On etc.
Any authenticator can be configured with any number of actions to run after login, or after sso. They are executed in the configured order so they can be chained and depend on each other.
Actions can do the following tasks:
These are just a subset of the general tasks, action plugins can be built to perform advanced orchestration using the above building blocks.
Fig. 89 Authentication Action Overview
There are two swim lanes of actions to configure.
Login actions fire when a new authentication with the current authenticator takes place. The end-result of all actions will be persisted in the Authenticated Session (i.e., an SSO session).
SSO actions fire when there is an existing, valid session for the current authenticator and Single Sign-On will occur.
The end-result of the SSO action will not be persisted in the authenticated (SSO) session, but will be returned in the attributes to the client.
Typically there is no need to have the same actions in both the Login and the SSO swim lanes.
An action plugin is split into two component: the Authentication Action and the optional action completion.
Whenever the action fires it can return one of three states:
The action returns the attribute it has worked on, and those are passed to the next action. Depending on type of action, the attributes may be unchanged.
If no more action are configured, the authentication service continues the authentication flow with more authenticators or returns success to the client.
The action decided to deny the user’s access. It is up to the action to decide how this decision is made. Examples are to look for an attribute that must exist, user must belong to a certain group, account is not active, etc.
When an action returns failure the authentication process stops and the user is redirected back to the client or service provider with an error code of access denined.
An action may decide that it requires more user action before it can grant access. There are four groups of Completions that may occur.
The action decided that the user needs to authenticate using another factor. It is up to the authenticator to decide why, but it could be that the user has opted into a second factor or for other reasons.
When the action requests this completion, the user is prompted with another authentication and once completed the action will resume.
Each action may implement it’s own set of screens that it needs the user to go through. These may be anything from a password update flow to approve terms and conditions to something else entirely. The user will be promted with these and, once completed, the action will resume and can decide if the user has fulfilled the requirement.
In some cases the action will require the user to be redirected elsewhere. It could be that the user needs to follow a sign-up flow on another website or needs to visit her profile to update her address, etc. When that is done, the other site will redirect back, and the action is resumed.
When configuring an action that will redirect off-site, remember to whitelist the redirect URL in the authentication profile configuration.
The action may require the user to register, usually with another factor or additional devices based on the authenticator logic.
When the action requests this completion, the user is redirected to the registration page of the configured authenticator and after successful registration the action will resume.
Optionally, the action implementation could decide whether to redirect to a different registration endpoint or to ignore any prerequisite for the registration.