CA CloudMinder Advanced Authentication › How Advanced Authentication Works › End User Authentication Flows › ArcotID PKI 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.

End users are authenticated as follows:

1. When trying to access a protected resource in a browser, the end user is prompted for their user name and LDAP password.
2. The Advanced Authentication service verifies that the end user is an existing user, but there is no ArcotID PKI credential on the device being used.
3. The end user is prompted for secondary authentication using the security question or security code mechanism.
4. If the authentication is successful, then depending on whether two-step authentication is enabled or not, 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.
   • If two-step authentication is enabled:
     1. The end user is authenticated using a second form of authentication.

     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.

   Note: Two-step authentication is not enabled if the ArcotID PKI mobile client is used for authentication. In this case, all configured authentication methods are used one after the other.

5. The browser displays the login page with the user name, prompting the end user for the password again.
6. The Advanced Authentication service then authenticates the user.
7. Upon successful authentication, the Advanced Authentication service also 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.
      • Posts the results 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 3 and 4) 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 DeviceID is recorded 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.