Adaptive authentication (AA), also known as risk-based authentication, is a subset of multifactor authentication and seeks to match the requirement for certain user credentials, with the perceived risk posed by the authentication requested.
The factors below will be taken into consideration when developing Multi-Factor Authentication (MFA) to prove that someone or something has the right identity:
- Things you know (knowledge), such as a password or PIN
- Things you have (possession), such as an OTP, tokens or certificates
- Things you are (inherence), such as a biometric like fingerprints or voice recognition
AA is an authentication model that seeks to reduce the burden of authentication on users, providing a better experience, while on the other hand ensuring the right levels of security where and when necessary.
Issues with Multi Factor Authentication (MFA)
- More cumbersome for the user but without awareness of the situation ie swapped SIMs, stolen phones etc
- Adds unnecessary cost for the authentication steps, such as SMS cost or push notification cost when the situation doesn’t necessary it
- Having more steps in the authentication flow always impacts the performance of the CIAM solution.
For example, if you are accessing an application from a public network,MFA is a great way to ensure appropriate security and authentication of the user, however, using the same MFA when the user is accessing from home or their corporate network will add unnecessary overheads to the system as well as requiring an unnecessarily cumbersome customer experience.
What are the deciding factors for Adaptive Authentication?
- More cumbersome for the user but without awareness of the situation ie swapped SIMs, stolen phones etc
- Adds unnecessary cost for the authentication steps, such as SMS cost or push notification cost when the situation doesn’t necessary it
- Having more steps in the authentication flow always impacts the performance of the CIAM solution.
For example, if you are accessing an application from a public network,MFA is a great way to ensure appropriate security and authentication of the user, however, using the same MFA when the user is accessing from home or their corporate network will add unnecessary overheads to the system as well as requiring an unnecessarily cumbersome customer experience.
Location & Network: Where is the user when trying to access information, home, office, abroad? Is the connection via private or public network? Is the network and location known and secure?
Device: Whether the device is corporate-managed, and whether the device has had previous access.
Time: Is access being requested at unusual times, for example from the office at 3 am or during the weekend, public holidays. Mostly time will be used in conjunction with other factors such as IP information to find the appropriate authentication option.
User’s Claims/Attributes: Authentication is based on the permissions of the user. Here, before the authentication is done, the role of the relevant attribute from the user must be retrieved. This information can be scraped from a landing screen or as a parameter in the authentication request itself.
Analytics related decision: Collects previous events and real-time request information, detects complex event patterns and uses machine learning models to decide on the MFA method.
How Adaptive Authentication Works
The diagram below explains how AA works. It can be implemented as a single option or as a mixture of the 3 options available depending on the authentication needs based on the AA deciding factors discussed above.
Image 1 : MFA Decision – Adaptive Authentication
Use Cases
1. Location – If a user accesses the system through their known corporate network, that will prompt basic authentication, while the same user accessing the system through an external network will trigger MFA authentication eg: One Time Password (OTP)
2. Role – Users login to a system which has different types of roles such as Admin, Supervisor and Operator. The Admin and Supervisor authentication will use OTP, simply because their access and permissions present a greater risk than that of the Operator, who will have basic authentication.
3. Group Authentication – Users have a single login that authenticates them across ABC group of companies, so they can have access to multiple applications. Each company has a different Identity Provider (IDP) and the username and password they use for their own company within the group.
4. Mitra, X and Y are the companies under LMN Group recently bought Application Z. The IT department of LMN group is currently working on enabling authentication for all users of the Group to access the application Z. Propose a solution for this integration.
- Please note that all 3 companies have different email domains for their users and their email address is used as their username.
- a user in Mitra company, username is adesilva@mitrai.com
- a user in X company, username is asfenandu@x.com
- a user in Y company, username is akperera@y.com
- Build an integrated authentication solution to support the above scenario.
How to Build Adaptive Authentication from WSO2 IAM
There are many popular CIAM solutions that support the AA concept in the industry. WSO2 IAM is one of the best open-source solutions, supporting AA.
The AA script in WSO2 IAM from JavaScript, the core API reference has functions and fields, refer here for more information.
- 1. Script Function Creation
- Go to WSO2 IAM admin console –> Manage –> Function Libraries –> Write the Function
Sample Script File
utilFunction = require('utilFunction.js'); // Reference other adaptive script from the script successResponseMessage = { // define object ‘status’: 90001 ‘statusMsg’: ‘External API call Success’, }; var onLoginRequestProcess = function(requestIp) { var networkData = utilFunction.getCorporateNetworkData(requestIp); // API call to get some other data httpPost(utilFunction.externalEndpoint, networkData,{ onSuccess: function(context, jsonResponse) { Log.info(“External API call success.”); // Instruct to execute steps defined in Authentication step configuration of SP // Based on the response, each condition can be implemented like below executeStep(1, { authenticationOptions: [{ idp: ‘IDPNameAssignInTheStep’ }] }, { onSuccess: function (context) { Log.info(“Success” + successResponseMessage.status ); } }); }, onFail: function(context, jsonResponse) { Log.info(“External API call failed!”); }, onTimeout: function (context, jsonResponse) { Log.info(“External API request timeout.”) } }); }; // How to make the method public to call from another script file or Adaptive Authentication script under the Authentication //steps of Service provider application module.exports.onLoginRequestProcess = onLoginRequestProcess;
- Apply the Script to the Authentication Flow
- The Adaptive script should be applied to the Service Provider (SP) application in the WS02 IAM
- The service provider is the entity that configures how to authenticate someone/something to the Identity Server, and the authentication steps are defined there. Adaptive Script applies under the ‘Script Based Adaptive Authentication’ of Authentication Step Configuration in the Local & Outbound Authentication configuration section.
Image 2 : Sample Advanced Authentication Configuration of SP in WSO2 IAM
- Apart from defining the dynamic authentication sequence configuration, the below functions can be achieved using adaptive script in WSO2 IAM.
- Execute extra functions after authentication, eg authorisation, this can be an external endpoint to authorise the user, or internal validation against the role and permissions based on the user claims
- Ability to process the user attributes after authentication eg: combining or splitting before sending them back to the application. eg: If the user’s Firstname is Kamali and the Lastname is Perera, and the calling application requires Fullname, then simply combine the Firstname and Lastname, Fullname is then sent as Kamali Perera.
- Adding extra analytics
b. Add the script based Adaptive Authentication function as below
var authenctaionHandler = require('authenctaionHandler.js');// Script File name
var onLoginRequest = function(context) {
authenctaionHandler.onLoginRequestProcess(context); // method to execute
for the discovery process
};
Configure other steps with the relevant local Authenticators and Federated Authenticators, see script below eg: ‘Step 1’ as 1 (Refer Image 2)
For Example: With only the stepId
executeStep(1); // This will execute the first step
configured under Authentication step configuration
With only the stepId and eventCallbacks
executeStep(1, { onSuccess: function(context) { //Implement the flow after successfully completing the step 1 } });
With the stepId, options, and an empty eventCallbacks array
executeStep(1,{ authenticationOptions:[{ authenticator: ‘authenctaorname’ // Execute the initialized authenticator as a first step }]}, });
- How to Test the Flow
- Develop a sample application by using Security Assertion Markup Language (SAML) or OpenIDConnect (OIDC) protocol
- SAML Sample : https://is.docs.wso2.com/en/5.10.0/learn/deploying-the-sample-app/
- OIDC Sample : https://is.docs.wso2.com/en/5.10.0/learn/testing-oidc-encrypted-id-token-with-is/#setup-playground-sample
- Create a Service provider application in WSO2 IS and add OIDC or SAML inbound authentication. Update the application configuration in the sample application configuration files with the created SP information.
- Deploy the Sample application to the web server eg: apache-tomcat and update the appropriate configuration to creating the Service Provider application in IS
- Login to the Sample application, then authentication will be performed through the IAM SP application.
Anusha Ruwanpathirana
Associate Software Architect
