Previous Topic: ArcotID PKI Roaming FlowNext Topic: ArcotID PKI Roaming with Risk Flow


ArcotID PKI with Risk Flow

The ArcotID PKI with Risk flow defines the steps that must be performed to authenticate end users by using both the ArcotID PKI credential and Risk Evaluation credential. At runtime, this flow takes effect only if both these credentials are enabled.

This section describes the end-user authentication flow based on the following assumptions:

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 then verifies that the end user is an existing user and checks for the presence of an ArcotID PKI on the device being used.
  3. After the presence of ArcotID PKI is confirmed, the Advanced Authentication service authenticates the user.
  4. 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 ArcotID PKI Roaming Flow) 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.

    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.