RiskMinder Java Developer's Guide › Getting Started › Overview of the Integration Steps

Overview of the Integration Steps

The RiskMinder SDK offers you multiple degrees of freedom in the available integration methods and the types of risk-based authentication flows. (See "Understanding RiskMinder Workflows" for more information on supported workflows.) This enables you to design the optimal authentication solution that best suits your organization’s requirements.

The RiskMinder flows can be integrated with your online application at the points discussed in following subsections.

Before a User Logs in to Your Application (and Just Accesses the Login Page)

In this case, your application must invoke RiskMinder’s evaluateRisk() function call from the login page (before the user specifies the login credentials) to assess the risk associated with the incoming data. For example, you can evaluate the IP address and/or the country for Negative IP and Negative Country checks.

Note: Negative IP addresses is a collection of IP addresses that have been the origin of known anonymizer proxies or fraudulent or malicious transactions in past. Similarly, Negative countries is a collection of all countries from which fraudulent or malicious transactions have been recorded in past.

In this case, you can also evaluate other RiskMinder rules that do not require user information. These include Device Velocity Check and any custom rules you might have implemented.

After a User Logs in to Your Online Application (By Specifying the User Name and Password to Access Their Account or the Protected Resource)

In this case:

1. Your application must invoke RiskMinder from the main page of your application that appears after successful login. The following scenarios are possible:
   • User is enrolled with RiskMinder, and must undergo risk evaluation.

     In this case, your application must invoke RiskMinder’s evaluateRisk() function call by passing user, device signature (collected by using the DeviceDNA Javascript provided by RiskMinder), IP address, and transaction details for assessing the risk:

     • If the received user data is assigned a low score after rule execution (based on the incoming data and the data stored for this user or device), then the advice is ALLOW. In this case, your application grants access to the user to the protected resource or Web page and allows the user to continue with the transaction.
     • If the received user data is assigned a high score after rule execution (based on the incoming data and the data stored for this user or device), then the advice is DENY. In this case, your organizational policies determine the outcome. The transaction can be denied or can be forwarded to a security analyst (known as Customer Support Representative (CSR) in RiskMinder terminology) for review and further action.
     • If a transaction is flagged as suspicious, then the advice is INCREASEAUTH. In this case, your application must perform a secondary authentication, which can include industry-standard one-time password (OTP) or security questions (such as mother’s maiden name and date of birth).

     Note: You can also use CA AuthMinder for this purpose.
     See http://www.ca.com/us/two-factor-authentication.aspx for more information.

     Only if your application authenticates the user during the secondary authentication, then you must grant the user access to the protected resource or Web page and allow the user to continue with the transaction.

   • User is new to RiskMinder, and therefore must be enrolled with it.

     In this case, your application must invoke RiskMinder’s createUserRequest message in the ArcotUserRegistrySvc Web service by passing user details to create the user in RiskMinder database.

     Important! Because RiskMinder works "behind the scene" for an end user, it is recommended that you do not change the end-user experience for this enrollment.

     After RiskMinder "knows" the user after this enrollment, then you must call the evaluateRisk() function and allow the user to proceed with the transaction, if the advice is ALLOW.

     See "Enrollment Workflows" for more information on the two different ways in which you can enroll users.

2. Your application invokes RiskMinder’s postEvaluate() function after the evaluateRisk() function. RiskMinder Server determines whether to create a user-device association and update the attributes based on the results of this function.