---
title: Adding PingAuthorize policy decision access control rules
description: Add a policy decision access control rule to use the Policy Decision Endpoint to contact PingAuthorize for access information.
component: pingaccess
version: 9.1
page_id: pingaccess:pingaccess_user_interface_reference_guide:pa_adding_pingauth_policy_decision_access_control_rules
canonical_url: https://docs.pingidentity.com/pingaccess/9.1/pingaccess_user_interface_reference_guide/pa_adding_pingauth_policy_decision_access_control_rules.html
llms_txt: https://docs.pingidentity.com/pingaccess/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
revdate: December 4, 2025
section_ids:
  before-you-begin: Before you begin
  about-this-task: About this task
  steps: Steps
  setting-up-the-token-validation-workaround: Setting up the token validation workaround
  about-this-task-2: About this task
  steps-2: Steps
  next-steps: Next steps
  creating-attributes-for-the-client_id-client_secret-and-active-token: Creating attributes for the client_id, client_secret, and active token
  steps-3: Steps
  next-steps-2: Next steps
  creating-policies-to-validate-and-authorize-the-access-token: Creating policies to validate and authorize the access token
  steps-4: Steps
---

# Adding PingAuthorize policy decision access control rules

Add a policy decision access control rule to use the Policy Decision Endpoint to contact PingAuthorize for access information.

|   |                                                                                                                                                                                                                    |
| - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|   | This rule allows for more control over fine-grain authorization decisions than the [PingAuthorize access control rule](pa_adding_pingauth_access_control_rules.html), but isn't compatible with PingOne Authorize. |

## Before you begin

* Create a third-party service with PingAuthorize configured as the target. Learn more in [Adding third-party services](pa_third_party_services.html#adding-third-party-services).

* Make the JSON PDP API available. Learn more in [About the Authorization Policy Decision APIs](https://docs.pingidentity.com/pingauthorize/latest/pingauthorize_server_administration_guide/paz_authr_policy_decision.html).

Limitations:

* Currently, there isn't an out-of-the-box way to perform token validation for PDP calls. If you want to use token validation instead of shared secrets, learn more in [Setting up the token validation workaround](pa_setting_up_the_token_validation_workaround.html).

## About this task

Use a policy decision access control rule to:

* Set the domain, service, and action.

* Provide additional attributes to be sent with the request. This includes static attributes, the request method and request URI, and attributes from the token provider.

* Retrieve information that PingAuthorize returns as a statement and set it as a header.

To add a PingAuthorize policy decision access control rule:

## Steps

1. Click **Access** and then go to **Rules > Rules**.

2. Click **Add Rule**.

3. In the **Name** field, enter a unique name of up to 64 characters.

   Special characters and spaces are allowed.

4. In the **Type** list, select **PingAuthorize Policy Decision Access Control**.

5. In the **Third Party Service** list, select your PingAuthorize service.

6. In the **Authorization Policy Decision Shared Secret** field, enter the shared secret from PingAuthorize.

7. In the **Domain** field, enter the organizational structure in the trust framework to use.

8. In the **Service** field, enter either the service PingAuthorize protects or the data source for the policy decision.

9. In the **Action** field, enter the action that the authorization request might ask to perform on a specific resource.

10. To send the access token to the PingAuthorize service, select the **Send Web Session Access Token as PingAuthorize Request Attribute** checkbox.

11. In the **Mapped Payload Attributes** section, enter any attributes to send to the PingAuthorize service.

    1. Click **+ Add Row** to create a mapping.

    2. In the **Attribute Name** field, enter the name of the attribute.

    3. In the **Attribute Value** list, select the value to which you want to map the attribute.

12. In the **Static Payload Attributes** section, enter any static attributes to send to the PingAuthorize service.

    1. Click **+ Add Row** to create a mapping.

    2. In the **Attribute Name** field, enter the name of the attribute.

    3. In the **Attribute Value** field, enter the value to which you want to map the attribute.

13. In the **Mapped Request Object Payload Attributes** section, enter any request object attributes to send to the PingAuthorize service.

    1. Click **+ Add Row** to create a mapping.

    2. In the **Attribute Name** field, enter the name of the attribute.

    3. In the **Attribute Value** list, select the value to which you want to map the attribute.

14. In the **Mapping Statement Response to Headers** section, enter a JSON pointer to identify any data in the returned statement from PingAuthorize that can be mapped to a header for the response.

    1. Click **+ Add Row** to create a mapping.

    2. In the **Header Name** field, enter the name of the header to which you want to map the data.

    3. In the **Response JSON Pointer** field, enter a JSON pointer that indicates the data in the PingAuthorize statement that you want to map.

15. (Optional) To configure advanced settings, click **Show Advanced Settings**.

    1. In the **Shared Secret Header Name** field, enter the header in which to send the shared secret.

    2. In the **Rejection Handler** list, select a [rejection handler](pa_rejection_handlers.html).

16. Click **Save**.

## Setting up the token validation workaround

Shared secrets are available out of the box with the PingAuthorize policy decision access control rule, but token validation is not. You can perform the following workaround to set up token validation.

|   |                             |
| - | --------------------------- |
|   | This procedure is optional. |

### About this task

To set up token validation, you'll build the call to the introspection endpoint manually and create a policy to check if the token is active.

There are three main steps in this workaround:

1. Creating an HTTP service for the PingFederate introspection endpoint

2. Creating attributes for the `client_id`, `client_secret`, and active token

3. Creating a policy to validate the access token

To create an HTTP service for the PingFederate introspection endpoint:

### Steps

1. In the PingAuthorize administrative console, go to **Trust Framework > Services > PDP** and create a service named `PingFederate Introspection`.

2. In the **Service Type** list, select **HTTP**.

3. In the **HTTP Settings** section:

   1. In the **URL** field, enter the PingFederate introspection endpoint.

   2. In the **HTTP Method** list, select `POST`.

   3. In the **Body** field, enter `token={{HttpRequest.AccessToken.access_token}}`

   4. In the **Authentication** list, select **Basic**.

   5. In the **Username** list, select the PingFederate client option.

   6. In the **Password** list, select the PingFederate client option.

4. In the **Value Processors** section, add a new JSON path processor:

   1. In the **Processor** list, select **JSON** and enter `active` in the field.

   2. In the **Value Type** list, select **Boolean**.

5. In the **Value Settings** section:

   1. In the **Type** list, select **String**, and enter `Secret` in the field.

6. In the **Timeout and Retry** section:

   1. In the **Request Timeout (ms)** field, enter `2000`.

7. Click **Save**.

### Next steps

[Create attributes for the `client_id`, `client_secret`, and active token](pa_creating_attributes.html).

### Creating attributes for the `client_id`, `client_secret`, and active token

Create the attributes you'll reference in the access token validation policy.

#### Steps

1. In the PingAuthorize administrative console, go to **Trust Framework > Attributes**.

2. In the **PingFed Client** section, create a `client_id` attribute:

   1. In the **Parent** list, select **PingFed Client**.

   2. In the **Value Settings** section:

      1. Select the **Default Value** checkbox and enter the client ID from the OAuth resource server that you want to use to validate the token in the field.

         For example, **authroize_rs**.

      2. In the **Type** list, select **String**.

   3. In the **Caching** section:

      1. In the **Cache Strategy** list, select **No Caching**.

3. In the **PingFed Client** section, create a `client_secret` attribute.

   1. In the **Parent** list, select **PingFed Client**.

   2. In the **Value Settings** section:

      1. Select the **Default Value** checkbox and enter the corresponding client secret from the OAuth resource server that you want to use to validate the token in the field.

      2. In the **Type** list, select **String**.

   3. In the **Caching** section:

      1. In the **Cache Strategy** list, select **No Caching**.

4. Go to the **SCIM2** section, and create a `TokenActive` attribute to resolve the `PingFederate Introspection` service:

   1. In the **Resolvers** section:

      1. In the **Resolver type** list, select **Service**, then select **PingFederate introspection**.

   2. In the **Value Settings** section:

      1. In the **Type** list, select **Boolean**.

   3. In the **Caching** section:

      1. In the **Cache Strategy** list, select **No Caching**.

#### Next steps

[Create a policy to validate the access token](pa_creating_attributes.html).

### Creating policies to validate and authorize the access token

Create policies to validate the access token and determine authorization requirements.

#### Steps

1. In the PingAuthorize Policy Editor, go to the **Policies** tab.

2. Go to the **Global Decision Endpoint** section and create a new policy called `Token Validation`.

3. In the **Rules** section, in the **Combining Algorithm** list, select **Unless one decision is deny, the decision will be permit**.

4. In the **Rules** section, add an **Access token is inactive** rule:

   1. In the **Applies to** section, select **Add definitions and targets, or drag from components** and **All requests**.

   2. In the **When** section, map the following:

      1. Select **All**, then select **TokenActive**, **Equals**, and **False**.

      2. Select **Any**, then set **Any Inbound Request** to **is True**, and **Any SCIM or OpenBanking Request** to **is True**.

         ![Screen capture of an example Access token is inactive rule.](_images/tokenValidationPolicy.png)

5. In the **Statements** section:

   1. Add an **Invalid Token** statement:

      1. In the **Code** field, enter `denied-reason`.

      2. In the **Applies To** field, enter `Deny`.

      3. In the **Applies If** field, enter `All decisions in path match`.

      4. In the **Payload** field, enter `{"status":401, "message":"invalid_token","detail":"Access token is expired or otherwise invalid"}`.

      5. Make sure the **Obligatory** checkbox is selected.

6. Click **Save**.