Explicit Enrollment

aa821test
 
 
2115401
In case of 
explicit enrollment
, you must explicitly call CA Risk Authentication’s createUserRequest message in the ArcotUserRegistrySvc Web service from your application’s code to create a user in CA Risk Authentication database. You can call this function either 
before
 (Scenario 1) or 
after
 (Scenario 2) you perform risk evaluation (by using the evaluateRisk()call.)
Scenario 1
The steps for the explicit enrollment workflow, if you call the createUserRequest message in the ArcotUserRegistrySvc Web service 
before
 evaluateRisk() function are:
  1.  
    User logs in to 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 calls CA Risk Authentication 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, email, and their personal assurance message (PAM) to CA Risk Authentication.
     
    Book: 
    See "Managing Users and Accounts" in the 
    CA Risk Authentication Web Services Developer’s Guide
     for detailed information on the createUserRequest message.
  3.  
    CA Risk Authentication creates the user in the database.
    If the createUserRequest call was successful, then CA Risk Authentication creates the user record in the CA Risk Authentication database. With this, user is enrolled with CA Risk Authentication.
  4.  
    Your application collects information required by CA Risk Authentication.
    At this stage, your application collects information from the user’s system that will be used by CA Risk Authentication 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 CA Risk Authentication's Utility Script called CA Risk Authentication-client.js to collect this information.
    •  
      Device information
       that includes Device ID, which is stored on the end user's device.
    •  
      Transaction information
       that includes the name of the channel being used by the user, a numeric identifier for the transaction, and some other information about the transaction.
    •  
      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.
  5.  
    Your application calls CA Risk Authentication’s evaluateRisk() for risk analysis.
    In this case, because you enrolled the user 
    before
     performing risk analysis, the CA Risk Authentication system "knows" the user and does not generate the ALERT advice. Refer to "Risk Evaluation Workflows" for more information.
  6.  
    CA Risk Authentication performs risk analysis.
    CA Risk Authentication generates a risk score and an advice.
  7.  
    Your application stores the Device ID on the end user’s device.
    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 make the createUserRequest message call before the evaluateRisk() call.
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 CA Risk Authentication.
    At this stage, your application collects information from the user’s system that will be used by CA Risk Authentication 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 CA Risk Authentication's Utility Script called CA Risk Authentication-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 the CA Risk Authentication 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 CA Risk Authentication.
  4.  
    CA Risk Authentication performs risk analysis.
    CA Risk Authentication performs risk analysis for the user and generates an advice. In this case, because the user is not yet "known" to the CA Risk Authentication system, the ALERT advice is generated.
  5.  
    Your application calls the CA Risk Authentication’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 CA Risk Authentication.
     
    Book: 
    See "Managing Users and Accounts" in the 
    CA Risk Authentication Web Services Developer’s Guide
     for detailed information on the createUserRequest message.
     Integrated Application.png 
  6.  
    CA Risk Authentication creates the user in the database.
    If the createUserRequest call was successful, then CA Risk Authentication creates the user record in the CA Risk Authentication database. With this, user is enrolled with CA Risk Authentication.
  7.  
    Your application calls the CA Risk Authentication 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 CA Risk Authentication.
  8.  
    CA Risk Authentication performs risk analysis for the user.
    In this case, CA Risk Authentication executes the rules and generates the risk score and the advice.
  9.  
    Your application stores the Device ID on the end-user 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.
    Explicit enrollment workflow.png