Cumulative Risk-Based Adaptive Authentication
Adaptive authentication is one of the key features in the WSO2 Identity Server. This blog will direct you to how you can use the adaptive authentication script in WSO2 IS in a more efficient and effective manner to authenticate the users by examining the user's risk profile. First of all, you can get an idea about adaptive authentication by reading the following blogs;
- Adaptive Authentication for Five Year-olds by Chamath
- Adaptive Authentication: Why? What? How? by Anuradha Karunarathna
- Become an expert on Adaptive Authentication with Identity Server in 10 minutes by Ruwan Abeykoon
Before move into seeing the true beauty of adaptive authentication in WSO2 IS, I request you to try out the adaptive authentication scenarios. For that WSO2 IS documentation will help you. And most importantly don’t miss trying out the scenarios of New-Device-Based, Login-Attempt-Based, and Risk-based as those scenarios help you to understand what I’m going to tell in this blog. If you a lazy person to try out those scenarios but still interested in knowing what I’m going to explore here; just keep reading and try out the scenario explained below.
Cumulative Risk-Based Adaptive Authentication
In adaptive authentication, you can think of any possible scenario which will examine the user’s risk profile and do the authentication accordingly. Here I’m going to combine the new-device based adaptive authentication scenario and the login attempt based adaptive authentication to examine the users' risk profile. For that, I use the analytics engine to calculate the user’s login risk.
Scenario: This scenario demonstrates adaptive authentication based on login from a new device and failed login attempts before success within a defined time window in WSO2 Identity Server.
- If the user uses a new device or a new browser to log in to the application, that information was sent to the analytics engine to calculate the cumulative risk.
- The new device or browser is identified by a cookie, therefore, once the cookie expires (this expiry time is specified in the authentication script), the same browser or device is considered as a new device.
- Then the login-attempts-based adaptive authentication was considered where the configured number of failed login attempts before success cause to perform an additional level of authentication to access a resource.
- This is useful when you want to add security for users who successfully log in after a specific number of failed login attempts.
- Those user login details of username, tenant domain, number of failed login attempts before success, and boolean value on new-device-based login, were sent to the analytics engine to calculate the risk.
- Then in the output stream, the analytics engine sent the risk of the particular user within the given time window.
- Based on that risk, you can define authentication steps accordingly.
Sample Scenario
Let’s say you have configured email OTP as the second step and FIDO as the third step (refer above-mentioned WSO2 IS docs to know more about configuring authentication steps).
Don’t get confused with the mentioned risk scores in here. I’ll explain it later with siddhi's application.
- A user called Alex tries to log in to the desired application with a new device and after successfully attempt for basic authentication, he will be prompted the second authentication step as the is a minor risk since the user tries to log in from that device for the first time. (At that time users risk score is 2)
- After that within 30 minutes time window, user has two failed login attempts and then he was successful with the basic authentication. As at that time, users' risk is 4 and prompt the 3rd authentication step as this user has considerable risk of login.
- Let’s say within the same 30 minutes time window Alex try to login from another new device and he failed two login attempts, he will be prompted with an error page mentioning his login was suspicious and his account was suspended for 30mins.
Refer to the below adaptive authentication script and try to understand how I’ve implemented the above-explained scenario. You may feel that you can use this script to implement adaptive authentication at it’s best.
Siddhi Application Logic
WSO2 IS publishes an event to the siddhi application in IS-Analytics by calling the “callAnalytics” method. Then Siddhi app receives the user login details as event properties by the defined input stream.
Within 30mins time period it calculates the risk score of the particular user. For the above-mentioned scenario, if the user logged in with a new device, it increases risk by 2, and for each failed login attempt before success increases risk by 1.
For 30 minutes time windows, the siddhi app calculates the cumulative risk score of the particular user and sends that risk value to WSO2 IS with the output stream. I will explain how to build siddhi application using IS-Analytics in a seperate log. Keep in touch!!
Congratulations!!! Now you know how the adaptive authentication script and analytics engine can be used to implement a more realistic adaptive authentication scenario. The above-explained scenario is just one scenario to demonstrate how powerful the WSO2 adaptive authentication script is. Therefore you can also try out different adaptive authentication scenarios with the authentication script and the analytics engine.
Now it’s your turn…. Play with different scenarios you can think and see how easy to achieve it using WSO2 IS adaptive authentication script and the WSO2 IS analytics.