LexisNexis offers a suite of products to authenticate and verify the identity of users: slug: risk-management-enhanced-sdk-web-framework-v2-partners-integration-threatmetrix

The LexisNexis Threatmetrix is a digital identity intelligence platform that provides businesses with tools to authenticate and verify the identity of online users in real time.

The LexisNexis Behaviosec product that provides a predictive behavioral biometric analysis solution.

Both products are accessible via one une unique API called Dynamic Decision Platform (DDP)

The following steps are mandatory only if you are using the LexisNexis DDP service.

SSL Hosting

This feature is mandatory to use ThreatMetrix collecting scripts. There is nothing to integrate in your page; it is only certificate and DNS configuration. Please fill in the related information in the onboarding form that your project leader should have provided to you.

Procedure overview

Your project leader will guide you through the procedure, but the details are available in the ThreatMetrix knowledge base: https://portal.threatmetrix.eu/kb/index.htm#t=portal%2Fforensics%2Fintroduction_forensics.htm As a short description, here are the main steps that will be required: 1. Fill in the onboarding form 2. Your project leader will ask ThreatMetrix to generate a certificate signing request (CSR) with the completed onboarding information 3. Your project leader will give you the generated CSR so that you can use it to ask for a signed certificate from your preferred Certificate Authority 4. Return this signed certificate to your project leader so that it can be set up in the ThreatMetrix backend 5. Then your project leader will provide you with a domain name returned by ThreatMetrix so that you can set up an entry in our DNS.

Note for Multi-Page website integration

When integrating ThreatMetrix in a Use Case which contains several pages, collecting ThreatMetrix data is required only once per Use Case. As ThreatMetrix data may take time, it is recommended to choose the page on which the user spends the most time. So, ThreatMetrix partners can be included only once per Use Case (by using the partners parameter when integrating the GAH script).

DDP

The Dynamic Decision Platform (DDP) is a comprehensive solution that enables the integration of advanced behavioural biometrics into your application without requiring the full ThreatMetrix® platform. This platform allows for the real-time collection, analysis, and application of behavioural data to enhance security and improve user experience.

Reset Profile

Resetting a user profile is an important operation that ensures the accuracy of behavioural data in the system. This operation is typically required when a user profile has been incorrectly trained due to anomalous events or implementation issues. Resetting the profile allows the system to start fresh and retrain the profile based on new, accurate data.

A user profile should be reset in the following scenarios:

Incorrect Training: If the profile was trained during a period when the user was not exhibiting normal behaviour (for example, during a scam or due to implementation errors).

Behavioural Anomalies: If there are significant and persistent anomalies in the user's behaviour that suggest the profile does not accurately reflect the user.

To reset a user profile, an API call is made with two parameters: userId and target. Depending on the value of target, the API call can either reset the entire profile or just the password-related behavioural data.

BehavioSec

The following steps are mandatory only if you are using the BehavioSec service; otherwise you can skip this section. In order to add the BehavioSec analysis to your page, an extra configuration step is required. It consists in: - Declaring the page identifiers in the BehavioSense dashboard - Customizing your HTML pages to list the fields that should be anonymous or excluded from the BehavioSec analysis, if any.

1. Pages declaration

The pages for which BehavioSec must be implemented have to be declared in the BehavioSense dashboard (menu settings > page definitions). Every single page analysed must be declared. This includes both HTML web pages and mobile application pages. Please refer to this link to get the documentation for a detailed description of the BehavioSense dashboard: https://developer.behaviosec.com/dw/dashboardguide/main

Note

Credentials for the sites mentioned above will be provided by Thales once on boarding process has been completed.

New Account Originating Use Case

To setup a page for New Account Originating, the page definition must follow a set of specific rules. - The page definition MUST disable the Anomaly Detection. For each field of your page, - Your type “c” (movement) fields MUST disable Remote Access detection reason 5 - Your fields MUST be Ignore to True. This prevents BehavioSense from calculating a Behavioral Score for the specific user associated with this Target. - Your fields MUST be New Account Fraud target to True.

Please refer to this link to get the documentation for a detailed description: https://developer.behaviosec.com/dw/dashboardguide/new_account_fraud#configure_page_definitions_to_use_new_account_fraud

2. Pages Customization

If there are data that has to be kept confidential, then masked and anonymous types can be used. The masked type is preferred from an analysis point-of-view (e.g. for RAT detection) but may in some scenarios be considered not confidential enough as it will not mask keys like "shift", “control”, etc. Anonymous fields We recommend to make every input field of type password anonymous. Other fields can also be made anonymous. These fields can be identified either by their name, id or type. Warnings: - ONLY set static input fields as anonymous (that is, fields where the input never changes for each user, such as password fields). - Setting anonymous for any type of field where the input changes will not work. - If a password field is configured as anonymous and the password is changed, then the profile for that target of that user must be reset.

Masked fields Masked type can be used as an alternative to anonymous type when the data doesn’t have to be kept strictly confidential. Using masked type will provide more information from an analysis point-of-view.

Ignored fields It is also possible to configure a black-list of fields that should not be monitored. In this case you can identify them either by their id or name.

PageId There is a mapping on the server side to analyse the behaviour of the end user on your page. This mapping is based on the pageId that you will define pageId param inside Behaviosec configuration for each page or view. It is important to define this id if you want to set some weight to the different fields of your pages.

There are two solution for setting the Behaviosec configuration of the view:

For a multi Page Website:

You can set the ifp_params variable with the configuration, before including our script:

 <head>...
    <script>
       var ifp_params = {
                bhv: {
                    pageIdCallback: function () {
                        return "ebanking/auth/login"
                    },
                    anonymous: {
                        by_name: ["userId"]
                    }
                }
            }
    </script>

    <script src="<%= signalCollectorUrl %>/api/v2/tenants/<%= tenantId %>/scripts?auto=1"></script>
    ...
</head>

If the Use Case contains several pages, this ifp_params variable has to be set on every page (with the page’s specific configuration).

Note

Behaviosec Multi page implementation may have a significant impact on the getDecision performance

For a Single Page Application:

Behaviosec configuration can be sent directly through the ifp_initView or ifp_initUseCaseAndView methods:

Ifp_initView(visitId,  {
                bhv: {
                    pageIdCallback: function () {
                        return "ebanking/auth/login"
                    },
                    anonymous: {
                        by_name: ["userId"]
                    }
                }
            });

If the Use Case contains several views, this has to be done on every views (with the view’s specific configuration).

Note

Behaviosec Multi page implementation may have a significant impact on the getDecision performance