KOBIL Verify

KOBIL Verify

The main task of this execution is to authenticate the user based on a digital signature, which is generated by the user by accepting a confirmation message called a transaction.

Note: Extending with the Risk Management feature makes this a very powerful authentication.

Type

Protocol	OpenID Connect 1.0
HTTP method	GET
Type	Browser Flow
Endpoint	Authorization Endpoint
Flow Supported	Authorization code flow Implicit flow Hybrid flow
Response	ID Token, Access Token, Refresh Token
Response Mode	query, form_post, fragment

How to configure

To access the config of the execution press the Actions button and select Config. The authenticator configuration screen will appear. Then enter your config data.

Note: This execution requires user execution, for example KOBIL Login.

Configuration

Parameters involved in KOBIL Verify execution

Parameter	Description
ID	Unique system UUID, which will be assigned automatically.
Alias	Provide an alias name for the configuration to be set.
Play Store URL	Provide the android app link from Play Store.
App Store Link	Provide the IOS app link from App Store.
One Link	Provide the common link to redirect for all app stores.
KOBIL Push Notification Message	Provide the custom message that needs to be displayed in the user device.
Device Timeout Duration (Seconds)	The value provided in seconds - The time duration after which the transaction is timed out (Time interval for which the message will be displayed to the user on the mobile device, before expiring) when the device is offline.
Transaction Timeout Duration (Seconds)	Tha value provided in seconds - The time duration after which the transaction is timed out (Time interval for which the message will be displayed to the user on the mobile device, before expiring) when the device is online.
Unlock Instruction	Provide the information text (on how to unlock the device), to be displayed on the login webpage if the user device is locked.
Do not show activation code for no devices	Enable not to display the activation code when no device available for the user.
No Device Instruction	Provide the message to be displayed when user did not have a devices.
Activation Instruction	Provide the user activation information to be displayed on the login webpage instead of the activation code. The usability of this text is based on the user configuration. Refer User management section for configuration details.
Transaction Message	Provide the message to be sent along with the transaction. Note: {userid} and {token} can be used as placeholders to include the userid and token to your custom message. If no message is added, then the default message containing the userid and token is displayed.
App Name	Configure the App name for which transaction should be triggered. To configure the multiple app names use "," to separate.
Broadcast Transaction	When this setting is turned ON, login confirmations (transactions) will be sent to all activated devices (device ID="-1"). The setting overrides the "Manual Trigger" parameter. The selection follows the logic: When no device is online, send the transaction to the device which comes online first. Online means KOBIL devices have active sessions between SDK and IDP Server(SSMS). Device Login has proceeded. When only one device is online, send the transaction to that device. When more than one devices are simultaneously online, the transaction will be sent to a device with a lower device ID - Device that was activated first on the IDP Server(SSMS).
Send Transaction to last logged In Device only	Enable to send transaction and push notification to last logged In device. Possible when 'Broadcast Transaction' is enabled.
Manual Trigger	When this setting is turned ON, login dialog displays the user's device list. User must select the device which receives the transaction and login from that device. When the user has only one device activated, the select box will be skipped(not displayed) and the transaction will be sent directly to the device.
Enable all device	When this setting is turned ON all the device types are enabled to receive the transaction. Alternately this could be turned OFF and specific device types from the below could be selected: ANDROID_ARMv7a, ANDROID_ARMv8a, IOS_ARMv7, IOS_ARM64, MAC_OS, WINDOWS.
Allow ANDROID_ARM	Enable to use ANDROID_ARM type devices.
Allow ANDROID_ARMV7A	Enable to use ANDROID_ARMV7A type devices.
Allow ANDROID_ARMV8A	Enable to use ANDROID_ARMV8A type devices.
Allow IOS_ARMV7	Enable to use IOS_ARMV7 type devices.
Allow IOS_ARMV7S	Enable to use IOS_ARMV7S type devices.
Allow IOS_ARM64	Enable to use IOS_ARM64 type devices.
Allow MAC_OS	Enable to use MAC_OS type devices.
Allow WINDOWS	Enable to use WINDOWS type devices.
Allow WINDOWSPHONE_ARMV7	Enable to use WINDOWSPHONE_ARMV7 type devices.
Allow WINDOWSPHONE_EMU	Enable to use WINDOWSPHONE_EMU type devices.

User Flow

Execution Flow

Type: browser/webview - This authentication is a type of browser flow and is to be used with browser or webview.

This execution contains the following main steps:

1. KOBIL Verify must be preceded with another authenticator since it procures the username from this precedent authenticator. For instance: KOBIL Login for user identification.

2. Once the username is provided, KOBIL Verify checks for user devices.

   Alternative 1: Manual Trigger = OFF (default)

   2a. If one or many devices exist, the transaction is triggered directly to the username, parameter = "-1"

   • If none of the devices are online when the transaction is triggered - a push notification is sent "without confidential data" to notify the user about the action.
   • If one device is online - the transaction arrives on the online device.
   • If more than one devices are online - the transaction will arrive on the device registered first.

   2b. If the device does not exist then the user is requested to contact the administrator, for alternate proceedings.

   Alternative 2: Manual Trigger = ON

2a. If devices exist, it lists the registered devices for the user to select. In the case of a single device, the transaction is triggered directly to the device.

2b. If the device does not exist then the user is requested to contact the administrator, for alternate proceedings.

3. IDP Provider starts login transaction. This transaction is a notification along with a token number, which is generated in the IDPentity screen. The user needs to verify if the token numbers match and approve or decline the transaction to login.

4. If the transaction signature is valid, then the user is logged in.