KOBIL Authentication Methods
KOBIL Authentication Methods
Following are the list of KOBIL specific authentication methods. The methods can be customized and used in combinations based on requirement.
- KOBIL Login
- KOBIL Verify
- KOBIL QR
- KOBIL OTP
- KOBIL PAM
- KOBIL Oneshot
- KOBIL Cookie
- KOBIL Remember Cookie Authenticator
- KOBIL mTAN
- mPower Cookie
- FIDO
- KOBIL Username Password Form
- KOBIL Email Registration
- KOBIL User Password Registration
- KOBIL User Attribute Handler
- KOBIL Contact Admin
- KOBIL Consent Manager
- Account - KOBIL Change Email
- Account - KOBIL Change Password
- Account - KOBIL Change Phone
- Account - KOBIL Change Username
- Account - KOBIL Manage Devices
- KOBIL Configure Password
- KOBIL Verify Password
- KOBIL Configure User Identity
- KOBIL Verify User Identity
- KOBIL Phone Verification
- KOBIL Email Verification
- KOBIL Create Account
- Condition - Email Verification
- KOBIL Condition - ACR Selection
- KOBIL Configure ACR
- KOBIL Configure User Details
- KOBIL Change Email
- KOBIL eTan
- KOBIL Delete Account
- AST Login
- Condition - ID Verification
- KOBIL ID Card Registration
- KOBIL ID Card Login
- KOBIL Face Login
- KOBIL User Group Registration
- KOBIL AST TMS
- KOBIL Magic Link
- KOBIL Maintenance Page
- KOBIL - Store AST Headers to Session
- KOBIL Register Security Question
- KOBIL Validate Security Question
- Kobil Captcha
- KOBIL AST Claims
- KOBIL Condition - User Role
KOBIL Login
This execution has the following main tasks
- To validate user existence on both IDP Provider and IDP Server (SSMS).
- Optional: To verify password against credentials stored in IDP Provider.
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.
Configuration
Parameters involved in KOBIL Login execution
Parameter | Description |
---|---|
ID | UUID is a string of characters that is assigned to a system or device to provide a globally unique identification. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: 1fa) |
Enable Password Check | If enable this will turn on password verification against IDP Provider credentials. |
Enable Switch User | Enable to provide switch user option. Applicable only to switch to external application. |
Switch User URL | Application URL to switch user. Applicable only if Enable Switch User is ON. |
User Not Exist/Locked Instruction | In case user does not exist or user is locked. This message will be displayed. Input: String: Example: Your account is blocked, please contact the helpdesk at +49 000. |
Enable Forgot Password | Enable this button to provide an option for forgot password flow incase the user forgot the password. Note: Make sure Enable Password Check option is enabled to utilize this option. |
Enable attempted flow | Enable to skip the current authenticator/flow and countinue the next authenticator/flow. |
User Flow
Execution Flow
This execution contains following main steps:
- User provides username.
- Execution verifies if username exist on both IDP Provider and on IDP Server (SSMS).
- 2a. If the user exists -> The user will be forwarded to the next execution screen -> for example: The user needs to provide the password -> If the password is correct, user is logged in.
- 2b. If the user does not exist -> The user will be forwarded to the password verification screen, camouflage not to give away that user does not exist -> Login won’t happen, since the user doesn’t exist.
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:
|
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 |
|
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:
KOBIL Verify must be preceded with another authenticator since it procures the username from this precedent authenticator. For instance: KOBIL Login for user identification.
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.
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.
If the transaction signature is valid, then the user is logged in.
KOBIL QR
The main task of this execution is to authenticate the user based on scanning a QR image which is generated and displayed in the webview. QR code contains a random values, known as a nonce, which has to be scanned by the user from the mobile application (client application).
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:
Required user Actions
should be set to KOBIL QR
. Refer User management section to know about user attribute configuration.
Configuration
Parameters involved in KOBIL QR execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Provide an alias name for the configuration to be set. |
TTL of QR | Set the QR Code Timeout in Seconds. Example 20 Seconds. Defaults to 120. |
Custom QR value | Configure the URL, with the following query param value "?qrValue={qrValue}" where {qrValue} is replaced nonce. For example 'link.com?qrValue={qrValue}'. |
Disable Remember Me option | Enable to hide the remember me option in QR Page. |
Disable Remain SignedIn option | Enable so that remain signedin option will not display. |
Disable back option | Enable to display option to reset flow. |
Enable attempted flow | Enable to skip the current authenticator/flow and countinue the next authenticator/flow. |
User Flow
Execution Flow
This execution contains following main steps:
A QR image is generated and displayed in the web app. QR code contains a random values, known as a nonce, which has to be scanned by the user from the mobile application (client application). If the authentication succeeds, the user is logged in.
The authentication will fail due to transaction timeout if the QR code is not scanned.
Note: Timeout seconds can be set by the client as per their requirement in
TTL of QR
configuration.
KOBIL OTP
The main task of this execution is to authenticate the user based on the provided OTP number. This OTP is generated by IDP SDK, KOBIL App.
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
Click on Add Execution
and select KOBIL OTP authenticator and mark the authenticator as REQUIRED
.
Note: Required user Actions
should be set to KOBIL OTP
. Refer User management section to know about user attribute configuration.
User Flow
Execution Flow
This execution contains following main steps:
KOBIL OTP must be preceded by another Authenticator since it procures a username from this precedent authenticator. For instance: KOBIL Login for user identification.
Post this an OTP generated by IDP SDK is shared with the user, through the mobile app, this OTP must be provided in the web portal, for authentication.
If authentication is successful, then the user is logged in.
KOBIL PAM
The main task of this execution is to authenticate the user based on two main scopes:
- kobil_password - Verifies password against IDP Server (SSMS)
- kobil_oneshot - Verifies login OTP against IDP Server (SSMS)
Type
Protocol | OAuth 2.0 |
---|---|
HTTP method | POST |
Type | Direct Grant |
Endpoint | Token Endpoint |
Flow Supported | Resource Owner Password Credential Grant |
Scope | kobil_oneshot kobil_password |
Response | Access Token, Refresh Token |
Note: This is OAuth 2.0 flow, in case you want to use OIDC protocol instead of the scope:kobil_oneshot, use KOBIL Oneshot. Scope kobil_password does not exist as an OIDC protocol.
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.
Configuration
Parameters involved in KOBIL PAM execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Provide an alias name for the configuration to be set. |
Enable Riskbit Validation | Switch this ON to enable Riskbit validation. Applicable for kobil_oneshot scope only. Refer Riskbits for more information. |
Result ACR Value | Provide the ACR value which needs to be added to the token. |
Execution Flow
Scope kobil_password
This execution contains the following main steps:
KOBIL PAM is an independent authenticator, which does not have to be paired with any other authenticator.
KOBIL PAM requires a username and password for verification.
User needs to provide the username and password.
- 3a. Username will be verified against the IDP Provider, and IDP Server.
- 3b. Password is verified against credentials stored in the IDP Server.
Note: Credentials are verified against KOBIL Server and NOT against KOBIL IDP Provider.
If the authentication is successful, the user is logged in.
Use Case: This authentication is used mostly in mobile apps where the app has access to the user credentials.
Used By: Any client has access to the user credentials.
Scope kobil_oneshot
This execution contains the following main steps:
KOBIL PAM is an independent authenticator, which does not have to be paired with any other authenticator.
KOBIL PAM requires a username and login OTP for verification.
Note: The login OTP you will receive on successful IDP SDK Login, call back on LoginEnd (login OTP, and etc...)
User needs to provide the username and login OTP is passed in the URL query parameter: login OTP.
- 3a. Username will be verified against the IDP Provider, and IDP Server.
- 3b. Login OTP is verified against the IDP Server.
Note: Login OTP is verified against KOBIL Server and NOT against KOBIL IDP Provider.
If the authentication is successful, the user is logged in.
Use Case: This execution is mainly used in mobile apps where the action is done automatically by the mobile app, without any user interaction.
This execution is mostly used in combination with other execution for example username + password.
Used By: Mobile and Desktop App that has access to the IDP SDK.
Additional Uses: Some sources recommend using this grant with your native apps (rather than the authorization code grant with the public client) since full access and control over the source code is ensured.
This grant can also be used in place of the Client Credential Grant in situations where a service account is used to represent the system or calling application.
How to verify username and password for kobil_password
scope using postman collection:
Download the postman collection here.
Pre-requisite - IDP Server, username and password along with client, client scope and client secret.
Open the
Get Access token
API and add thetoken endpoint URL
in the request URL section.Go to the "Body" tab and enter the required details in the
value
column of the username and password along with client, client scope and client secret parameters respectively.Send the request.
If the request is fetched successfully, then the credentials are verified.
How to verify username and password for kobil_oneshot
scope using postman collection:
Download the postman collection here.
Pre-requisite - Go to the Pre-login menu of the Oneshot app and enable
Use OTP
.Open the
Get Access token
API and add thetoken endpoint URL
in the request URL section.Login to the mobile application. The OTP will be generated and stored in the clipboard.
Go to the "Body" tab and enter the OTP and the corresponding username in the
value
column of theusername
andpassword
along with client, client scope and client secret parameters respectively.Send the request.
If the request is fetched successfully, then the credentials are verified.
Develop
Parameter | Description |
---|---|
userid *required | Userid stored in IDP Provider not in IDP Server |
password *required | Instead of the password, provide KOBIL Token, called login OTP. IDP SDK delivers this token on successful authentication, in SDK callback on LoginEnd (..., login OTP). |
Example
curl --location --request POST 'https://midprovider.kobil.com/digitanium/v3/login' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'username=test_user' \
--data-urlencode 'password=1096D3GFDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31' \
--data-urlencode 'scope=kobil_oneshot' \
--data-urlencode 'client_id=test_client'
var settings = {
"url": "https://midprovider.kobil.com/digitanium/v3/login?grant_type=password&username=test_user&password=1096D3GFDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31&scope=kobil_oneshot&client_id=test_client",
"method": "POST",
"timeout": 0,
"headers": {
"Content-Type": "application/x-www-form-urlencoded"
},
};
$.ajax(settings).done(function (response) {
console.log(response);
});
var settings = {
"url": "https://midprovider.kobil.com/digitanium/v3/login?grant_type=password&username=test_user&password=1096D3GFDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31&scope=kobil_oneshot&client_id=test_client",
"method": "POST",
"timeout": 0,
"headers": {
"Content-Type": "application/x-www-form-urlencoded"
},
};
$.ajax(settings).done(function (response) {
console.log(response);
});
import http.client
import mimetypes
conn = http.client.HTTPSConnection("midprovider.kobil.com")
payload = ''
headers = {
'Content-Type': 'application/x-www-form-urlencoded'
}
conn.request("POST", "/digitanium/v3/login?grant_type=password&username=test_user&password=1096D3GFDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31&scope=kobil_oneshot&client_id=test_client", payload, headers)
res = conn.getresponse()
data = res.read()
print(data.decode("utf-8"))
Use Case: KOBIL PAM combined with Condition - ACR KOBIL Cookie
Configuration
The authentication flow would look like configuration would be
- Condition - ACR KOBIL Cookie (acr=1, header/cookie name=1fa-token)
- KOBIL PAM execution
Exection Flow
Let say more complex authentication contains the following steps.
username + password (1FA - First Factor)
IDP SDK login with result loginOTP (2FA - Second Factor)
They say the last step you would like exchange both factors 1FA + 2FA for ID Token, Access Token.
Authentication request contains
Example
Note: In our example, we are using the Condition - ACR KOBIL Cookie as additional security. To fulfill the additional security requirements extra header parameter is required to be added.
In our example we are adding the first factor ID Token. We defined the name "1fa-token". This name can be defined in the configuration of Condition - ACR KOBIL Cookie.
This was added to the original request.
--header '1fa-token: 1fa-token-value' \
curl --location --request POST 'https://midprovider.kobil.com/digitanium/v3/login' \
--header '1fa-token: 1fa-token-value' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'username=test_user' \
--data-urlencode 'password=1096D3GHDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31' \
--data-urlencode 'scope=kobil_oneshot' \
--data-urlencode 'client_id=test_client'
var settings = {
"url": "https://midprovider.kobil.com/digitanium/v3/login?grant_type=password&username=test_user&password=1096D3GHDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31&scope=kobil_oneshot&client_id=test_client",
"method": "POST",
"timeout": 0,
"headers": {
"1fa-token": "1fa-token-value",
"Content-Type": "application/x-www-form-urlencoded"
},
};
$.ajax(settings).done(function (response) {
console.log(response);
});
OkHttpClient client = new OkHttpClient().newBuilder()
.build();
MediaType mediaType = MediaType.parse("application/x-www-form-urlencoded");
RequestBody body = RequestBody.create(mediaType, "");
Request request = new Request.Builder()
.url("https://midprovider.kobil.com/digitanium/v3/login?grant_type=password&username=test_user&password=1096D3GHDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31&scope=kobil_oneshot&client_id=test_client")
.method("POST", body)
.addHeader("1fa-token", "1fa-token-value")
.addHeader("Content-Type", "application/x-www-form-urlencoded")
.build();
Response response = client.newCall(request).execute();
import http.client
import mimetypes
conn = http.client.HTTPSConnection("midprovider.kobil.com")
payload = ''
headers = {
'1fa-token': '1fa-token-value',
'Content-Type': 'application/x-www-form-urlencoded'
}
conn.request("POST", "/digitanium/v3/login?grant_type=password&username=test_user&password=1096D3GHDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31&scope=kobil_oneshot&client_id=test_client", payload, headers)
res = conn.getresponse()
data = res.read()
print(data.decode("utf-8"))
KOBIL Oneshot
The main use case is to authenticate the user based on query parameter login OTP. This login OTP is returned by IDP SDK on behalf of successful IDP SDK Login.
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.
Configuration
Parameters involved in KOBIL Oneshot execution
Parameter | Description |
---|---|
Alias | Provide an alias name for the configuration to be set. |
Enable Riskbit Validation | Switch this ON to enable Riskbit validation. Refer Riskbits for more information. |
Execution Flow
This execution contains the following main steps:
KOBIL Oneshot is an independent authenticator, which does not have to be paired with any other authenticator.
KOBIL Oneshot requires a username and login OTP for verification.
Note: The login OTP you will receive on successful IDP SDK Login, call back on LoginEnd.
User needs to provide the username and login OTP is passed in the URL query parameter: login OTP.
- 3a. Username will be verified against the IDP Provider, and IDP Server.
- 3b. Login OTP is verified against the IDP Server.
Note: Login OTP is verified against KOBIL Server and NOT against KOBIL IDP Provider.
If the authentication is successful, the user is logged in.
Use Case: This execution is mainly used in mobile apps where the action is done automatically by the mobile app, without any user interaction.
This execution is mostly used in combination with other execution for example username + password.
Used By: Mobile and Desktop App that has access to the IDP SDK.
Additional Uses: Some sources recommend using this grant with your native apps (rather than the authorization code grant with the public client) since full access and control over the source code is ensured.
This grant can also be used in place of the Client Credential Grant in situations where a service account is used to represent the system or calling application.
Develop
Parameter | Description |
---|---|
userid *required | userid stored in IDP Provider not in IDP Server |
login_otp *required | Provide KOBIL Token, called login OTP. IDP SDK delivers this token on successful authentication, in SDK callback on LoginEnd(..., loginOTP) |
Example
https://midprovider.kobil.com/digitanium/v3/auth
?client_id=kobil_oneshot_test
&redirect_uri=https%3A%2F%2Fexample-redirect-uri.com
&scope=openid&response_type=token
&response_mode=fragment
&state=gfsjhjgfjshdgfjhs
&nonce=c9ayedrim4p
&username=user_test
&login_otp=1096D3GHDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31
curl --location --request GET 'https://midprovider.kobil.com/digitanium/v3/auth?client_id=kobil_oneshot_test&redirect_uri=https%3A%2F%2Fexample-redirect-uri.com&scope=openid&response_type=token&response_mode=fragment&state=gfsjhjgfjshdgfjhs&nonce=c9ayedrim4p&username=user_test&loginOTP=1096D3GHDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31'
var settings = {
"url": "https://midprovider.kobil.com/digitanium/v3/auth?client_id=kobil_oneshot_test&redirect_uri=https%3A%2F%2Fexample-redirect-uri.com&scope=openid&response_type=token&response_mode=fragment&state=gfsjhjgfjshdgfjhs&nonce=c9ayedrim4p&username=user_test&loginOTP=1096D3GHDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31",
"method": "GET",
"timeout": 0,
};
$.ajax(settings).done(function (response) {
console.log(response);
});
OkHttpClient client = new OkHttpClient().newBuilder()
.build();
Request request = new Request.Builder()
.url("https://midprovider.kobil.com/digitanium/v3/auth?client_id=kobil_oneshot_test&redirect_uri=https%3A%2F%2Fexample-redirect-uri.com&scope=openid&response_type=token&response_mode=fragment&state=gfsjhjgfjshdgfjhs&nonce=c9ayedrim4p&username=user_test&loginOTP=1096D3GHDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31")
.method("GET", null)
.build();
Response response = client.newCall(request).execute();
import http.client
import mimetypes
conn = http.client.HTTPSConnection("midprovider.kobil.com")
payload = ''
headers = {}
conn.request("GET", "/digitanium/v3/auth?client_id=kobil_oneshot_test&redirect_uri=https%3A%2F%2Fexample-redirect-uri.com&scope=openid&response_type=token&response_mode=fragment&state=gfsjhjgfjshdgfjhs&nonce=c9ayedrim4p&username=user_test&loginOTP=1096D3GHDD89732A2DE1161BA1DC739671233058BAF3B70D7B0CA999D3387BC5F573736D73312E65636F2D64656D6F31", payload, headers)
res = conn.getresponse()
data = res.read()
print(data.decode("utf-8"))
KOBIL Cookie
The main use case is to authenticate the user based on the access token and exchange it for a different access token with limited scope or authorization code.
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.
Configuration
Parameters involved in KOBIL Cookie execution
Parameter | Description |
---|---|
Alias | Provide an alias name for the configuration to be set. This will be displayed in the authentication flow configuration. |
Header/Cookie Name | Provide a name of the "key" also called "field, name" send during client authentication request either in the header or in the cookie. For Example: 1FA-Token |
Result ACR Value | Provide the ACR Value which needs to be added to the token. |
Expected Client Name | Configure the client name should provided in the azp (authorized party) of the token. |
Enable Loader | If enabled error page will be displayed when navigating back from the next authenticator. |
AST Registration | If enabled, activates or verifies users in AST and links user to AST client. |
AST Login | If enabled initiates AST login for user. |
AMR value | Configure the AMR value for token when flow succeeds. |
Enable BruteForce Check | If enabled, an error page is displayed when user is locked in bruteforce. |
Execution Flow
This execution contains the following main steps:
- KOBIL Cookie is an independent authenticator and could be used without any precedent authenticator.
- An access token is generated and stored in the server for every user during the IAM onboarding.
- The token should either be set in the header or the client portal URL cookie.
- Now when the user tries to login, the access token is verified and login happens.
How to verify cookie using postman collection:
Download the postman collection here.
Use the
Get Access token
API to generate an access token.Use the sample GET method named "KOBIL Cookie" for reference.
Paste the `authorization URL in the request URL section.
Go to the "Headers" tab and add the previously generated access token in the
value
parameter and send the request.Else
Go to the "Cookies" tab ->
Add Cookie
and add the previously generated access token in thevalue
parameter and send the request.If the request is fetched successfully, then the cookie is verified.
Development
Example
curl --location --request GET 'midprovider.kobil.com/digitanium/v3/auth?client_id=ibm_ega&response_type=code&redirect_uri=app://login&scope=openid&response_mode=querry&nonce=sadasdsadasd' \
--header '2FA-token: {{access token}}' \
--header 'Content-Type: application/x-www-form-urlencoded'
OkHttpClient client = new OkHttpClient().newBuilder()
.build();
Request request = new Request.Builder()
.url("midprovider.kobil.com/digitanium/v3/auth?client_id=ibm_ega&response_type=code&redirect_uri=app://login&scope=openid&response_mode=querry&nonce=sadasdsadasd")
.method("GET", null)
.addHeader("2FA-token", "{{access token}}")
.addHeader("Content-Type", "application/x-www-form-urlencoded")
.build();
Response response = client.newCall(request).execute();
var settings = {
"url": "midprovider.kobil.com/digitanium/v3/auth?client_id=ibm_ega&response_type=code&redirect_uri=app://login&scope=openid&response_mode=querry&nonce=sadasdsadasd",
"method": "GET",
"timeout": 0,
"headers": {
"2FA-token": "{{access token}}",
"Content-Type": "application/x-www-form-urlencoded"
},
};
$.ajax(settings).done(function (response) {
console.log(response);
});
import http.client
import mimetypes
conn = http.client.HTTPSConnection("midprovider.kobil.com")
payload = ''
headers = {
'2FA-token': '{{access token}}',
'Content-Type': 'application/x-www-form-urlencoded'
}
conn.request("GET", "/digitanium/v3/auth?client_id=ibm_ega&response_type=code&redirect_uri=app://login&scope=openid&response_mode=querry&nonce=sadasdsadasd", payload, headers)
res = conn.getresponse()
data = res.read()
print(data.decode("utf-8"))
Example combined with Condition - ACR KOBIL Cookie
Basically only the extra paramater needs to be added to the header. For example --header '1FA-token: {{1FA access token}}' is added to the request.
The name of the parameter can be defined in configuration under section "Header/Cookie Name".
curl --location --request GET 'midprovider.kobil.com/digitanium/v3/auth?client_id=ibm_ega&response_type=code&redirect_uri=app://login&scope=openid&response_mode=querry&nonce=sadasdsadasd' \
--header '1FA-token: {{1FA access token}}' \
--header '2FA-token: {{2FA access token}}' \
--header 'Content-Type: application/x-www-form-urlencoded'
var settings = {
"url": "midprovider.kobil.com/digitanium/v3/auth?client_id=ibm_ega&response_type=code&redirect_uri=app://login&scope=openid&response_mode=querry&nonce=sadasdsadasd",
"method": "GET",
"timeout": 0,
"headers": {
"1FA-token": "{{1FA access token}}",
"2FA-token": "{{access token}}",
"Content-Type": "application/x-www-form-urlencoded"
},
};
$.ajax(settings).done(function (response) {
console.log(response);
});
OkHttpClient client = new OkHttpClient().newBuilder()
.build();
Request request = new Request.Builder()
.url("midprovider.kobil.com/digitanium/v3/auth?client_id=ibm_ega&response_type=code&redirect_uri=app://login&scope=openid&response_mode=querry&nonce=sadasdsadasd")
.method("GET", null)
.addHeader("1FA-token", "{{1FA access token}}")
.addHeader("2FA-token", "{{access token}}")
.addHeader("Content-Type", "application/x-www-form-urlencoded")
.build();
Response response = client.newCall(request).execute();
import http.client
import mimetypes
conn = http.client.HTTPSConnection("midprovider.kobil.com")
payload = ''
headers = {
'1FA-token': '{{1FA access token}}',
'2FA-token': '{{access token}}',
'Content-Type': 'application/x-www-form-urlencoded'
}
conn.request("GET", "/digitanium/v3/auth?client_id=ibm_ega&response_type=code&redirect_uri=app://login&scope=openid&response_mode=querry&nonce=sadasdsadasd", payload, headers)
res = conn.getresponse()
data = res.read()
print(data.decode("utf-8"))
KOBIL Remember Cookie Authenticator
The main use case is to check the flow based on the cookie if it is saved previously. It works similar to conditional authenticator, here the flow is executed based on the cookie name and flow type specified in the authenticator config.
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.
Configuration
Parameters involved in KOBIL Remember Cookie Authenticator execution
Parameter | Description |
---|---|
Alias | Provide an alias name for the configuration to be set. This will be displayed in the authentication flow configuration. |
Cookie Name | Provide a cookie name to validate the flow. For Example: KOBIL_QR_REMEMBER_ME |
Enable for alternate flow | Enable this option to switch to a different flow once the cookie is stored; otherwise, the same flow will be used for execution. |
Execution Flow
This execution contains the following main steps:
KOBIL Remember Cookie Authenticator is a dependent authenticator and it should be used with any precedent authenticators. For instance KOBIL QR.
When the Alternate flow is Enabled, the cookie will be saved throughout execution. During the next execution, the user will be allowed to switch to a different flow.
KOBIL mTAN
The main task is to authenticate the user based on OTP sent to the user through SMS.
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 |
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: Please make sure the appropriate execution name and the user mobile number(to receive mTAN OTP) are set to the user attributes Required user Actions
and phone
respectively(phone
is a custom attribute that could be added to user attributes list). Refer User management section to know about user attribute configuration. Additionally, the SMS Provider configuration must be added to the Realm settings -> SMS. Refer Realm management section for the configuration procedure.
Configuration
Parameters involved in KOBIL mTAN execution
Parameter | Description |
---|---|
Alias | Provide an alias name for the configuration to be set. |
Mobile number attribute | Provide the attribute in which the user mobile number is stored. Default value is 'phone'. |
SMS code time to live | Provide the validity of the sent code in seconds. |
Length of the SMS code | Provide the length of the SMS code. Default value is 6. |
Template of text to send to the user | Provide the message to be displayed to the user, while triggering OTP. Use %sms-code% to display the generated SMS code. |
OTP Resend Count | Provide the maximum number of times a user can request for a new OTP. |
Excute One Time | Enable this to add the attributes mtan_verified and mtan_verified_timestamp to the user after the first execution so that consecutive logins do not require explicit mTan execution. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL mTAN must be preceded by another Authenticator since it procures a username from this precedent authenticator. For instance: KOBIL Login for user identification.
- An OTP is generated and sent to the user through SMS.
- User should enter the OTP in the mobile application for authentication.
- If authentication is successful, the user is logged in.
KOBIL mPower Cookie
The main task is to authenticate the user based on the mPower JWT token.
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 |
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.
Configuration
Parameters involved in KOBIL mPower Cookie execution
Parameter | Description |
---|---|
Alias | Provide an alias name for the configuration to be set. |
User Flow
Execution Flow
This executions contains following main steps:
- KOBIL mPower Cookie must be preceded by another Authenticator since it procures a username from this precedent authenticator. For instance: KOBIL Login for user identification.
- User's identity is validated with KOBIL login.
- KOBIL mPower cookie flow is initiated as 2FA.
- The SSMS server verifies whether the saml_authorization cookie is available and validates it.
- If the cookie is valid, the user is logged in.
KOBIL FIDO
The main task is to authenticate the user based on the FIDO token.
Execution Flow
This execution contains the following main steps:
- Fido needs to be preceded by a KOBIL login for username and password verification.
- User's identity is validated with KOBIL login.
- Fido flow(2FA) is initiated.
- Make sure the Web authN key is plugged into your computer.
- When browser alert is displayed, press the authNkey.
- If the key is registered to the user, the login succeeds.
KOBIL Username Password Form
This execution has the following main tasks
- To validate user existence on IDP Provider.
- To verify password against credentials stored in IDP Provider.
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.
Configuration
Parameters involved in KOBIL Login execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: 1fa) |
Invalid Credentials Message | Message to be displayed when the user credentials invalid. For default invalid username or password. |
User Disabled Message | Message to be displayed when the user is disabled. Default Message: User is currently disabled, please contact admin. |
Temporarily locked message | Message to be displayed when the user is temporarily locked. Example: User is temporarily locked for %time% minutes. |
Time Unit | Select the Time unit in which the user lock duration must be displayed. |
User Alias Attribute | User attribute value selected for login validation. |
Verify Secret Password | Enable to verify the secret password. |
Header on filtering secret credential ID, when Verify Secret Password is enabled | The data in the specified header will be appended with credential ID to verify the secret password. |
Registration URL | The Registration URL to be assigned for user registration link. If not specified, default registration auth flow is assigned. |
Reset Credentials URL | The Reset Credentials URL to be assigned for Forgot Login Detail link. If not specified, default reset credentials auth flow is assigned. |
JSON Script | JSON to display inputs in Headless V2 theme. |
JSON Error Script | JSON to display the error messages in Headless V2 theme. |
Enable Metrics | Enable the metrics which are specific to the current authenticator to expose in metrics endpoint. |
Custom Metrics Name | Name of the metrics under which specific authenticator metrics will be exposed. |
Custom Metrics description | Description about the custom metrics. |
User Flow
Execution Flow
This execution contains the following main steps:
- User provides username and password.
- Execution verifies if the username exists on IDP Provider and password exists on the IDP Provider.
- 2a. If the user does not exist or if credentials are incorrect -> The user will be redirected back to the username and password verification screen, (camouflage not to give away that user does not exist) -> Login won’t happen, since the user doesn’t exist.
KOBIL Email Registration
This execution has the following main tasks
- To verify the email id of the user, if email id is already available.
- To collect and verify the email id of the user, if email id is not available.
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.
Configuration
Parameters involved in KOBIL Login execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: 1fa) |
Force Email Verification | Enable to force email verification, even phone is already verified. |
Email Verification Code Length | Provide the size of the verification code to be sent through email. |
Disable Email Back Button | Disable the back button in forgot password flow. |
Email Verification Code TTL | Provide the validity of the verification code. Default value is 1 hour. |
Show Email Confirmation | Enable to show email confirmation view. |
Email Retry Delay | Set the time delay in seconds between each incorrect attempt. Default value is 5 seconds. Note: This time will be doubled with every consecutive attempt. |
Use OTP Bruteforce Global Settings | Enable to implement the default IAM's OTP brute force logic. |
Disable Email Verification | If this is switched ON, email verification is temporarily suspended and carried out later as part of Required Actions . |
Disable email editing | Enable - email cannot be editied/modified. Disable - email can be editied/modified. |
User Flow
Execution Flow
This execution contains following main steps:
- KOBIL Email Registration must be preceded by another authenticator, since it procures username from this precedent authenticator. For instance: KOBIL Username Password Form for user identification.
- The OTP will be sent to the email which we entered, once the user enters the valid OTP, the user email will be added on successful authentication.
- Execution verifies the user email id when
Email Verified
is OFF andemail_verified_timestamp
is not present in User details.- 3a. If the user email id is available in IDP and `Email Verified` is **OFF** -> An OTP will be sent to the already existing user email id. User must provide the OTP in the login screen for verification. Login happens if the OTP is correct. On successful login, `email_verified_timestamp` must be added to the user.
- 3b. If the user email id is not available in IDP and `Email Verified` is **OFF** -> The user will be asked to provide the email id during login, to which OTP needs to be sent. User must provide the OTP in the login screen for verification. Login happens if the OTP is correct. On successful login, `email_verified_timestamp` and `email_lastupdated_timestamp` must be added to the user.
- 3c. If the user email id is available in IDP and `Email Verified` is **ON** -> An OTP will be sent to the already existing user email id. User must provide the OTP in the login screen for verification. Login happens if the OTP is correct. On successful login, `email_verified_timestamp` must be added to the user.
KOBIL Phone Registration
This execution has the following main tasks
- To collect and verify the phone number of the user, if the phone number is not available.
- To verify the phone number of the user, if the phone number is already available.
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.
Configuration
Parameters involved in Account - KOBIL Change phone execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Phone Registration) |
Force Phone Verification | Enable to force phone verification, even phone is already verified. |
Disable Back Button | Disable the back button in the forgot password flow. |
Phone Verification Code TTL | Provide the validity of the verification code. (Example: for days 2d, for hours 2h, for secs 2s.) Default value is 1h. |
Phone Verification Code Length | Length of the SMS code. Default value is 6. |
Show Phone Confirmation | Enable to show phone confirmation view. |
Phone Retry Limit | Phone Retry Limit. Default value is 5. |
Phone Retry Delay | Phone Retry delay in seconds and between every attempts previous time will be doubled: Default value is 5 seconds. |
Template of text to send to the user | Add phone message template, following attributes are supported {first_name}, {last_name}, {code}, and {expiration}. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Phone registration must be preceded by another authenticator since it procures a username from this precedent authenticator. For instance: KOBIL Username Password Form for user identification.
- The OTP will be sent to the phone number which we entered, once the user enters the valid OTP, the user phone number will be added on successful authentication.
KOBIL User Attribute Handler
Main task of this execution is to add/update and remove the attributes provided through the User Attribute Name/Value field and JSON format.
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: User Enabled
should be set to ON
.
Configuration
Parameters involved in KOBIL User Attribute Handler execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Provide an alias name for the configuration to be set. |
User Attribute Name | Provide a name of the "key" send during authentication request. |
User Attribute Value | Provide a name of the "Value" send during authentication request. |
While execution the attributes present in JSON format will be considered as the highest priority even if the value present in User Attribute Name/Value field.
Sample Request Body
In order to add/update and remove the attributes use the below JSON formats.
To remove:
{
"attribute_name1": {
"removeAttribute": "true"
}
}
To add/update:
{
"attribute_name2": {
"attributeValue": "value"
}
}
User Flow
Execution Flow
This execution contains following main steps:
- It is mandatory that KOBIL User Attribute Handler must be preceded by another Authenticator, since it procures username from this precedent authenticator. For instance: KOBIL Username Password Form for user identification.
- The authenticator will receive a collection of attributes in the authenticator configuration as a JSON file and it will add/remove the attributes depending on the supplied JSON.
- The backward compatibility of a single attribute upgrade has also been established.
KOBIL User Password Registration
This execution has the following main tasks to register the user password on IDP Provider.
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.
Configuration
Parameters involved in KOBIL User Password Registration execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: 1fa) |
Match Password Policy | Enable to match generated password with password policy. |
Auto Generate One Time Password | Enable to generate password. |
Auto Generate One Time Password Size | Set size of auto generate password: default: 8 |
Auto Generate One Time Password Type | Set type of auto generate password: default: Alphanumeric. |
Auto Generate Password Character Set | Set of specified characters to generate the password. |
One Time Password Expiry | Set One time password expiry, for days 2d, for hours 2h, for minutes 2m, for secs 2s. |
Disable Update Password Event | Enable to stop triggering update password, after successfully completing the password registration. |
Hash and store secret password | In hashed format, user's secret password will be stored. |
Header on filtering secret credential ID, when Verify Secret Password is enabled | The data in the specified header will be appended with credential ID to verify the secret password. |
Select Way of Next Step | Select Option to proceed to next step, login will redirect to login page and continue to move to next step. |
Do login | Set the url which needs to be redirected. |
Redirect URL | Specify the Redirect URL to include in all pages. |
Form Texts Script | Include custom texts to be displayed in the Form with support for different locale. |
JSON Script for Headless V2 theme | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- It is mandatory that KOBIL User Password Registration must be preceded by another Authenticator, since it procures username from this precedent authenticator. For instance: KOBIL Login for user identification.
- User provides username.
- Execution verifies if the username exists on IDP Provider.
- User is requested to update the new password and confirm the same.
KOBIL Display Username
Main task of this execution is to display the property based on the user property selection to display at configuration level.
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.
Configuration
Parameters involved in KOBIL Display Username execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Provide an alias name for the configuration to be set. |
User Property to display username | Select one user property to perform display action with. On selection of Username property Username will be displayed, Email property will be displaying the user registered Email Id and User attribute will display the corresponding attribute value. Defaults to Username |
User Attribute Name | Provide the attribute name if you selected user property as an User attribute . |
Do login | Provide the redirect URL where it should be redirected on successful authentication. |
User Flow
Execution Flow
This execution contains following main steps:
- KOBIL Display Username must be preceded by another authenticator, since it procures username from this precedent authenticator. For instance: KOBIL Username Password Form for user identification.
- The authenticator will display the property on successful authentication based on the user property selection to display.
Note: This execution used User Alias Attribute configuration in KOBIL Username Password Form for user identification.
KOBIL Contact Admin
Main task of this execution is to provide the contact details of support desk.
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.
Configuration
Parameters involved in KOBIL Contact Admin execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Provide an alias name for the configuration to be set. |
Login URL | Provide the redirect URL where it should be redirected on successful authentication. |
User Flow
Execution Flow
This execution contains following main steps:
- KOBIL Contact Admin must be preceded by another authenticator, since it procures username from this precedent authenticator. For instance: KOBIL Username Password Form for user identification.
- The authenticator will provide the contact details of support desk on successful user authentication.
KOBIL Consent Manager
Main task of this execution is to gather and maintain user consent for processing their personal information.
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.
Configuration
Parameters involved in KOBIL Login execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Demo) |
Consent Scope | Defines the consent's scope, whether local, global, or none. Note: If the script accepts consent from one client, it will accept consent from all clients. When the consent is defined in the IAM client scopes rather than the script, pick none. |
Version | Set the version number for consents. |
Content | Set content that needs to be displayed to the user in order to accept the consents. |
Client Scopes | Add script for consent management scopes. Note:Name should be unique for each consent. |
User Flow
Execution Flow
- KOBIL Consent Manager must be preceded by another authenticator, since it procures username from this precedent authenticator. For instance: KOBIL Username Password Form for user identification.
- The authenticator will collect and maintain user consent for processing their personal information.
Account - KOBIL Change Email
This execution has the following main tasks
- To change the email id of the user.
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.
Configuration
Parameters involved in Account - KOBIL Change Email execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: 1fa) |
Email Verification Code Length | Provide the size of the verification code to be sent through email. |
Email Verification Code TTL | Provide the validity of the verification code. Default value is 1 hour. |
Show Email Confirmation | Enable to show email confirmation view. |
Email Retry Delay | Set the time delay in seconds between each incorrect attempt. Default value is 5 seconds. Note: This time will be doubled with every consecutive attempt. |
Email Verification way | Set the verification way to email. |
Login Url | Provide the login url to redirect in case of selecting OTP verification way. |
Send Notification to Old Email | Enable to send mail to the Old Email. |
Send Notification to New Email | Enable to send mail to the New Email. |
Disable email address masking | Disable email address masking at the OTP verification screen. |
Restrict redirection for error | Enable to restrict redirection for error messages in OTP Screen. |
Custom Action Token Handler Name | To use custom Action token handler if empty, it takes default Action token handler. |
User Flow
Execution Flow
This execution contains the following main steps:
KOBIL Change Email must be preceded by another authenticator since it procures a username from this precedent authenticator. For instance: KOBIL Login for user identification.
Based on the verification way we choose, whether OTP or LINK the response will be sent.
- 2a. If Send Notification to Old Email is enabled, the notification will be sent to the old email.
- 2b. If Send Notification to New Email is enabled, the notification will be sent to the new email.
If authentication is successful, the user email id will be changed.
Account - KOBIL Change Password
This execution has the following main tasks
- To change the password of the user.
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.
Configuration
Parameters involved in Account - KOBIL Change Password execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Password) |
Login Url | Provide the login URL to redirect incase of selecting next step success. |
Select Way of Next Step | Select option to proceed to next step, success will redirect to intermediate page before redirect and continue to move to next step. |
Maximum length of a password | Provide maximum length of the password. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Change password must be preceded by another authenticator since it procures a username from this precedent authenticator. For instance: KOBIL Login for user identification.
- Based on the next step way we choose, whether
Success
orContinue
the response will vary.- 2a. If the next step is chosen as Success, we will be redirected to the success page.
- 2b. If the next step is chosen as Continue, we will be redirected to move to the next step of the process.
Account - KOBIL Change Phone
This execution has the following main tasks
- To add/update the phone number of the user.
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.
Configuration
Parameters involved in Account - KOBIL Change phone execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: phone) |
Force Phone Verification | Enable to force phone verification, even phone is already verified. |
Phone Verification Code TTL | Provide the validity of the verification code. (Example: for days 2d, for hours 2h, for secs 2s.) Default value is 1h. |
Phone Verification Code Length | Length of the SMS code. Default value is 6. |
Show Phone Confirmation | Enable to show phone confirmation view. |
Phone Retry Limit | Phone Retry Limit. Default value is 5. |
Phone Retry Delay | Phone Retry delay in seconds and between every attempts previous time will be doubled: Default value is 5 seconds. |
Template of text to send to the user | Add phone message template, following attributes are supported {first_name}, {last_name}, {code}, and {expiration}. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Change Phone must be preceded by another authenticator since it procures a username from this precedent authenticator. For instance: KOBIL Login for user identification.
- On successful authentication, the user phone number will be added/updated.
- 2a. If the phone number is already present, the OTP will be sent to the new number which we entered, once the user enters the valid OTP the phone number will be updated.
- 2b. If the phone number is not present, the OTP will be sent to the new number which we entered, once the user enters the valid OTP the new number will be added.
Account - KOBIL Change Username
This execution has the following main tasks
- To change the username of the user.
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 |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Change Username must be preceded by another authenticator since it procures a username from this precedent authenticator. For instance: KOBIL Login for user identification.
- On successful authentication, the username will be added/updated.
- 2a. If the provided username is already present, we will be redirected to the error page.
- 2b. If the provided username not available, the username will be updated in authorization server and SSMS as well.
Account - KOBIL Manage Devices
This execution has the following main tasks
- Manage devices will return a list of actions that can be performed for the given user devices (Example: Lock, Unlock and Delete).
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.
Configuration
Parameters involved in Account - KOBIL Manage Devices execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Manage Devices) |
Enable Lock/Unlock Option | Enable to provide lock and unlock options. |
Enable Delete Option | Enable to provide delete options. |
AST Device Delete Action | Select the flow to delete the device from AST. |
Order Devices by | Select on which order the registered device should display for the user. |
Show Success Page | Enable to show success page in the flow. |
Select Way of Next Step | Choose your way to continue the flow. Redirect will move to URL provided in navigation URL. Continue will move to next step. |
Navigation URL | Provide an URL if you need any navigation option from devices page. |
Enable Notifications | Enable to send notifications. |
User Attribute Name for no devices | Provided attribute will be added for user when user deletes all his available devices. NOTE: This is a combination hence if provided, attribute value present below should not be null or empty. |
User Attribute Value for no devices | Provided value will be added for user when user deletes all his available devices. NOTE: This is a combination hence if provided, attribute name present above should not be null or empty. |
User Flow
Execution Flow
This execution contains the following main steps:
KOBIL Manage device must be preceded by another authenticator since it procures a username from this precedent authenticator. For instance: KOBIL Login for user identification.
Based on the next step way we choose, whether
Redirect
orContinue
the response will vary.- 2a. If the next step is chosen as redirect, we will be redirected to the provided URL in configuration tab.
- 2b. If the next step is chosen as Continue, we will be redirected to move to the next step of the process.
On successful authentication, the user device will perform the provided action (Example: Lock, Unlock and Delete).
KOBIL Special Authentication Execution
Condition - ACR KOBIL Cookie
This special execution verifies the ACR claim of the access token against the expression defined in configuration.
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 |
Note: This special execution can be combined with direct grant as well within single flow.
Configuration
Parameters involved in KOBIL Cookie execution
Parameter | Description |
---|---|
Alias | Provide an alias name for the configuration to be set. This will be displayed in the authentication flow configuration. |
Header/Cookie Name | Provide a name of the "key" also called "field, name" sent during client authentication request either in header or in cookie. For Example: 2FA-Token |
| | ACR Value | Provide ACR value which needs to be validated against Token. (Example: 1. Details see table ACR and AMR Values) | | ACR Expression | This is the conditional ACR expression. (Example: if value >= 1 All tokens equals or greater than 1 will match.) |
| Result ACR Value | Provide the ACR value which needs to be added to the token. |
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. Place it before any execution, which should be additionally validated.
User Flow
Execution Flow
If the value matches the conditional expression then it forwards to the next execution. If not and it is set as required then authentication fails.
Authentication request contains header parameter or cookie fields with value of access token. The name of this parameter is to be defined in the configuration.
Condition – KOBIL Scope
This is a special execution which verifies client scope passed in the authorization request against the scope mapped in the configuration of this execution.
With this execution added to the authentication flow, if the requested scope and the scope mapped to the execution are a match, then the authentication succeeds and user login happens.
Note: In this case any other required executions which are part of the authentication flow are skipped.
Use Cases
For instance, let’s assume an authentication flow has the following executions:
KOBIL Login – 1FA
KOBIL Special Authentication: Condition – Scope
mTAN – 2FA
Here once 1FA (i.e) KOBIL Login is completed successfully, KOBIL Special Authentication is executed. If the execution conditions are satisfied, then 2FA (i.e) mTAN is skipped and the user login happens automatically. If the execution fails then 2FA is initiated.
Configuration
Parameters involved in the configuration of Condition - KOBIL Scope execution
Parameter | Description |
---|---|
Alias | Provide an alias name for the configuration to be set. This will be displayed in the authentication flow configuration. |
Scope | Provide the conditional KOBIL scope. |
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.
ACR and AMR Values
Authentication | acr_values (KOBIL) | amr_values (KOBIL) | eIDAS Regulation [(EU) 910/2014 low | substantial | high |
---|---|---|---|---|---|
Cookie/SSO | 0 | cookie | * | ||
KOBIL Login + Password | 1 | k_pwd | * | ||
KOBIL mTAN | 1 | k_mtan | * | ||
KOBIL Verify | 2 | k_verify | * | * | |
KOBIL QR | 2 | k_qr_login | * | * | |
KOBIL Oneshot | 2 | k_oneshot | * | * | |
KOBIL PAM | 2 | k_pam | * | * | |
KOBIL Cookie | 2 | k_jwt | * | * | |
KOBIL mPower Cookie | 2 | k_mpower_cookie | * | * | |
KOBIL SecureSequence | 2 | k_secseq | * | * | |
KOBIL Challenge based OTP | 2 | k_secoptic | * | * | |
KOBIL SecOvid OTP | 2 | k_secovid | * | * | |
FIDO | 2 | fido | * | * | |
FIDO_PIN | 3 | fido_pin | * | * | * |
KOBIL SignPod | 3 | k_signpod | * | * | * |
KOBIL Configure Password
This execution has the following main tasks to configure the user password on IDP Provider.
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.
Configuration
Parameters involved in KOBIL Configure Password execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Configure Password). |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Registration) |
ACR value | This ACR value will be set in the end, if verification succeeds. |
AMR value | This AMR value will be set in the end, if verification succeeds. |
Password Page Title | Configure the content to be displayed in the title on the Password Page. |
Password Page Header | Configure the content to be displayed in the header on the Password Page. |
Validate old password | Checks the old and current password while configuring the password. |
Disable Brute force for Old password field | Checks if an incorrect old password is entered. |
Disable Brute force general error page | If enabled brute force error message shows customised theme page. Else, brute force general error page will be displayed. |
Disable Confirm Password Field | Enable to enter password for password confirmation while configuring password. |
Skip if password exists | The authenticator is skipped if the password is already configured for the user. |
Skip Recent Password Validation | The current password will not be set as new password if the condition is true. |
Password Validation Error Page Header | Configure message to be displayed for password validation error. |
Show Success Page Screen | Enable to show success page in the flow. |
Success Page Title | Text will be displayed in the success page title. |
Success Page Description | Text will be displayed in success page body. |
Success Page Action | Select the option to which flow to be continued after the success page. |
Redirect URL after Success | Configure URL to redirect after the success flow. Execute only when redirect option is selected from Success Page Action configuration. |
Auth Flow Cancel Deep link | Configure deep link to redirect when user abort's the flow. |
New Password PlaceHolder | Configure the text to be displayed in the placeholder of the new password field. |
Password Page Submit Button Caption | Configure the submit button caption of the password page. |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- It is mandatory that KOBIL Configure Password must be preceded by another Authenticator, since it procures username from this precedent authenticator. For instance: KOBIL Verify User Identity for user identification.
- User provides current password.
- User is requested to update the new password and confirm the same.
KOBIL Verify Password
This execution has the following main tasks to verify the user password on IDP Provider and supports AST
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.
Configuration
Parameters involved in KOBIL Verify Password execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Verify password if configured) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Step-Up) |
Reset Bruteforce failure count | Enable to reset OTP Brute Force failure count on successful login. It is disabled by default. |
Invalid credentials message | Message to be displayed when the user credentials invalid. For default : Incorrect password |
User disabled message | Message to be displayed when the user is disabled. Default Message: User is currently disabled, please contact admin. |
User temporarily locked message | Message to be displayed when the user is temporarily locked. Example: User is temporarily locked for %time% minutes. |
Biometric Verification Hyperlink | Configure the link to redirect for biometric verification. |
Reset Credential Hyperlink | Configure the link to redirect for reset credentials. |
ACR value | This ACR value will be set in the end, if verification succeeds. |
AMR value | This AMR value will be set in the end, if verification succeeds. |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- It is mandatory that KOBIL Verify Password must be preceded by another Authenticator, since it procures username from this precedent authenticator. For instance: KOBIL Verify User Identity for user identification.
- User provides password.
- Execution verifies the password in the IDP Provider.
KOBIL Configure User Identity
This execution has the following main tasks to configure the user identity on IDP Provider.
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.
Configuration
Parameters involved in KOBIL Configure User Identity execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Configure Email) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Registration) |
User Identity attribute | User property to identify the user for login validation such as Username, Email and User attribute. Default : Email. |
User Attribute | User attribute value selected for login validation. This should be set only if the User Identity Attribute value is "user attribute" |
ACR value | This ACR value will be set in the end, if verification succeeds. |
AMR value | This AMR value will be set in the end, if verification succeeds. |
User temporarily locked message | Message to be displayed when the user is temporarily locked. Example: User is temporarily locked for %time% minutes. |
OTP temporarily locked message | Message to be displayed when the OTP resend option is temporarily locked. |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Configure User Identity can be used as a standalone execution, since it is used to configure a user. This execution will be used in the registration flow.
KOBIL Verify User Identity
This execution has the following main tasks to verify user identity on IDP Provider.
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.
Configuration
Parameters involved in KOBIL Verify User Identity execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Login with Email) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Login) |
User Identity attribute | User property to identify the user for login validation. Default : Email. |
Display User Identity attribute | User property to be displayed for login validation. |
User Attribute | User attribute value selected for login validation. This should be set only if the User Identity Attribute value is "user attribute" |
Enable Password Check | If enable this will turn on password verification against IDP Provider credentials. |
Reset Bruteforce failure count | If enabled the Bruteforce failure count will be set to 0 on successful login. |
Disable the check for registration status | If enabled, it will disable the check for user registration status. |
Disable show previous input | If enabled, it will erase the previously entered invalid credentials. |
Invalid credentials message | Message to be displayed when the user credentials invalid. For default : incorrect password. |
User disabled message | Message to be displayed when the user is disabled. Default Message: User is currently disabled, please contact admin. |
User temporarily locked message | Message to be displayed when the user is temporarily locked. Example: User is temporarily locked for %time% minutes. |
OTP temporarily locked message | Message to be displayed when the OTP resend option is temporarily locked. |
ACR value | This ACR value will be set in the end, if verification succeeds. |
AMR value | This AMR value will be set in the end, if verification succeeds. |
Show Success Popup screen | Enable to show success popup in the flow. |
Success Popup Title | Text wil be displayed in the success popup title. |
Success Popup Description | Text wil be displayed in the success popup body. |
Is Captcha Required | To support the reCAPTCHA. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Verify User Identity can be used as a standalone execution, since it is used to configure a user. This execution will be used in the login flow.
KOBIL Phone Verification
This execution has the following main tasks:
- To collect and verify the phone number of the user, if the phone number is not available.
- To verify the phone number of the user, if the phone number is already available.
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.
Configuration
Parameters involved in KOBIL Phone Verification execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Phone Verification) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Login). |
Enter if phone is verified | Proceeds for authentication only if the phone number is verified. |
Phone Verification Code Length | Length of the SMS code. The default value is 6. |
Phone Verification Code TTL | Provide the validity of the verification code. (Example: for days 2d, for hours 2h, for secs 2s.) Default value is 1h. |
Show Phone Confirmation | Enable to show phone confirmation view. |
Get user by Phone Number | Enable to fetch user with phone number. |
Query User From | Query the user based on username or user attribute(phone_number) from the dropdown. |
Select Default Region Code | the default displaying national flag in Phone Number page can be selected |
Ask phone number everytime if not verified | Enable to ask phone number untill verified. |
Template of text to send to the user | Add phone message template, following attributes are supported {first_name}, {last_name}, {code}, and {expiration}. |
Resend Interval Duration | Time duration for resend code interval. |
Retry Attempt Exceeded | To display the retry exceeded message along with the timer. |
ACR value | This ACR value will be set in the end, if verification succeeds. |
AMR value | This AMR value will be set in the end, if verification succeeds. |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Phone Verification must be preceded by another authenticator since it procures a username from this precedent authenticator. For instance: KOBIL Login for user identification.
- The OTP will be sent to the phone number which we entered, once the user enters the valid OTP, the user phone number will be added on successful authentication.
KOBIL Email Verification
The main task of this execution is to verify the Email of the user.
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.
Configuration
Parameters involved in KOBIL Email Verification execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Email Verification) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Login) |
Email Verification Code Length | Length of the Email Verification code. The default value is 6. |
Email Verification type | Email to be verified by OTP or link. Default is OTP. |
Email Verification Code TTL | Provide the validity of the verification code. (Example: for days 2d, for hours 2h, for secs 2s.) Default value is 1h. |
Email OTP Expired Mesage | Message to be displayed when the user enters expired OTP. |
Show Email Confirmation | Enable to show email confirmation view. |
Retry Attempt Exceeded | To display the retry exceeded message along with the timer. |
OTP Resend Attempt Exceeded | To display the OTP Resend Attempt exceeded message along with the timer. |
Reset OTP Bruteforce failure count | Enable to reset OTP Brute Force failure count on successful login. It is disabled by default. |
Reset Bruteforce failure count | If enabled, OTP failure count will be reset to 0 after the successful login. |
ACR value | This ACR value will be set in the end, if verification succeeds. |
AMR value | This AMR value will be set in the end, if verification succeeds. |
REG Enable Session OTP Bruteforce | Enable the Session OTP brute force. Enabled only for the Registration flow. |
REG Max Session OTP Resend | Number of re-tries a user is allowed to do. (Example: 10, Default: 5). Used only in the Registration flow |
REG Wait Increment | Wait time (in seconds) for the user, if the user gets locked. (Example: 3600, Default: 5). Value has to be in seconds. |
Resend Interval Duration | Enter the duration for for Resend code interval. |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Email Verification must be preceded by another authenticator since it procures a user from this precedent authenticator. For instance: KOBIL Verify User Identity for user identification.
- The OTP / link will be sent to the email, which was already available for the user, once the user enters the valid OTP or clicks the link, then the email will be verified for the User.
KOBIL Create Account
This execution has the following main tasks
- To create an account for the user, if the Email is not yet available in the IDP.
- If the email exists for a user and not verified, delete the existing account and create a new account with the Email and user's current Email verification status.
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.
Configuration
Parameters involved in KOBIL Create Account execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Phone Verification) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Registration) |
Create Anonymous User | If enabled, creates a user with random UUID as username. |
Update Existing User | Update existing user or delete the user and create a new user. |
Skip Registration Success Page | If enabled, the success page will not be displayed after registration completion. |
JSON Script | JSON display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Create Account must be preceded by 1FA since it procures a user's identity validation from this precedent Authenticator. For instance: KOBIL Configure User Identity.
- If a user account with specified Email Id is already present in IDP, the old account for that user will be removed and the new user will be registered with the verification status of email.
Condition - Email Verification
The main task of this execution will allow the next flow to proceed only if the user has an email and it is not verified and Vice Versa. It can be changed in the authenticator config.
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.
Configuration
Parameters involved in Condition - Email Verification execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Login Verify Email) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Login). |
Check Email not verified | Enable to proceed the flow only when the user has email and it is not verified. |
User Flow
Execution Flow
This execution contains the following main steps:
- Condition Email verification must be in conditional flow and the flow must be preceded by another authenticator since it procures a user from this precedent authenticator. For instance: KOBIL Configure User Identity for the user registration.
KOBIL Condition - ACR Selection
This execution contains the following main steps:
- This Execution needs the expected step-up ACR value and current ACR value from the session and the respective execution ACR value which is set in the config.
- This Conditional Execution will allow the next execution to proceed only if the expected step-up ACR value and respective execution ACR value is greater than the current ACR value of the user.
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.
Configuration
Parameters involved in KOBIL Condition - ACR Selection execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Provide an alias name for the configuration to be set. (Example: ACR 1) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Step-Up) |
Respective ACR value | Respective ACR value of succeeding authenticator. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Condition - ACR Selection must come under conditional flow and it must be succeeded by password, email, phone authenticators (KOBIL Login), since it procures expected step-up ACR value and current ACR value from the session from KOBIL Configure ACR authenticator.
- This execution will be used only for Step-Up flow.
- Refer ACR value
KOBIL Configure ACR
This execution contains the following main steps:
- To verify and validate the token and set user in context.
- To extract the expected step-up ACR value from the scope and current ACR value of the user from token and setting both of them in session.
- It will get succeeded only the expected step-up ACR value is greater than the current ACR value.
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.
Configuration
Parameters involved in KOBIL Verify Password execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Provide an alias name for the configuration to be set. (Example: ACR 1) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Step-Up) |
User Flow
Execution Flow
This execution contains the following main steps:
- The execution is basically a conditional execution, which needs scope and token, astClientId as input from the header, in which the token should contain ACR and AMR values
- If the expected step-up ACR value is greater than the current ACR value of the user, then the flow will move to the next execution otherwise, the flow gets succeeded.
- This execution will be used only for Step-Up flow.
KOBIL Configure User Details
The main task of this execution is to configure a User with details such as first name, last name and other custom user attributes.
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.
Configuration
Parameters involved in KOBIL Configure User Details execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Configure user Details) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Registration) |
ACR value | This ACR value will be set in the end, if verification succeeds |
AMR value | This AMR value will be set in the end, if verification succeeds |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Configure User Details must be preceded by another authenticator since it procures a user from this precedent Authenticator. For instance: KOBIL Configure User Identity for user identification. This execution will be used in the registration flow.
KOBIL Change Email
The main task of this execution is to change the Email ID of the User.
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.
Configuration
Parameters involved in KOBIL Change Email execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Configure user Details) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Registration) |
User Identity attribute | User property to identify the user for login validation. Default : Email. |
Display User Identity Attribute | User property to be displayed for login validation. |
User Attribute | User attribute value selected for login validation. This should be set only if the User Identity Attribute value is "user attribute" |
Enable Password Check | If enable this will turn on password verification against IDP Provider credentials. |
Reset Bruteforce failure count | If enabled the Bruteforce failure count will be set to 0 on successful login. |
Invalid User ID message | Message to be displayed when the user ID is invalid or user not found. |
Invalid credentials message | Message to be displayed when the user credentials invalid. For default invalid username or password. |
User disabled message | Message to be displayed when the user is disabled. Default Message: User is currently disabled, please contact admin. |
User temporarily locked message | Message to be displayed when the user is temporarily locked. Example: User is temporarily locked for %time% minutes. |
ACR value | This ACR value will be set in the end, if verification succeeds |
AMR value | This AMR value will be set in the end, if verification succeeds |
Show Success Popup Screen | Enable to show success popup in the flow. |
Success Popup Title | Text wil be displayed in the success popup title. |
Success Popup Description | Text wil be displayed in the success popup body. |
Email Verification Code Length | Length of the Email Verification code. The default value is 6. |
Email Verification type | Email to be verified by OTP or link. Default is OTP. |
Email Verification Code TTL | Provide the validity of the verification code. (Example: for days 2d, for hours 2h, for secs 2s.) Default value is 1h. |
Email OTP Expired Message | Message to be displayed when the user enters expired OTP. |
Email Verified Message | Message to be displayed when the Email is verified. |
Show Email Confirmation | Enable to show email confirmation view. |
Retry Attempt Exceeded | To display the retry exceeded message along with the timer. |
Reset OTP Bruteforce failure count | Enable to reset OTP Brute Force failure count on successful login. It is disabled by default. |
REG Enable Session OTP brute force | Enable the Session OTP brute force. Enabled only for the Registration flow. |
REG Max Session OTP Resend | Number of re-tries a user is allowed to do. (Example: 10, Default: 5). Used only in the Registration flow. |
REG Wait Increment | Wait time (in seconds) for the user, if the user gets locked. (Example: 3600, Default: 5). Value has to be in seconds. |
Resend Interval Duration | Enter the duration for for Resend code interval. |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Change Email must be preceded by another authenticator since it procures a user from this precedent Authenticator. For instance: KOBIL Configure User Identity for user identification.
- User will provide email ID and password, If the email is not registered with any user, the password will be validated.
- Once the password validation succeeds , OTP will be sent to the mail. If the OTP is verified, the user will be verified with email.
KOBIL eTan
The main task of this execution is to verify the email and also support AST Service as well as SSMS based installations.
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.
Configuration
Parameters involved in KOBIL eTan execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Email Confirmation) |
Authentication Flow Type | Type of flow for which the authenticator is used. (Example: Reset-credentials) |
User Identity attribute | User property to identify the user for login validation. Default : Email. |
User Attribute | User attribute value selected for login validation. This should be set only if the User Identity Attribute value is "user attribute". |
Enable Password Check | If enable this will turn on password verification against IDP Provider credentials. |
Reset Bruteforce failure count | If enabled the Bruteforce failure count will be set to 0 on successful login. |
Invalid User ID message | Message to be displayed when the user ID is invalid or user not found. |
Invalid credentials message | Message to be displayed when the user credentials invalid. For default invalid username or password. |
User disabled message | Message to be displayed when the user is disabled. Default Message: User is currently disabled, please contact admin. |
User temporarily locked message | Message to be displayed when the user is temporarily locked. Example: User is temporarily locked for %time% minutes. |
ACR value | This ACR value will be set in the end, if verification succeeds |
AMR value | This AMR value will be set in the end, if verification succeeds |
Show Success Popup Screen | Enable to show success popup in the flow. |
Success Popup Title | Text wil be displayed in the success popup title. |
Success Popup Description | Text wil be displayed in the success popup body. |
Email Verification Code Length | Length of the Email Verification code. The default value is 6. |
Email Verification Code TTL | Provide the validity of the verification code. (Example: for days 2d, for hours 2h, for secs 2s.) Default value is 1h. |
Email OTP Expired Message | Message to be displayed when the user enters expired OTP. |
Show Email Confirmation | Enable to show email confirmation view. |
Retry Attempt Exceeded | To display the retry exceeded message along with the timer. |
OTP temporarily locked message | Message to be displayed when the OTP resend option is temporarily locked. |
Reset OTP Bruteforce failure count | Enable to reset OTP Brute Force failure count on successful login. It is disabled by default. |
REG Enable Session OTP brute force | Enable the Session OTP brute force. Enabled only for the Registration flow. |
REG Max Session OTP Resend | Number of re-tries a user is allowed to do. (Example: 10, Default: 5). Used only in the Registration flow. |
Allow non-existent user | If enabled, non-existent user will not get blocked instead the user will be redirected to OTP page to not reveal whether the user has an account. |
REG Max Session OTP Resend | Number of re-tries a user is allowed to do. (Example: 10, Default: 5). Used only in the Registration flow |
REG Wait Increment | Wait time (in seconds) for the user, if the user gets locked. (Example: 3600, Default: 5). Value has to be in seconds. |
Resend Interval Duration | Enter the duration for for Resend code interval. |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL eTan must be preceded by another authenticator since it procures a user from this precedent Authenticator. For instance: KOBIL Configure User Identity for user identification. This execution will be used in the registration flow.
KOBIL Delete Account
The main task of this execution is to Delete the User account.
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.
Configuration
Parameters involved in KOBIL Delete Account execution
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Delete Account) |
Verify User Identity | If enabled, the user identity is verified in addition to password validation. |
User Identity attribute | User property to identify the user for login validation. Default : Email. |
User Attribute | User attribute value selected for login validation. This should be set only if the User Identity Attribute value is "user attribute" |
Invalid User ID message | Message to be displayed when the user ID is invalid or user not found. |
Reset Bruteforce failure count | If enabled the Bruteforce failure count will be set to 0 on successful login. |
Invalid credentials message | Message to be displayed when the user credentials invalid. For default invalid username or password. |
User disabled message | Message to be displayed when the user is disabled. Default Message: User is currently disabled, please contact admin. |
User temporarily locked message | Message to be displayed when the user is temporarily locked. Example: User is temporarily locked for %time% minutes. |
Proceed account deletion message | Message to be displayed when requesting the user to proceed for account deletion. |
Confirm account deletion message | Message to be displayed when requesting confirmation from the user to delete the account. |
Account deletion failed message | Message to be displayed when user deletion gets failed. |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
KOBIL Delete Account must be preceded by 1FA since it procures a user's identity validation from this precedent Authenticator. For instance: KOBIL Configure User Identity.
The user will be prompted to enter his/her password. If the password validation succeeds the user account will be deleted.
AST Login
The main task of this execution is to perform Actions Configuration on AST services.
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.
Configuration
Parameters involved in AST Login execution
Parameter | Description |
---|---|
Alias | Display name of configuration, which occurs in authentication flow. (Example: AST Login) |
Action | Select the action which the authenticator should perform. |
MLoA | Select MLoA value for the user. |
AST Client ID Optional | Enable to make AST Client ID optional for AST activation. |
Set hidden first factors | Enable to set user attribute hiddenfirst_factor{astClientId} as password after activation. |
Read AST Client ID and Client Data from session | Enable to always read AST Client ID and Client Data from session. |
prompt user before unbind all | If enabled it will request for confirmation before unlinking the device(s) in Confirmation screen. If disabled it will unlink without Confirmation screen. |
JSON Script | To display the prompt information in JSON Headless V2 theme, when Prompt user before unbind all is enabled. |
User Flow
Execution Flow
This execution contains the following main steps:
- AST Login must be preceded by 1FA since it procures a user's identity validation from this precedent Authenticator. For instance: KOBIL Username Password Form.
- The AST Login authenticator will perform actions (login, activate, etc) based on the configs, it provides support for the AST service.
Condition ID Verification
The main task of this execution is to check if the User is available.
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.
User Flow
Execution Flow
This execution contains the following main steps:
- Condition ID Verification must be preceded by another authenticator since it procures a user validation from this precedent Authenticator. For instance: KOBIL Cookie for user validation.
- This authenticator verifies if the User is already registered or not and triggers Registration/Login flow accordingly.
KOBIL ID Card Registration
The main task of this execution is to check if the User is Registered.
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.
Configuration
Parameters involved in KOBIL ID Card Registration
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: KOBIL ID Card Reg) |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL ID Card Registration must be preceded by another authenticator since it procures a user validation from this precedent Authenticator. For instance:KOBIL Cookie, Condition - ID Verification, KOBIL ID Card Registration for user validation.
- This Authenticator registers User by getting data from the User and verifies with External Server.
KOBIL ID Card Login
The main task of this execution is to Login a Registered User.
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.
Configuration
Parameters involved in KOBIL ID Card Login
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: ID Card Login) |
Face Login Required | If enabled, the Face Login is required after ID card Login. |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL ID Card Login must be preceded by another authenticator since it procures a user validation from this precedent Authenticator. For instance: KOBIL Cookie, Condition - ID Verification, KOBIL ID Card Registration for user validation.
- The Authentication session created in the External server at the begining and the nonce and mrz_info are sent to the app from IDP.
- The User will send back response to IDP before the session ends in the External server.
KOBIL Face Login
The main task of this execution is to Login an user through Face Login.
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.
Configuration
Parameters involved in KOBIL Face Login
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: Face Login) |
JSON Script | JSON to display inputs in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Face Login must be preceded by another authenticator since it procures a user validation from this precedent Authenticator. For instance: KOBIL Cookie, Condition - ID Verification, KOBIL ID Card Registration for user validation.
- The IDP receives the base64 data of User's selfie and sends it to External Server for verification and back to the Authentication response to the application.
KOBIL User Group Registration
The main task of this execution is to add a User to a Configured Group.
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.
Configuration
Parameters involved in Condition ID Verification
Parameter | Description |
---|---|
ID | Unique system UUID, which will be assigned automatically. |
Alias | Display name of configuration, which occurs in authentication flow. (Example: User Group) |
User Group | Add User to the group only if available. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL User Group Registration must be preceded by 1FA since it procures a user's identity validation from this precedent Authenticator. For instance: KOBIL Configure User Identity.
- When an User executes into the flow, the user will be mapped to the configured group.
KOBIL AST TMS
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.
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.
Configuration
Parameters involved in KOBIL AST TMS
Parameter | Description |
---|---|
Alias | Display name of configuration, which occurs in authentication flow. (Example: User Group) |
Execute based on ACR flow type | If enabled, execution will be based on the session data. |
TMS Timeout | TMS timeout for transaction process. |
Retrieval Timeout | Duration of the transaction. |
Require Explicit Authentication | Whether the TMS result must be submitted with an specifically authenticated token. |
Require Freshness of Authentication | The maximum age in seconds the access token may have when submitting the TMS result. Default value is -1 to omit this requirement. |
Audit Message | An optional message that is written to auditing. |
Enable auto polling for tms result | Enable polling for tms result to get accept/decline response, else user has to manually click on validate button to get the tms result. |
Enable TMS result validation with Kafka response | Check TMS result retrieved in kafka topic before taking response from ast result endpoint, Config applies only if Poll for tms result is disabled. |
Skip TMS | Skip triggering TMS, when it is not a transaction flow and new device registration. |
Enable broadcasting TMS | Enable to initiate transactions for the latest logged-in/activated devices. |
Authentication Flow Type | Type of the Authentication Flow. |
ACR level to list devices | Devices to list for sending tms request with greater than or equal to specified ACR (Note: Not applicable for flow type Step-Up). |
Skip If No Target ACR Devices | If enabled the transaction will be skipped. Else, authenticator will be excecuted. |
Web portal device name | Configure the device name to be displayed in the web portal. |
Enable TMS Push Notification | Enable to send contents present in the Push notification title and Push notification body . |
Push notification title | Configure the specific push notification title's message key to fetch value from Realm localization with locale support or message bundles will send actual title text to the Master device. |
Push notification body | Configure the specific push notification text's message key to fetch value from Realm localization with locale support or message bundles will send actual title text to the Master device. |
Show success page | Enabled to show the success page after completing the TMS flow. |
Transaction Message | Message to be sent as a part of TMS. Use placeholders {userid} and {token} to send login. |
Skip JSON Script | If enabled JSON script will not be displayed. |
Skip Device Selection | Enabled and device ID should present in the header so that device selection option can be skipped. |
JSON Script | JSON to display inputs in Headless V2 theme. |
JSON Error Script | JSON to display the error messages in Headless V2 theme. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL AST TMS must be preceded by 1FA since it procures a user's identity validation from this precedent Authenticator. For instance: KOBIL Username Password Form.
- When an User executes into the flow, the user will be authenticated and the transaction will be intiated.
Note: The TMS Transaction Keys are required to trigger the transaction.
KOBIL Magic Link
The main task of this execution is to authenticate user through email via link.
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.
Configuration
Parameters involved in KOBIL AST TMS
Parameter | Description |
---|---|
Alias | Display name of configuration, which occurs in authentication. |
Allow Login Directly with Magic Link | Authenticate user through email via link. |
Reset password | Allows users to reset their password by clicking on the Magic Link if the parameter is enabled. Else, users will not be able to reset their password. |
Redirect URI | Configure the URI to which the user will be redirected after authentication. |
Magic Link Email Subject | Configure the subject of the email. |
User Flow
Execution Flow
This execution contains the following main steps:
- KOBIL Magic Link must be preceded by 1FA since it procures a user's identity validation from this precedent Authenticator. For instance: KOBIL Username Password Form.
- User's identity is validated with KOBIL Username Password Form .
- Magic link (2FA) is initiated to verify the user with Email and continue the Login.
KOBIL Maintenance Page
The main task of this execution is to display the information about the page. For example: under maintenance.
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.
Configuration
Parameters involved in KOBIL Maintenance Page
Parameter | Description |
---|---|
Alias | Display name of configuration, which occurs in authentication flow. (Example: User Group) |
Maintenance info JSON | JSON to display inputs. |
User Flow
Execution Flow
This execution contains the following main steps:
- When user excecutes the flow, an information about the page will be displayed.
KOBIL - Store AST Headers to Session
The main task of this execution is to save AST Client ID and Client Data present in the header to the session. Hence, the value can be used throughout the flow.
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
Click on Add Execution
and select KOBIL - Store AST Headers to Session authenticator and mark the authenticator as REQUIRED
.
User Flow
Execution Flow
This execution contains the following main steps:
- When user excecutes the flow, it will save the AST Client ID and Client Data present in the header to the session.
KOBIL Register Security Question
The main task of this execution is to select and register the answer for the security questions provided in the auth config.
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.
Configuration
Parameters involved in KOBIL Register Security Question
Parameter | Description |
---|---|
Alias | Display name of configuration, which occurs in authentication flow. (Example: Security Question) |
Minimum Number Of Answers | Config minimum number of questions to be answered. |
JSON Script | JSON to display inputs in Headless V2 theme. |
JSON Error Script | JSON to display the error messages in Headless V2 theme. |
Registration Policy Regex | Policy to validate security question answers. |
Registration Policy Regex Info Text | Configure the message which will guide users, when their answer does not match the specified criteria. |
User Flow
Execution Flow
- KOBIL Register Security Question must be preceded by 1FA since it procures a user's identity validation from this precedent Authenticator. For instance: KOBIL Username Password Form.
- User's identity is validated with KOBIL Username Password Form .
- KOBIL Register Security Question (2FA) is initiated to select and register the answer for the security questions provided in the auth config.
KOBIL Validate Security Question
The main task of this execution is to verify the answer for the registered security question.
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.
Configuration
Parameters involved in KOBIL Validate Security Question
Parameter | Description |
---|---|
Alias | Display name of configuration, which occurs in authentication flow. (Example: Security Question) |
Display any one question | Enable to display single question from the registered question. If disabled minimum configured security question will be validated. |
JSON Script | JSON to display inputs in Headless V2 theme. |
JSON Error Script | JSON to display the error messages in Headless V2 theme. |
User Flow
Execution Flow
- KOBIL Validate Security Question must be preceded by 1FA since it procures a user's identity validation from this precedent Authenticator. For instance: KOBIL Username Password Form.
- User's identity is validated with KOBIL Username Password Form .
- KOBIL Validate Security Question (2FA) is initiated to verify the answer for the registered security question.
Kobil Captcha
The main task of this execution is initiated to prevent bot spamming.
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.
Configuration
Requirements in Realm Settings
In order to get the Google reCAPTCHA, the following configurations are required:
CAPTCHA_SITE_KEY, CAPTCHA_SECRET_KEY required to be updated in the Realm settings.
In the
Content-Security-Policy
parameter field, [frame-src 'self' https://www.google.com.] must be added.(Pathway: Realm-settings -> Security-defences -> Headers -> Content-Security-Policy)
Parameters involved in Kobil Captcha
Parameter | Description |
---|---|
Alias | Display name of configuration, which occurs in authentication flow. (Example: Kobil Captcha) |
JSON Script | JSON to display inputs in Headless V2 theme. |
JSON Error Script | JSON to display the error messages in Headless V2 theme. |
User Flow
Execution Flow
- GOOGLE reCAPTCHA site key is initiated along with KOBIL Username Password Form.
- Captcha response are validated with the GOOGLE reCAPTCHA API.
- User logs into the application using valid captcha and KOBIL Username Password Form.
KOBIL AST Claims
The main task of this execution will be calculating ACR and AMR values and stored in the session.
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.
Configuration
Parameters involved in KOBIL AST Claims
Parameter | Description |
---|---|
Alias | Display name of configuration, which occurs in authentication flow. (Example: AST Claims ) |
First Factor | If enabled the first factor for the user is retrieve and persisted in the current session. |
ACR | If enabled the ACR value for the user is retrieved and persisted in the current session. |
AMR | If enabled the AMR value for the user is retrieved and persisted in the current session. |
User Flow
Execution Flow
- KOBIL AST Claims must be preceded by 1FA since it procures a user's identity validation from this precedent Authenticator. For instance: KOBIL Login.
- User's identity are validated using KOBIL Login .
- KOBIL AST Claims authenticator where the current ACR and AMR values are calculated and stored in the session.
KOBIL Condition - User Role
The main task of this execution is to verify multiple Roles of the user.
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.
Configuration
Parameters involved in KOBIL Condition - User Role
Parameter | Description |
---|---|
Alias | Display name of configuration, which occurs in authentication flow. (Example: User Role) |
Roles To Check | Configure the Roles to be verified while authenticating. |
Should be assigned all roles | If enabled all the Roles configured in the Roles To Check will be mandatory to authenticate. |
Negate output | If enabled the output will be turned to negative. |
User Flow
Execution Flow
- KOBIL Condition - User Role must be preceded by 1FA since it procures a user's identity validation from this precedent Authenticator. For instance: KOBIL Username Password Form.
- User's identity is validated with KOBIL Username Password Form.
- KOBIL Condition - User Role authenticator is to verify multiple Roles of the user.