Authentication nodes
Authentication trees provide fine-grained authentication by allowing multiple paths and decision points throughout the authentication flow.
Authentication trees are made up of authentication nodes that define actions taken during authentication. Each node performs a single task during authentication, such as collecting a username or making a simple decision. Nodes can have multiple outcomes rather than just success or failure.
You can create complex yet customer-friendly authentication experiences by linking nodes together, creating loops, and nesting nodes within a tree, as follows:
Node types
Nodes are designed to have a single responsibility. Where appropriate, they should be loosely coupled with other nodes, enabling reuse in multiple situations.
For example, if a newly written node requires a username value, it should not collect it itself, but rely on another node, namely the Username Collector node.
There are two broad node types: collector nodes and decision nodes.
Collector nodes
Collector nodes capture data from a user during the authentication process. This data is often captured by a callback that is rendered in the UI as a text field, drop-down list, or other form component.
Examples of collector nodes include the Username Collector node and Password Collector node.
Collector nodes can perform basic processing of the collected data, before making it available to subsequent nodes in the authentication tree.
The Choice Collector node provides a drop-down list, populated with options defined when the tree is created, or edited.
Not all collector nodes use callbacks. For example, the Zero Page Login Collector node retrieves a username and password value from the request headers, if present.
Decision nodes
Decision nodes do the following:
-
Retrieve the state produced by one or more nodes.
-
Perform some processing on that state.
-
Optionally, store some derived information in the shared state.
-
Provide one or more outcomes, depending on the result.
The simplest decision node returns a boolean outcome - true, or false.
Complex nodes may have additional outcomes. For example, the LDAP Decision node provides the additional outcomes
Locked, Expired, and Cancelled. The tree administrator decides what to do with each outcome;
for example, the True outcome is often routed to a Success node, or to additional nodes for further authentication.
In the following example tree, two collector nodes are connected before a Data Store Decision node. The node then uses the credentials to authenticate the user against the identity stores configured for the realm. In this instance, an unsuccessful login attempt leads directly to failure; the user must restart the process from scratch.
A more user-friendly approach might route unsuccessful attempts to a Retry Limit Decision node. In the following example, unsuccessful authentication attempts at the Data Store Decision node stage are routed into a Retry Limit Decision node. Depending on how many retries have been configured, the node either retries or rejects the new login attempt. Rejected attempts lead to a locked account.
|
Nodes can have prerequisite stages
Some Decision nodes are only applicable when used in conjunction with other nodes. For example, the Persistent Cookie Decision node looks for a persistent cookie that has been set in the request, typically by the Set Persistent Cookie node. The OTP Collector Decision node, which is both a collector and a decision node, only works when used in conjunction with a one-time password generated by a HOTP Generator node. |
Restrict a node’s functionality
To determine the functionality of a node, reduce the node’s responsibility to its core purpose. For example, the Password Collector node just captures the user’s password.
Before you create a set of nodes, assess the level of granularity the nodes should produce. For example, a customer’s environment may require a series of utility nodes that, on their own, don’t perform authentication actions, but have multiple use cases in many authentication journeys. In this case, you can create nodes that take values from the shared state and save it to the user’s profile.
Individual nodes can respond to a variety of inputs and outputs, and return different sets of callbacks to the user without leaving the node.
The following guidelines help a node developer determine the best point at which to split a node into multiple instances:
-
If a node’s process method takes input from the user, and immediately processes it:
Consider splitting the functionality over two nodes:
-
A collector node returns callbacks to the user and stores the response in the shared state.
-
A decision node uses the inputs collected so far in the tree to determine the next course of action.
A node that takes input from the user and makes a decision should only be designed as a single node if there is no possible additional use for the data gathered, other than making that specific decision.
-
-
If a processing stage in a node is duplicated in other nodes:
In this case, take the repeating stage out and place it in its own node. Connect this node appropriately to each of the other nodes.
If multiple nodes contain the same step in processing, such as returning a set of callbacks to ask the user for a set of data before processing it in different ways, the common functionality should be pulled out into its own node.
-
If a single function within the node has obvious use cases in other authentication journeys:
In this case, the functionality should be written into a single, reusable node. For example, in multi-factor authentication, a mechanism for reporting a lost device is applicable to many node types, such as mobile push, OATH, and others.