PingOne Protect monitors end user requests and generates a risk score of low, medium, or high, based on the user's activity and device context.

You can create risk policies through the PingAccess administrative console or administrative API to respond to PingOne Protect's evaluations dynamically. Risk policies tell PingAccess when to gather user device profile information and start a new evaluation. They also enable you to apply different access control or authentication challenge policies based on the risk score that PingOne Protect determines.

For example, if the determined risk score is MEDIUM, you might direct the user to complete step-up authentication with additional multi-factor authentication (MFA) methods. However, if the determined risk score is HIGH, you might completely deny access to the resource instead.

The following topics demonstrate how to integrate PingOne Protect evaluations within PingAccess and create PingAccess risk policies to leverage different responses to end user requests based on their determined risk score:

  1. To configure a connection between PingOne Protect and PingAccess, see Adding a PingOne connection.
  2. To configure a risk policy, see Adding a risk policy.
  3. To assign a risk policy to a specific application or application resource, see Application field descriptions and Adding application resources.

PingAccess evaluates the risk policies assigned to each application and resource before processing application and resource-specific rules and rule sets.

  1. If you enabled device profiling in your risk policy configuration, either PingAccess collects the user's device profile or the front end application collects the user's device profile and submits it to PingAccess.
  2. PingAccess collects user data, such as user ID and user-agent IP address, then sends a risk evaluation request to PingOne Protect each time the <riskCheckInterval> that you specified in the risk policy passes.
  3. After PingOne Protect returns an evaluation, PingAccess follows the response specified in the risk policy for the determined risk score or for a failed evaluation if PingAccess is unable to gather the expected risk response from PingOne Protect.

    For example, if the returned risk score is HIGH and the risk policy specifies that an authentication challenge policy (ACP) should be issued to an end user with a high-risk score, then PingAccess returns the authentication challenge defined by the ACP to the end user for reauthentication.

    If the risk policy specifies that PingAccess should follow a specific rule or rule set, then it uses that rule or rule set to determine whether the end user should be allowed access.

  4. If the end user meets the constraints set by the risk policy, PingAccess moves on to the next stage of request processing, reviewing the normal policies attached to the application or resource.

    If a request is denied, PingAccess uses the rejection handler set within the risk policy or follows the rejection response specified in the rules or rule sets attached to the application or resource. The former case is applicable if the risk policy was set to deny an end user's request. Otherwise, the rejection response specified in the normal policy takes precedence.

  5. After PingAccess has completed request processing, it sends PingOne Protect feedback on whether an end user's request was allowed or denied.