Managing the HID Risk Management Solution

The HID Risk Management Solution (RMS) is a fraud and threat detection solution, designed with a modern fraud schemes and attack types in mind. It is based on device fingerprinting and transparent user identification technologies. It uses advanced techniques to establish a unique device fingerprint based on the device location, browser, and system hardware details.

The HID RMS uses obfuscated JavaScript code that is embedded within the relying-party's web application to retrieve information about the end user's system, to establish a device fingerprint, study the way users interact with the application, analyze and then, finally, produce a risk score.

This information is given a unique ID so when the relying-party’s application calls the HID Authentication Service, it can retrieve a risk score associated with the authentication attempt.

The HID Authentication Service compares this risk score with the pre-configured threshold values to decide how to process the authentication:

• Reject and block the channel for the end user (very high risk)

• Only reject (high risk)

• Ask for a step-up authentication (medium risk)

• Authorize the request (low risk)

This feature is activated on the HID Authentication Service by adding and configuring an RMS source to an authentication channel (CH_RMS). This ensures that authentications on the designated channel require a RMS Risk Score index retrieval.

RMS JavaScript Snippet

The RMS JavaScript Snippet is a core component ensuring detection of cyber threats and monitoring of users’ activity in the application. This component is to be placed in HTML code (in header of all pages) of the protected applications. The JavaScript snippet is continuously re-obfuscated to ensure that attackers cannot easily reverse engineer the solution.

RMS Server

The HID RMS server is the central point of analysis for the data gathered by the respective JavaScript probes as well as providing a graphical web dashboard for fraud analysts to analyze detection cases.

Risk Score Provider Configuration

The HID RMS source or Risk Score Provider is a configuration details about the threat detection provider to retrieve the risk score details by the HID Authentication Service.

For further information about configuring RMS source endpoints, see the Risk Score Provider REST API.

Solution Workflow

The following diagram illustrates the flow of authentication requests and responses, when an end user authenticates to relying party applications such as banking application, leveraging the HID RMS integration.

The green flow illustrates the step-up authentication using the HID Authentication Service and HID Approve.

1. The end user submits a logon request to the banking application (relying party).

2. The banking application web page requests a user data probe using the HID RMS JavaScript.

3. HID RMS provides the JavaScript and cookies required for the probe on the user’s device.

4. The HID RMS probe retrieves the user data and returns it to the HID RMS for realtime analysis.

5. The banking application retrieves the HID RMS cookie from the user’s browser.

6. The banking application sends an authentication request, including the HID RMS cookie ID, to the HID Authentication Service.

7. The HID Authentication Service sends the cookie ID to the HID RMS to retrieve the risk score.

8. The HID RMS returns the risk score.

9. The HID Authentication Servicee analyses the risk score based on the configured thresholds:

   • If the score is lower than the thresholds, the HID Authentication Service authorizes the authentication request.

   • If the score is higher than one of the thresholds, the HID Authentication Service either:

     • Rejects the request (only)

     • Rejects the request and blocks the channel for the end user

     • Asks for a step-up authentication (for example, push-based validation)

10. The HID Authentication Service sends the response to the banking application.

11. If the request is authorized, the authenticated user can access the appropriate resources in the banking application.

    

    Important: A common proxy MUST be used to redirect the different exchanges according to the different URL endpoints.

Integrate with HID RMS

Error Codes and Messages

The error code is provided in the JSON:

{
    "hid_failure":    
    {
        "reason": 51,
        "context":       {
            "TM_AUTHENTICATION_TYPE_LIST": "AT_PASA",
            "TM_ACTION_ID": "4481",
            "LEVEL_OF_ASSURANCE": "1",
            "RMS_DETAILS": "eyJhbGciOiJub25lIn0.eyJzZXNzaW9uIjpic3RhbmRhbG9uZV9zawiZGV0ZWN0aW9ucyI6W119LCJ0YWdzIjpbXX0.",
            "TM_SESSION_TRANSFER": "BjA4Tl2OxjEj7vKMxgQqgLanBs"
        },
        "authType": "AT_STDPWD"
    },
    "error_description": "Invalid grant: Step-up authentication required",
    "error": "invalid_grant"
}

HID RMS OpenID Calls

This section provides detailed examples of OpenID requests for the HID RMS.

When integrating with ThreatMark™ as a RMS provider, the content of the JWT are JSONs containing the following items:

{
            "session":{
                        "score":688,
                        "standalone_signals":[
                                    {"id":4426,"type":"PHISHING_PROBE_LOAD"},
                                    {"id":4427,"type":"NEW_USER_DEVICE"},
                                    {"id":4430,"type":"NEW_USER_LANGUAGE"}
                        ],
                        "detections":[]
            },
            "action":{
                        "score":0,
                        "standalone_signals":[],
                        "detections":[]
            },
            "risk":897,
            "device":{
                        "score":99,
                        "standalone_signals":[
                                    {"id":4429,"type":"UNKNOWN_WEBINJECT"},
                                    {"id":4437,"type":"UNKNOWN_WEBINJECT"},
                                    {"id":4450,"type":"UNKNOWN_WEBINJECT"}
                        ],
                        "detections":[]
            },
            "user":{
                        "score":110,
                        "standalone_signals":[],
                        "detections":[]
            },
            "tags":[]
}

Static Password Authentication (No Step-up Authentication)

POST https://myserver/idp/ONLINEBANK/authn/token
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer RTp7HwAAAWd49XAymijxrvKMwWLZ5fZ6S1VF

grant_type=password&username=testp1&password=activcard2018&context=RMSINFO:eyJhbGciOiJub25lIn0.eyJUTV9TRVNTSU9OX1NJRCI6InJZRm
NtNjVwa2hvYXdHUkZnTjFVUk5YWUhsM1FBcGxIIiwiVE1fQ0xJRU5UX0lQIjoiMTAuMTYuNzEuNzkiLCJUTV9ERVZJQ0VfVEFHIjoiME9lbk5xQWRsUTNhcG9WZkhoZHJibmdhdlg0VWozUFQifQ.:false

HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8
{
    "access_token":"TXvBKAAAAWd5AGiHxQ\/X8RV\/IIrAug4yr9Jhuzqu",
    "context":{
        "TM_ACTION_ID":"4454",
        "LEVEL_OF_ASSURANCE":"1",
        "RMS_DETAILS":"eyJhbGciOiJub25lIn0.e…",
        "token_type":"Bearer",
        "expires_in":3600
    }
}

Static Password Authentication with an OTP Step-up

The step up will happen if the risk score returned by the first authentication exceeds the configured threshold.

In that case, the HID Authentication Service will return an error when performing the password authentication, and will force the client to use a second authentication policy.

First step is the same as before - a simple password authentication

POST https://myserver/idp/ONLINEBANK/authn/token
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer RTp7HwAAAWd49XAymijxrvKMwWLZ5fZ6S1VF

grant_type=password&username=testp1&password=activcard2018&context=RMSINFO:eyJhbGciOiJub25lIn0.eyJUTV9TRVNTSU9OX1NJRCI6InJZRm
NtNjVwa2hvYXdHUkZnTjFVUk5YWUhsM1FBcGxIIiwiVE1fQ0xJRU5UX0lQIjoiMTAuMTYuNzEuNzkiLCJUTV9ERVZJQ0VfVEFHIjoiME9lbk5xQWRsUTNhcG9WZkhoZHJibmdhdlg0VWozUFQifQ.:false

HTTP/1.1 400 Bad Request
{
    "hid_failure":{
        "reason":51,
        "context":{
            "TM_AUTHENTICATION_TYPE_LIST":"AT_EMPOTP,AT_PASA",
            "TM_ACTION_ID":"4464",
            "LEVEL_OF_ASSURANCE":"1",
            "RMS_DETAILS":"eyJhbGciOiJub25lIn0.e…",
            "TM_SESSION_TRANSFER":"hb4dGrRnmXN7xC9pVBH6e6XOCggneOLhDwRYagsA"
        },
        "authType":"AT_CUSTPW"
    },
    "error_description":"Invalid grant: Step-up authentication required",
    "error":"invalid_grant"
}

The second step is to select one of the authentication policies configured as the second factor. In the example, we will be using "AT_EMPOTP" (OTP authentication using the HID Approve app).

The "TM_SESSION_TRANSFER" value from the step 1 response should be part of the RMSINFO base64-encoded JSON value.

POST https://myserver/idp/ONLINEBANK/authn/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer RTp7HwAAAWd49XAymijxrvKMwWLZ5fZ6S1VF6gyf
grant_type=password&username=testp1&password=662122&authType=AT_EMPOTP&mode=SYNCHRONOUS&context=RMSINFO:eyJhbGciOiJub25lIn0.eyJUTV9TRVNTSU9OX1NJRCI6InJZRmNtNjVwa2hvYXdHUkZnTjFVUk5YWUhsM1FBcGxIIiwiVE1fQ0xJR
U5UX0lQIjoiMTAuMTYuNzEuNzkiLCJUTV9TRVNTSU9OX1RSQU5TRkVSIjoiaGI0ZEdyUm5tWE43eEM5cFZCSDZlNlhPQ2dnbmVPTGhEd1JZYWdzQSIsIlRNX0RFVklDRV9UQUciOiIwT2VuTnFBZGxRM2Fwb1ZmSGhkcmJuZ2F2WDRVajNQVCJ9.:false

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
    "access_token":"TXvBKAAAAWd5UCD78H5sKTurkzygh6kMhyA7\/XyL",
    "context":{
        "TM_ACTION_ID":"4465",
        "RMS_DETAILS":"eyJhbGciOiJub25lIn0.e…",
        "token_type":"Bearer",
        "expires_in":86400
    }
}