WSO2 IS Analytics for Risk based Adaptive Authentication

As I promised in my Cumulative Risk-Based Adaptive Authentication blog, here I will explain the role of the WSO2 IS Analytics when implementing a Risk based adaptive authentication usease. Through this blog, I hope to give you a deeper understanding of the capabilities that WSO2 IS Analytics provides you to support risk-based adaptive authentication.

If you have read my previous blogs, now you already know that adaptive authentication is a method for selecting the right authentication factors depending on a user’s risk profile and tendencies for adapting the type of authentication to the situation. So, I’m going to explore how adaptive authentication can be used in WSO2 identity Server to select the right authentication factors depending on a user’s risk profile and how we can build the user’s risk profile using WSO2 IS Analytics. Keep reading!!!

About WSO2 IS Analytics…

The WSO2 Identity Server Analytics(WSO2 IS-Analytics) is a streaming SQL-based complex event processing platform powered by Siddhi to be extremely high performing that can be used to monitor authentication related analytics for residence and federated authentication scenarios of WSO2 Identity Server with a rich set of streaming data processing capabilities to support;

• Collect events, analyze them in real-time, identify patterns, map their impacts, and communicate the results within milliseconds
• Static and dynamic machine learning based decision making
• Calculating aggregations over windows such as time, length, and session
• Static rule processing
• And, many more…

Maintain a Risk Profile using WSO2 IS-Analytics

As shown in the following diagram, when a user initiates the login request, the service provider(application) sends an authentication request to WSO2 Identity Server. Then WSO2 IS sends an HTTP request to WSO2 IS Analytics to compute the user’s risk score based on the user’s login details. The WSO2 IS, takes the decision based on the received risk analysis statistics, adaptive authentication script can be used to define dynamic authentication sequences that can perform actions similar to the following:

• Control the authentication step selection
• Change user attributes
• Send email notifications
• Redirect users to an error page etc.
• Directly give access to the application

Let’s see how this happens

Hope you have read my previous blog on Cumulative Risk-Based Adaptive Authentication. In that blog I have explained how to examine the users’ risk profile by evaluating the new-device based adaptive authentication scenario and the login attempt based adaptive authentication.

Recap:

• 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 user login details (username, tenant domain, number of failed login attempts before success, and boolean value on new-device-based login) were sent to the IS-Analytics to calculate the cumulative 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 in the adaptive authentication script.

As I promised in that blog here I’m going to explain the Siddhi application logic to demonstrate the role of the WSO2 IS-Analytics in risk based adaptive authentication. Before start, I request you to quickly go through the adaptive authentication script in that blog. So referring to that let’s build the Siddhi application step by step. Buckle up!!!

Creating a Siddhi application

1. Download the latest version of WSO2 IS Analytics.
2. Extract the downloaded zip and navigate to the <ISANALYTICS_HOME>/bin directory and issue one of the following commands to start the WSO2 IS Analytics Editor.

• For Windows: editor.bat
• For Linux: ./ editor.sh

3. Access the WSO2 IS Analytics Editor through the following URL: http://\<HOST_NAME>:\<EDITOR_PORT>/editor. (Default URL is: http://localhost:9390/editor)

4. Click New to start creating a new Siddhi application.

Step 01

In the siddhi application, first we need to add the Siddhi app name and the description as follows. In this scenario, let’s name the application as IS_ANALYTICS_RISK_BASED_LOGIN . (For the siddhi application name “IS_ANALYTICS_” prefix should be added)

@App:name("IS_ANALYTICS_RISK_BASED_LOGIN")                       @App:description("Description of the plan")

Since we use the in-built “callAnalytics” method in the adaptive authentication script to send the input stream to IS-Analytics, you should add the call analytics method as follows in the adaptive authentication script according to the above explained usecase.

callAnalytics(
    {'Application':'IS_ANALYTICS_RISK_BASED_LOGIN',
     'InputStream':'InputStream'}, 
    {'username':username, 
     'userTenantDomain':userTenantDomain,      
     'newDeviceAttempt':newDeviceAttempt,
     'failedLoginAttemptsbeforeSuccess':
           failedLoginAttemptsbeforeSuccess}, 
    { // Callback event handlers.})

According to the Adaptive Authentication JS API Reference “callAnalytics” method includes the following parameters.

callAnalytics(metadata, payloadData, eventHandlers )

• metadata: A JSON object that contain the following attributes:

Application: Siddhi application name (mandatory).

As explained above, in this example we use “IS_ANALYTICS_RISK_BASED_LOGIN” as the application name

InputStream: Input stream name (mandatory)

In a Siddhi application, there should be a stream defined with an HTTP source with the same name we define here. In this example, we use input stream name is ‘InputStream’)

• payloadData: The data that needs to be sent to the analytics engine.

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.

• eventHandlers The callback event handlers.

Step 02

After we send the payload to IS-Analytics, it will capture as an input stream in the Siddhi application as follows. Here we need to add the source with type, source id and the receiver URL. The attribute map type should be JSON and the the values received from IS, will be mapped to the attributes in the Input stream to define the input stream.

After processing the input stream through several streams, finally we define the HTTP-response sink with the OutputStream to send the processed and examined final analytics data to the WSO2 IS to capture it through adaptive authentication script. Here we send the messageID, username and the riskscore to WSO2 IS and thereafter based on that risk analysis statistics (riskscore), you can define dynamic authentication sequences.

In the above the HTTP-request source and HTTP-response sink code blocks, source id and messageId are referred to the following.

• source.id in the source stream and the sink stream is used to bridge one input stream to one output stream, and should be matching and unique in pair.
• messageId The attribute must be of type string and the value should be selected from trp:messageId.Maintain the messageId attribute throughout the whole flow. The messageId attribute should also be available in the sink stream. The HTTP-response type sink should have the option message.id and the value should be the above mentioned messageId.

Step 03

From the input stream, username, user tenant domain and login time, calculated risk score and the failed login attempts before success count will be inserted to another stream called riskStream. Here, login time will get from the in-build function of eventTimeStamp() function. Risk score will set to 2 if if the login is from a new device by checking the newdeviceattempt boolean value. If the login is not from a new device risk score will be 0.

Then data from the riskStream will insert into secondRiskStream while getting the cumulative risk score for that particular login. Here, it will calculate the risk score by adding the failed login attempt before success count to the received risk score from the riskStream. We get the second RiskStream to store the login details along with the risk value in the database table. This will be discussed in Step 04.

Step 04

Here we define a table as follows to store the user login details. You should give the datasource as ‘IS_ANALYTICS_DB’. In the very beginning it will create an event table named ‘USER_RISK_PROFILE’ in the database if it does not already exist with four attributes named ‘username’, ‘userTenantDomain’, ‘logintime’ and ‘riskscore’).

As explained in step 03, from the riskStream it will calculate the risk score for the particular login and pass it the secondRiskStream. Then the data from that stream will be inserted to the USER_RISK_PROFILE database table as follows.

Step 05

Here we insert input stream data to IntermediateStream, just to get the starting time of the 30 minute time interval from the current login time. Then we join the IntermediateStream with the USER_RISK_PROFILE table to calculate the summation of the riskScore of the particular user within the 30 minutes time interval. That value will be passed to the Output Stream that we defined in the Step01 to be passed to the IS.

We are done!!! The final Siddhi application is as follows.

Testing the Siddhi application

1. Run the Siddhi application from the Editor.
2. Execute the following cURL command on a terminal window to calculate the user’s risk score.

Request to get the risk score

curl -kv -X POST http://analytics.wso2isdemo.com:8080/IS_ANALYTICS_RISK_BASED_LOGIN/InputStream -H ‘Accept: application/json’ -H ‘Content-Type: application/json’ -d ‘{
 “event”: {
 “username”: “daniel@facilelogin.com”,
 “userTenantDomain”: “carbon.super”, 
 “failedloginattemptsbeforesuccess”: 0, 
 “newDevice”: false, 
 “mitigateRiskForTrustedDevice”: false
 }
}’

You will receive a response similar to the response given below.

{“event”:{“messageId”:”e7b4cac1–162b-4686–8d59–9cebbf58cd5c”,”username”:”daniel@facilelogin.com”,”riskScore”:4.0}}

Deploying the Siddhi application

You have successfully created the Siddhi application and tested the functionality using the Editor. The Editor is useful for testing purposes however, you must deploy the application properly in WSO2 IS Analytics to use it in production. Follow these instructions to deploy the application.

1. On the Editor, click File>Export File.
2. A file named IS_ANALYTICS_RiskBasedLogin.siddhi is downloaded onto your machine. Place it in the <ISANALYTICS_HOME>/deployment/siddhi-files directory.
3. Stop the Editor and start WSO2 Stream Processor in a Worker profile.

• For Windows: worker.bat
• For Linux: ./ worker.sh

Hooray!!!! You have successfully deployed Siddhi application. Now you can test the scenario explained in Cumulative Risk-Based Adaptive Authentication blog, and authenticate the user based on his/her risk profile with the support of the WSO2 IS Analytics.

High Five!!! Now you know how to write a Siddhi application in WSO2 IS Analytics to support a more realistic risk based adaptive authentication use case. So you can think of a better way to secure the application considering your application user’s behaviours implement a risk based adaptive authentication using WSO2 IS adaptive authentication script and the WSO2 IS analytics.