HID Risk Management Solution (RMS) Web Component - Login Flow

Note: This section provides necessary server settings, component settings and other services settings to integrate the HID RMS Web component. Additionally, the detailed description of the Login Flow is provided in this section which would be available as part of User Authentication component after the successful integration.

HID® Risk Management Solution (RMS) is a real-time risk profiling technology that protects financial institutions against cybercriminals, protecting customer data and defending against fraud, malware, and data breaches.

It is a next-generation cyber threat and fraud detection solution, based on data analytics, that protects against traditional as well as modern threats targeting online and mobile banking, transaction systems, and sensitive applications.

Temenos Infinity platform customers can easily integrate the HID® Risk Management Solution to enable adaptive and risk-based authentication.

Prerequisites:

  • A dedicated channel has to be created for the partner.

  • Reverse Proxy has to be configured in Kony Fabric Console to generate the RMS Script Tag. This proxy settings allow your application to connect with RMS system.

    Add RMS script tag "<script src = < BASE_URL /services/HIDRMS/getJS> ></script>" under Project → Settings → Responsive Web → HTML Head

    Note: If you have your own reverse proxy configured then you can ignore below RMS script tag configuration.

  • Server configuration properties on fabric should be configured with RMS channel_id and application_id (Refer to Server Settings).

  • All the mandatory Server and component Settings has to be configured.

Configurations:

Mandatory Server Settings

APPLICATION_ID

 <Unique application name given by RMS>

CHANNEL_ID

 <Unique identifier to access the application by RMS.>

ENVIRONMENT_ID

<Identification of the environment the application is running E.g. prod, test>
IS_CUSTOM_RMS_SCORE_RANGE

<Custom RMS score range >

RMS generates the score in the range of 0 - 1000 and then we set our custom range raging from 0 - 10 .

Custom Range Risk Score Use Case
0-99 0 Step - Down
100 - 199 1 Step - Down
200 - 299 2 Step - Down
300 - 399 3 Step - Down
400 - 499 4 Step - Down
500 - 599 5 Step - Up
600 - 699 6 Step - Up
700 - 799 7 Step - Up
800 - 899 8 Step - Up
900 - 999 9 Step - Up
1000 10 Step - Up
Note: If the custom RMS score range is not defined, system will consider default defined custom range.

Note: Login Component is the main component which includes all component setting for RMS web component.
Mandatory Component Settings

isRMSEnabled

 <ON/OFF options to enable or disable the RMS. ON means RMS is enabled; OFF means RMS is disabled>

tmCookieTag

<cookie value associated with the RMS>, mandatory field

This identifier is issued by RMS .Each new device used by the user to access the protected application will be tagged by RMS. This attribute is mandatory and should be always sent.

tmCookieSid

<cookie value associated with the RMS>, mandatory field

This identifier is issued by RMS and serves as a unique identification of a user's session. Its value is persistent throughout the whole session and is stored as a cookie pair.
adaptiveAuth

<We can define the range of Adaptive Auth range from 0 - 10> (Its an optional field, If not configured, the configured MFA will be called for medium risks).

We can define the Risk Score for performing STEP-UP and STEP-DOWN based on the RMS score and alert.
isRMSReadOnly

<ON/OFF options to enable RMS in Read-Only Mode. ON means RMS is in ReadOnly mode; OFF means RMS is enabled. The default value is always OFF > .

If this field is ON → RMS will just record the users behavior but it wont perform any STEP-DOWN operations, All operations would be always STEP-UP.

RMS Login Component Public Function:

Functions Descriptions

getRMSSessionId

This function generate the sessionId for the particular session which is being used across whole flow.

Parameters: → NA

Return Types: → app_session_id (String)

logoutOnClick

This function terminate the sessionid when being called.

Parameters : → username, sessionId (optional)

Return Type : → NA

Login Flow

This describes how an adaptive and risk-based authentication works during the Login process.

Sequential Diagram

Flow Chart Diagram

Risk-based Authentication Functional Flow

  1. When user visits the application’s Login page, the configured JS script will be loaded to connect with the RMS system.

  2. Once the RMS server responses, it checks whether the component property isRMSEnabled is ON. Enabling this property will make the RMS Web Component ready.

  3. Now user provides their Username and Password, then clicks Submit.

  4. After successfully validating the user’s credentials, the RMS Login API sends request to RMS server to check the risk score.

  5. There are rules defined in the rule engine that uses risk score and generates a tag i.e., STEP-UP, STEP-DOWN, or USER BLOCK.

    Login Component use these tags below to act upon for login.

    • Medium-High Risk: Tag STEP-UP triggers Multi Factor Authentication

    • Low Risk: Tag STEP-DOWN triggers One Factor Authentication

    • User Block: It refers to it won’t allow the user to login to App.

    Note: RMS has configured rule engine in its backend, which has configured signal like (New IP address, New Country, and New Device Check) and alerts the application with tags (STEP-UP) whenever it detects changes in these signal and increases the risk score as well.

Risk based STEP-DOWN

During the Login process, If RMS captures that Risk score is low with tag STEP-DOWN, MFA won’t be triggered as 2nd Factor and user will be redirected to Dashboard.

Risk based STEP-UP

During the Login process, If RMS captures that Risk score is High, it triggers Multi-Factor Authentication (MFA) with tag STEP-UP, where MFA is Approve, SMS OTP or Email OTP that is configurable at component level i.e adaptiveAuth.

  • If the user has more than one Approve Push device registered, it will display the list of devices. If the user has only one Approve device registered, the user will receive a push notification on it directly.

  • On selecting the device, the user will receive a push notification on the selected device. User can also select an option to authenticate using Approve secure code.

  • After Approving the push notification, user will be directed to the next screen to show that user has been logged in successfully and a button to Logout.

  1. User receives an OTP either by SMS or by email based on the MFA selected.

  2. On the next screen, the user enters the received OTP and clicks Confirm to complete the authentication.

  3. After validating the OTP successfully, the user is directed to the next screen confirming that they have been successfully authenticated and can log out if required.

Note:

The property determines the authentication factor to be used for authentication. The component supports the following factors:

Keyword Purpose

OTP_SMS

OTP via OOB SMS

OTP_EML

OTP via OOB Email

APPROVE

Push based Authentication using HID Approve

OTP_HWT

OTP via Hardware Token
Note:

  • Types of Authentication is decided based on risk scores. You can configure the score in component Properties "adaptiveAuth".

  • RMS Score for Adaptive Authentication:

    {
"customAdaptiveAuth": [
{
"authType": "OTP_SMS",
"lowerLimit": "5",
"upperLimit": "8"
},
{
"authType": "APPROVE",
"lowerLimit": "8",
"upperLimit": "10"
}
],
"default": "APPROVE"
}

Risk based USER BLOCK

During the Login process, If RMS captures that Risk score is high for any anomalous signal, it Blocks the User from Login to application.

Note: All the above three tags (STEP-UP, STEP-DOWN, and USER-BLOCK) are configurable in Rule engine.

Object Services

Object Services is a feature of Quantum Fabric that enables model-driven application design and development by following a microservices architectural approach to create reusable components and link them to fit into your solution. Using Object Services, you can define your preferred data model, which defines how your application wants to interact with its data. There is a clear separation between the data model and how it maps to the back-end systems of record.

ServiceName DataModel Mapping Purpose Input Parameters Invoking

HIDRMSService

RMSActionComplete

rmsActionReject

Mark already submitted action as unsuccessfully completed

tm_action_id

RMSThreatMarkAPI (1.0).actionReject
 

rmsActionComplete

Mark already submitted action as successfully completed

tm_action_id

RMSThreatMarkAPI (1.0).actionComplete

HIDRMSService

RMSActionCreate

rmsActionCreate

Create and score action defined only by it's type and properties

action_type,app_session_id,app_user_id, client_ip,tm_action_id, tm_device_tag, tm_session_sid

RMSThreatMarkAPI (1.0).actionCreate

HIDRMSService

RMSActionSign

rmsActionSign

This API call will Sign the action

app_sesson_id,app_user_id,security_item_type, client_ip,tm_action_id, tm_session_sid

RMSThreatMarkAPI (1.0).actionSign
HIDRMSService RMSSessionService sessionLogout Notifying the RMS about log out of the user session username, session RMSThreatMarkAPI (1.0).sessionLogout

Integration Services

An Integration Service is an application component that represents the application interaction with an external system or data source. A service definition comprises the meta-data or the configurations required to exchange data with the external system or data source.

Name Operation Names Services Type Description

HIDRMS

getJS

Integration

This API call has to be added in <head>tag which will load the JS Script in our web Application.

 

probeRequest

Integration

 
RMSThreatMarkAPI sessionCreate Integration This method is called, every time a user is logging into the protected application using one of their authentication factors, like credentials or OTP.
RMSThreatMarkAPI sessionLogin Integration The "login" method has to be called after the last successful "create_login_step" using the last login step "tm_action_id" or "app_action_id" to let the system know that the customer has successfully logged in.
RMSThreatMarkAPI actionCreate Integration create and score the defined action
RMSThreatMarkAPI actionReject Integration Mark already submitted action as unsuccessfully completed

RMSThreatMarkAPI

actionSign

Integration

Add signature and sign that particular action (for eg. device Update, device rename, Active/suspend device).

RMSThreatMarkAPI

actionComplete

Integration

Mark already submitted action as successfully completed. This method can be called after-action/create or after an arbitrary number of added signatures via action/sign Either tm_action_id or app_action_id has to be provided.

Authentication Pre/Post Processors

A preprocessor is a component that is invoked before passing the data to the external data source.

A postprocessor is a component invoked after the data is received from the external data source.

Name Description Used by (ServiceName-Operation)

RMSBasePreprocessor

This Preprocessor gets the RMS-related properties (like application_id, channel_id, etc) from KONY server properties and passes these values to call a specific API. The Processors use by multiple Integration services as mentioned.

RMSThreatMarkAPI-actionCreate,RMSThreatMarkAPI-actionComplete, RMSThreatMarkAPI-actionReject,RMSThreatMarkAPI-actionSign

RMSBasePostprocessor

After the successful call of action create service, this Processor will do the score re-Mapping.

RMSThreatMarkAPI-actionCreate