RiskMinder Java Developer's Guide › Understanding RiskMinder Workflows › Enrollment Workflows › Explicit Enrollment › Scenario 2

Scenario 2

The steps for the explicit enrollment workflow, if you call the CreateUserRequest message after evaluateRisk() function, are:

1. User logs into your online application.

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

2. Your application collects information required by RiskMinder.

   At this stage, your application collects information from the user’s system that will be used by RiskMinder for analyzing 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 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() function.

   At this stage, your application must call the evaluateRisk() function in riskfortAPI. In this call, you must pass all the user and device information that you collected in the preceding step to RiskMinder.

4. RiskMinder performs risk analysis.

   RiskMinder performs risk analysis for the user and generates an advice. In this case, because the user is not yet "known" to the RiskMinder system, the ALERT advice is generated.

5. Your application calls RiskMinder’s createUserRequest message.

   At this stage, your application must make an explicit call to the createUserRequest message in the ArcotUserRegistrySvc Web service. In this call, you must pass all pertinent user details, such as user’s name, last name, organization, e-mail, and their personal assurance message (PAM) to RiskMinder.

   Book: See "Managing Users and Accounts" in the CA RiskMinder Web Services Developer’s Guide for detailed information on the createUserRequest message.

6. RiskMinder creates the user in the database.

   If the createUserRequest call was successful, then RiskMinder creates the user record in the RiskMinder database. With this, user is enrolled with RiskMinder.

7. Your application calls RiskMinder’s evaluateRisk() function again.

   At this stage, your application must again call the evaluateRisk() function in riskfortAPI. In this call, you must ensure that you pass all the user and device information that you collected in Step 2 to RiskMinder.

8. RiskMinder performs risk analysis for the user.

   In this case, RiskMinder executes the rules and generates the risk score and the advice.

9. Your application stores the Device ID on the end user’s system.

   Your application must store the Device ID returned by evaluateRisk() as a cookie on the device that the end user is using for the current transaction.

   The following figure illustrates the explicit enrollment workflow when you call the CreateUserRequest message before the evaluateRisk() call.