Introduction to Adaptive Authentication with WSO2 Identity Server 5.7.0 Release
Before going to discuss what adaptive authentication is, the question is why adaptive authentication is important. As we all know for today’s world relying on simple username and password authentication is not enough to protect critical business data and systems against number of growing cyber attacks. Next step is having multi factor authentication. What is multi factor authentication in brief.
- Something you know (such as a password, PIN, answer to security question)
- Something you have (a token, card, certificate, key, app instance, or other unique item)
- Something you are (a fingerprint, a typing behavior, a retinal pattern, a voice print)
If you want to provide strong authentication having single factor is not enough. Ex: Having two passwords in the authentication flow is not a good secure design. That is why now a days most of cloud service providers such as Google, Yahoo, Facebook, AWS, Salesforce, Office365 …etc supports two factor authentication.For an example if you enable multi factor authentication for Gmail in the first step you will get username password login page which is something you know then in the second step you will get a page to enter the OTP (one time password) received to the mobile which is something you have.
Do I need to provide multi factor authentication every time ??? Does it kill usability ???
So the next challenge is how do you combine multiple factors to provide strong authentication based on risk associate with particular user profile or authentication request (risk based authentication) or ACR (Authentication Context Reference). I suppose still some of you may confused with above statement :D Let me give you couple of practical examples.
Case 01: You want to enable second factor authentication only if authentication request coming from external IP address. If authentication request coming from internal IP address then you want to bypass second factor.
Case 02: If authenticated user from first authentication step has admin role then he should be able to bypass second factor authentication.
Case 03: Based on login history if anomalies detected then multi factor authentication should be enabled.
Case 04: You want to deny authentication to salesforce during weekends.
Case 05: Authentication request itself describe the required strongness for authentication by using acr_values. If you are familiar with mobile connect specification it defines acr_values as LoA1, LoA2, LoA3, LoA4. LoA1 is the minimum level of authentication, LoA2 should you “something you have” factor, LoA3 should have two factors like “something you know and something you have”. You can refer level of assurance [1] for more information.
Adaptive Authentication is the next Era of Identity and Access management where you can find sophisticated solution under one umbrella for all of above use cases.
Let’s move on to Power of WSO2 Identity Server 5.7.0 with Adaptive Authentication support. At the time I am writing this blog WSO2 Identity Server 5.7.0 beta-2 has already been released and hope to see GA release soon with most exciting feature.
If you are new to the journey of WSO2 Identity Server [2] is a good read.
We can walk through couple of use cases to understand how adaptive authentication works with WSO2 Identity Server.
If you are already familiar with previous releases of WSO2 Identity Server (before version 5.7.0)
Create a Service provider → navigate to Local and Outbound Authentication Configuration → Advanced Configuration, you will seen an UI as below

But if you follow same steps in WSO2 Identity SerVer 5.7.0 UI will be look like below. The idea is in addition to sequential authentication steps you can configure how to navigate through different authentication steps via JavaScript.

Under Authentication Step Configuration you can configure any number of authentication steps by mixing local and federated authenticators. Under Script Based Adaptive Authentication you can write JavaScript to navigate via different authentication steps. Furthermore in the right hand side you have set of predefined templates for known use cases such as User-Age-Based, Role-Based, ACR-Based, IP-Based.
Let me take Role-Based template and explain the syntax.

Assume Step 1 configured with Basic Authenticator, Step 2 configured with Fido Authenticator. Authentication step sequence is decided by JavaScript configuration. The idea is first execute authentication step-01. If step-01 is successful then execute the function onSuccess in line 11. context.currentKnownSubject provide a reference to authenticated user. In line 15 there is a JavaScript API called “hasAnyOfTheRole” to check whether user in particular role or not (For more JS API references you can check [4]). If user has “admin” or “manager” role step 2 will be executed before completing authentication flow if user doesn’t have any of role “admin” or “manager” then authentication flow will be completed immediately after step 1.
To get more clear idea have a look at another example
function onLoginRequest(context) {executeStep(1, {
onSuccess: function (context) {
var user = context.steps[1].subject;
Log.info(user.username);
var isAdmin = hasRole(user, ‘admin’);
if (!isAdmin) {
sendError(‘http://www.example.com/error’,{‘errorcode’:’000403',’errorMsg’:’You are not allowed to login to this app.’});
}
}
});
}
The logic is if authenticated user from first authentication step doesn’t have role ‘admin’ user will be redirected to location ‘http://www.example.com/error' with ‘errorcode’ and ‘errorMsg’ attribute. My intention of this blog post is provide some basic idea of Adaptive Authentication support in up coming WSO2 Identity Server release. I will discuss more complex use cases with Adaptive Authentication in future.
References
[1] https://developer.mobileconnect.io/level-of-assurance
[2] https://medium.com/@WSO2/wso2-identity-server-the-inside-story-e842b363e6b9
[3] https://docs.wso2.com/display/IS570/Adaptive+Authentication
[4] https://docs.wso2.com/display/IS570/Adaptive+Authentication+JS+API+Reference
