Authentication Configuration

Authentication Flow

An authentication flow is a container for all authentications, screens, and actions that must happen during login, registration, and other workflows. IDP(IAM) platform enables multiple authentication methods powered by KOBIL to enable required workflows. You will be able to define and configure all the authentication flows in the system including actions that each of the flow requires.

Authentication flow is the sequence of actions an user or a service needs to perform in order to be authenticated.

Note: Authentication flows are important security functionality. A badly created flow could either let no user login, let users login with less authentication, or simply result in an error.

Required Actions

Required Actions are tasks to be performed by the user during the authentication process. A user will not be allowed to login until all the required actions are completed. Listed below are the required actions provided by IDP.

• KOBIL Email Registration
• KOBIL Phone Registration
• KOBIL Consent Manager
• KOBIL 2FA OneTime Verification
• KOBIL OTP Remove
• KOBIL Registration Status Verification
• Kobil Update Password

Note: OTP bruteforce lock is applicable for KOBIL Phone Registration and KOBIL Email Registration.

Default Required Actions:

When a new realm is created a list of default required actions are mapped to it, which can be easily modified by enabling/disabling or Registering other custom Required actions.

Note: The required actions can be separately configured for each user as well. Refer User management.

Built-in flows

IDP comes with a certain number of built-in flows. These flows cannot be modified, but the requirements can be modified to suit your needs.

How to create custom Authenticator Flow

Authentication flow contains of main elements

• Top Level flow (authentication flow)
• Execution flow
  • Sub-Execution flow
• Execution

Step 1: Create top level flow

To create a Top Level flow, you can either:

1. Copy and then modify an existing flow. To do this select an existing flow (for example the Browser flow), and press the duplicate button (in-dropdown). This will then ask you to set a name for the new flow, before creating it.

2. Create a new flow from scratch. To do this press the Create flow button. Since this is the more general case, we will use this for our example.

   Parameter	Description
   Alias	The name of the top-level flow.
   Description	The description you can set for the flow.
   Flow Type	The type of flow. The type Basic flow is used only for the authentication of clients (applications). For all other cases, choose Client flow.

Once the flow is created, in addition to the Bind flow, Duplicate, Export, and Edit info buttons, you now have Delete (in the Action drop-down), Add step, and Add sub-flow options.

Note: Deleting the flow in usage may cause user or clients not be able to login.

Step 2: Create Execution flow and/or Add execution

Create Execution flow

Create a new flow from scratch. To do this press the Create flow button.

Create Sub Execution flow

Sub-Execution flows can be added in top level flow with the Add flow button, which opens a Create Execution Flow page that is very similar to the Create Top Level Form page. The only difference is that the Flow Type can be either generic (like before), or form. The form type is used to construct a sub-flow that generates a single form for the user, like what is done for the built-in Registration flow. Sub-flows are a special type of execution that evaluate as successful depending on how the executions they contain evaluate (and this includes the evaluation of their contained sub-flows). And the logic of this evaluation depends on the Requirement of each execution and sub-flow.

Add execution

Executions can be added with the Add execution button. Executions can have a wide variety of actions, from sending a reset email to validating an OTP. If you hover over the tooltip (the tiny question mark) next to Provider, this will describe what the execution does.

These can be divided into automatic executions and interactive executions. Automatic executions are similar to the Cookie execution, and will automatically perform their action when they are encountered in the flow. Interactive executions will halt the flow, usually to get some user input. Executions that execute successfully will get the success status. This is important, because this is part of whether a flow is successful or not. For example, an empty Browser flow would not allow anyone to log in. For that it would need at least one execution that successfully evaluates, for example a Username Password Form that is corrected filled and submitted.

Step 3: Configuration of Requirements

• Required

  For a flow to be evaluated as successful, all required elements in the flow must evaluate as successful. This means that all Required elements in the flow must be sequentially executed, from top to bottom, unless one of the elements causes the flow to fail. However, this is only true for the current flow. Any Required element within a sub-flow is only processed if that sub-flow is entered.

• Alternative

  When a flow contains only Alternative elements, only a single element must evaluate as successful for the flow to evaluate as successful. Because the Required flow elements within a flow are sufficient to mark a flow as successful, any Alternative flow element within a flow that contains Required flow elements will never be executed. In this case, they are functionally Disabled.

• Disabled

  Any Disabled element is not evaluated and does not count to mark a flow as successful.

• Conditional

  This requirement type can only be set on sub-flows. A Conditional sub-flow can contain a "Condition" execution. These "Condition" executions must evaluate as logical statements. If all "Condition" executions evaluate as true then the Conditional sub-flow acts as Required. If not, the Conditional sub-flow acts as Disabled. If no "Condition" execution is set, the Conditional sub-flow acts as Disabled. If a flow contains "Condition" executions and is not set to Conditional, the "Condition" executions are not evaluated, and can be considered functionally Disabled.