RiskMinder Web Services Developer's Guide › Understanding RiskMinder Workflows › Risk Evaluation Workflows › Post-Login Risk Evaluation Workflow › Secondary Authentication Workflow

Secondary Authentication Workflow

When RiskMinder generates the INCREASEAUTH advice, it transfers the control back to your application temporarily for secondary authentication. In this case, your application must implement some mechanism for performing additional authentication. For example, your application can display industry-standard security (or challenge) questions to the user (such as mother’s maiden name and date of birth) or make them undergo out-of-band phone authentication.

After you determine whether the user authenticated successfully or not, you must forward the result to RiskMinder, which uses this feedback to generate the final advice, update device information, create association information, and store the feedback to use for risk analysis of future transactions.

The risk evaluation workflow in the case of secondary authentication is as follows:

1. User logs in to your online application.

   Your system validates if the user exists in the system. If the user is not valid, then your application must take appropriate action.

2. Your application collects information required by RiskMinder.

   Your application collects the following information from the user\xE2\x80\x99s system that will be used by RiskMinder for analyzing the risk:

   • User system information that includes operating system, platform, browser information (such as browser language, HTTP header information), locale, and screen settings. Your application uses RiskMinder's Utility Script called riskminder-client.js to collect this information.
   • Device information that includes Device ID, which is stored on the end user's device.
   • Location information that includes the IP address and Internet Service Provider related information.
   • (Optionally, if you are using additional information) Additional Inputs that are specific to custom rules or the channel selected.
3. Your application calls RiskMinder’s evaluateRisk operation.

   Your application must call the evaluateRisk operation in RiskFortEvaluateRiskSvc. In this call, you must pass all the user and device information that you collected in Step 2 to RiskMinder.

4. RiskMinder performs risk analysis for the user.

   If RiskMinder flags the transaction as suspicious, it generates the INCREASEAUTH advice. This implies that extra credentials are required to further authenticate the user.

5. Your application performs secondary authentication.

   Based on the secondary authentication mechanism that you are using, your application displays the appropriate pages to the user. For example, you can prompt the user to:

   • Answer the security questions that they selected while enrolling with your application.
   • Perform One-Time Password (OTP) authentication.
   • Perform out-of-band phone authentication.

   After receiving the user input, your application determines the outcome of the additional authentication.

6. Your application calls RiskMinder’s postEvaluate operation and forwards the result of the secondary authentication to RiskMinder.

   Irrespective of whether the user failed or cleared the secondary authentication, your application must pass the result back to RiskMinder. This information helps RiskMinder build an up-to-date and accurate user history.

   To do so, your application must call the postEvaluate operation in RiskFortEvaluateRiskSvc. In this call, you must pass the risk score and advice from the evaluateRisk call, the result of secondary authentication, and any association name, if the user specified one.

7. RiskMinder generates the final advice.

   By using your application’s feedback regarding the secondary authentication, RiskMinder generates the final advice.

8. RiskMinder updates the device information and creates the association information.

   Based on the result of the postEvaluate call, RiskMinder also updates the device attributes and creates the association information in the RiskMinder database.

9. Your application takes the appropriate action.

   Based on the result of the postEvaluate call, your application either allows the user to continue with the transaction or denies them access to the protected resource.

The following figure illustrates the secondary authentication risk evaluation workflow.

Secondary Authentication Risk Evaluation Workflow