Advanced Authentication Service › Advanced Authentication Flows › Advanced Authentication Flows › Risk Evaluation-Based Flows › ArcotID PKI Roaming with Risk Flow

ArcotID PKI Roaming with Risk Flow

This section describes the authentication and risk flow for an end user who is enrolled but is using a different device to which the ArcotID PKI credential has not been provisioned.

The Flow:

1. In a browser window, the end user attempts to access a protected resource.
2. On the login page, the end user enters their user name and password, and then clicks Submit.
3. CA SiteMinder verifies the end user's login credentials.
4. The ArcotID PKI Client checks for an ArcotID PKI for the provided user name but does not find it on the end user’s device.
5. The Advanced Authentication application invokes the Advanced Authentication Server to retrieve the end user’s ArcotID PKI.
6. If the user name exists in the database but if their ArcotID PKI is on a different device, the user is challenged for secondary authentication. Depending on the secondary authentication mechanism, one of the following sequence of steps takes place:
   • If Security Question has been set as the secondary authentication mechanism, then:
     1. The Advanced Authentication application invokes IdentityMinder to retrieve the security questions.
        The page with challenge questions is presented to the end user. On the same page, the end user can specify whether the ArcotID PKI must be stored for future sessions.
     2. The end user submits answers to the security questions.
     3. The Advanced Authentication application invokes IdentityMinder to verify the answers.
   • If Security Code has been set as the secondary authentication mechanism, then:
     1. The Advanced Authentication application invokes the Advanced Authentication Server to generate a security code and fetch the end user’s email address and/or phone number.
     2. If more than one delivery channel has been configured, then the end user selects a preferred channel.
     3. The Advanced Authentication application invokes the delivery channel.
     4. The Advanced Authentication application presents a page challenging the end user for the security code.
        On the same page, the end user can specify whether the ArcotID PKI must be stored for future sessions.
     5. The end user submits the security code.
     6. The Advanced Authentication application invokes the Advanced Authentication Server to verify the security code.
7. If the verification is successful, depending on whether two-step authentication is enabled, either of the following steps take place:
   • If two-step authentication is not enabled:
   • The ArcotID PKI credential is downloaded to the end user’s device.
     1. The ArcotID PKI Client loads the ArcotID PKI.
   • If two-step authentication is enabled:
     1. The end user is presented the second form of authentication, and is authenticated as described in Step 6.

     Note: If security question was used the first time, then security code is used in this step. Conversely, if security code was used the first time, then security question is used in this step.

     1. If the verification is successful:
     • The ArcotID PKI credential is downloaded to the end user’s device.
     • The ArcotID PKI Client loads the ArcotID PKI.
8. Upon downloading the credential, the browser displays the login page with the user name and challenges the end user for the password.
9. The end user enters the password and completes the rest of the authentication process.
10. If authentication is successful, the Advanced Authentication service performs a risk check as follows:
    1. A JavaScript that is running in the browser does the following:
       • Checks whether a DeviceID has been recorded on the device.
       • Extracts DeviceDNA from the device to identify the device.
       • Sends this information back to the Advanced Authentication service without requiring any user inputs.
    2. The Advanced Authentication service validates the DeviceID and DeviceDNA using the configured risk rules. It then generates a risk advice.
    3. Depending on the risk advice, one of the following happens:
       • If the Advanced Authentication service returns an ALLOW advice, then the end user is granted access to the resource.
       • If the Advanced Authentication service returns an INCREASEAUTH advice, the end user is prompted for secondary authentication. If secondary authentication (described in steps 6 and 7) is successful, the end user is granted access to the resource.
       • If the Advanced Authentication service returns a DENY advice, then an error message is displayed indicating that the authentication failed.

       Notes:

       • For every time that secondary authentication is invoked in a flow, one or more secondary authentication mechanisms are exhausted. Therefore, for a flow that requires more than one round of secondary authentication, ensure that you enable as many secondary authentication mechanisms as possible. An error occurs if secondary authentication is invoked and no mechanism left.
       • If two-step authentication is enabled, and if one of the authentication methods overlaps for the roaming and risk flows, when the end user chooses that common method in the first flow and authenticates successfully, that authentication method is skipped in the next flow.

         For example, if security question or security code over email is enabled for roaming authentication, and security question or security code over SMS is enabled for risk authentication, and if the end user selects security question first and is authenticated successfully, they are not authenticated again during the risk flow. However, if the end user selects security code over email the first time and is authenticated successfully, then in the risk flow, the user is authenticated again using security question.

         In another example where security question or security code over email is enabled for roaming authentication, and security question and security code over SMS are enabled for risk authentication, if the end user selects security question in the roaming flow and is authenticated successfully, then in the risk flow, the security code over SMS method is invoked. However, if the end user selects security code over email in the roaming flow, then both security question and security code over SMS are invoked in the risk flow.

    A risk cookie is placed on the end user's device. During subsequent logins, the risk history is used to decide whether to grant access to the end user after authentication.