Configuring Risk-Based Adaptive Authentication

WSO2 Identity Server Analytics is a lightweight, lean, streaming SQL-based stream processing platform that allows you to collect events, analyze them in real-time, identify patterns, map their impacts, and communicate the results within milliseconds. It is powered by Siddhi to be extremely high performing.

This tutorial demonstrates using WSO2 Identity Server Analytics to publish transactional data and assess an end user's risk score based on the user's transaction history in an adaptive authentication scenario. Consider a business use case where a bank wants to prompt an additional authentication step when a user attempts to log in to the system after doing a transaction of over $10,000. This usecase can be achieved by creating a Siddhi application in WSO2 Identity Server Analytics and configuring a conditional authentication script in the service provider configured in WSO2 Identity Server.

Follow the instructions given in the sections below to set this up.

Risk profiling flow

The diagram below shows how the connection between the client application, WSO2 Identity Server Analytics, and WSO2 Identity Server works to assess risk and provide adaptive authentication to users.

The user performs bank transactions through different applications.
Transactional data from all these applications are published to WSO2 Identity Server Analytics.
The user attempts to access a service provider application that uses WSO2 Identity Server as the identity provider.
The service provider sends an authentication request to WSO2 Identity Server.
The user is prompted to sign in and WSO2 Identity Server authenticates the user using basic authentication (username and password).
WSO2 Identity Server publishes an event to the Siddhi application in WSO2 Identity Server Analytics to compute the user's risk score based on the user's transaction data received in step 2. If the user has made transactions that sums up to over $10,000 within the last five minutes, the risk score is 1. Else, the risk score is 0.
If the risk score is 1, WSO2 Identity Server prompts the additional user authentication step, which requires entering a hardware key number, before allowing the user to access the service provider application.

Let's learn how to configure risk-baesd adaptive authentication:

Configuring WSO2 Identity Server Analytics

Follow the steps below to create a Siddhi application that has two endpoints, one to publish transactional data and the other to recieve the user's risk score.

Download the latest version of WSO2 Identity Server Analytics.

Create and deploy the following Siddhi application on a WSO2 Identity Server Analytics worker node. For instructions, see Using WSO2 Identity Server Analytics for Adaptive Authentication.

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

@Source(type = 'http-request', source.id='testsource', basic.auth.enabled='true', parameters="'ciphers:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256', 'sslEnabledProtocols:TLSv1.1,TLSv1.2'", receiver.url="https://localhost:8280/RiskBasedLogin/InputStream", @map(type='json', @attributes(messageId='trp:messageId',username='$.event.username')))
define stream InputStream (messageId string, username string);

@sink(type='http-response', source.id='testsource', message.id='{{messageId}}', @map(type='json'))
define stream OutputStream (messageId string, username string, riskScore int);

define stream TempStream (messageId string, username string, sumTransactions double);

@Source(type = 'http', receiver.url="http://localhost:8281/RiskBasedLogin/TransactionInputStream", basic.auth.enabled='false', @map(type='json', @attributes(username='$.event.username', transaction='$.event.transaction')))
define stream TransactionInputStream (transaction double, username string);

from TransactionInputStream#window.time(5 min)
right outer join InputStream#window.length(1) unidirectional 
on TransactionInputStream.username == InputStream.username
select InputStream.messageId, InputStream.username, sum(transaction) as sumTransactions
group by messageId, InputStream.username
insert into TempStream;

from TempStream
select messageId, username, ifThenElse(sumTransactions > 10000, 1, 0) as riskScore
insert into OutputStream;

Configuring WSO2 Identity Server

Follow the steps below to configure WSO2 Identity Server to communicate with the Siddhi application.

Before you begin

Set up the service provider and sample application for adaptive authentication. For instructions, see Configuring a Service Provider for Adaptive Authentication.
For more information about adaptive authentication with WSO2 Identity Server, see Adaptive Authentication.

Sign in to the WSO2 Identity Server Management Console.
Create a user named Alex with the login privileges. For instructions on creating a user, see Configuring Users.
On the Main tab, click Identity > Service Providers > List.
Click Edit on the saml2-web-app-dispatch.com service provider.
Under the Inbound Authentication Configuration section, click Local and Outbound Configuration > Advanced Authentication.
Click on Templates on the right side of the Script Based Conditional Authentication field and then click Risk-Based.
Click Ok. The authentication script and authentication steps are configured. The authentication script defines a conditional step that executes the second step of authentication (the hardware key authenticator) if the riskScore is greater than 0.
The second authentication step that is added is totp. However, totp is an authentication step that you would normally use in production. To try out this scenario sample authenticators with the sample application, delete the totp authenticator and add the following sample authenticator instead.
1. Click Delete to remove the totp authenticator from Step 2 (the second authentication step).
2. Select Sample Hardware Key Authenticator and click Add.
Save the service provider configurations.
Restart WSO2 Identity Server.

Trying it out

Start the Tomcat server and access the following sample PickUp application URL: http://localhost.com:8080/saml2-web-app-dispatch.com.

Port offset the 9443 port in WSO2 Identity Server Analytics. This is required because WSO2 IS also runs on the 9443 port.

Open the deployment.yaml file found in the <SP_HOME>/conf/worker/ folder.

Change the Port: 9443 to 9444 under listenerConfigurations.

  listenerConfigurations:
    -
      id: "default"
      host: "0.0.0.0"
      port: 9090
    -
      id: "msf4j-https"
      host: "0.0.0.0"
      port: 9444
      scheme: https
      keyStoreFile: "${carbon.home}/resources/security/wso2carbon.jks"
      keyStorePassword: wso2carbon
      certPass: wso2carbon

Start the WSO2 Identity Server Analytics server in a Worker profile.
- For Windows: worker.bat
- For Linux: ./worker.sh
Log in by giving username and password credentials. You are logged in to the application.

Note that the user is authenticated with basic authentication only.
Log out of the application.

Execute the following cURL command. This command publishes an event about a user bank transaction exceeding $10,000.

Tip: Replace the <username> tag in the cURL command given below with a valid username and ensure that the WSO2 Identity Server Analytics Worker profile is running.

curl -v -X POST   http://localhost:8281/RiskBasedLogin/TransactionInputStream   -H 'Accept: application/json'   -H 'Cache-Control: no-cache'   -H 'Content-Type: application/json'   -H 'Postman-Token: 7847a682-012d-4939-88f5-6e8ec781c144'   -d '{    "event": {
        "username": "chris",
        "transaction": 12000
    }
}' -v

Log in to the sample PickUp application. You are prompted with the hardware key authentication after the basic authentication step.

Before executing the cURL command given in step 4, the user had no transaction history and the user's riskScore was 0. The authentication script is programmed to prompt only basic authentication if the risk score is 0.
After executing the command, a transaction event that indicates the user spending more than $10,000 is published and recorded in the Siddhi application. Therefore, when the user now attempts to log in again, the user's riskScore is evaluated to 1 and the user is prompted for an extra step of authentication.
Re-enter the number given on the screen and click Sign In. You are logged into the application.

What's Next?

The following scenarios demonstrate the use of adaptive authentication templates and scripts to try out different usecases.