Configure PingOne Protect evaluations in web applications protected by PingAccess and set PingAccess's response to the different levels of risk scores that might be returned.
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 PingOne Protect when to start a new evaluation and enable you to apply different access control or authentication challenge policies based on the risk score it 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.
To accomplish these tasks within the administrative console, see:
- To establish a connection between PingOne Protect and PingAccess, see PingOne connections.
- To configure a risk policy, see Risk policies.
- To assign a risk policy to a specific application or application resource, see Application field descriptions and Adding application resources.
To accomplish these tasks within the administrative API, see the following topics:
- To establish a connection between PingOne Protect and PingAccess, see Connecting PingAccess and PingOne Protect.
- To configure a risk policy, see Creating a PingAccess risk policy.
- To assign a risk policy to a specific application or application resource, see Assigning a risk policy to a specific application or resource.
For more information about the /pingone/connections
and
/riskPolicies
endpoints, see /pingone/connections and /riskPolicies endpoints.
To enhance API security, you must include X-XSRF-Header: PingAccess
in all requests and use the application/json
content type for
PUT/POST requests. For more information on using the admin API, see Administrative API endpoints and Accessing the PingAccess administrative API.
PingAccess evaluates the risk policies assigned to each application and resource before processing application and resource-specific rules and rule sets. The system 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> you specified in the risk policy passes. 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.
If the end user meets the constraints set out 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. After PingAccess has completed request processing, it sends PingOne Protect feedback on whether an end user's request was allowed or denied.