Policies are built by business analysts who understand your application requirements and the regulations that you’re complying with. Your organization imposes many conditions and constraints on access control. Policies capture these constraints in rules that define the circumstances under which users can access certain resources.

Structuring policies

You can group policies using policy sets organized hierarchically in a tree structure. PingOne Authorize owns the Policies and API Access Management root policy sets.

The Shield (Screen capture of the shield icon.) icon indicates that these policy sets are system-owned and editing restrictions apply. You can’t move or delete these policy sets. This ensures that they are configured correctly and always available.

Screen capture showing the Policies and API Access Management root policy sets, the shield icon , and a policy nested under root policy set.
Policies policy set

You can nest your own policy sets and policies under the Policies policy set:

  • Add a root policy set to contain all other policy sets. This is useful when you publish the policy tree to a decision endpoint.
  • Branches can include policies and other policy sets as children. You can branch the policy tree up to 20 levels deep.
  • Policies are evaluated in order from top to bottom in the tree. This allows you to control the order of execution using the structure of the tree.
  • Place frequently used policies and policies for lightweight decisions near the top of the tree.

For more information, see Adding a policy or policy set.

API Access Management policy set

The API Access Management policy tree is generated when custom policies are enabled for an API service. The tree includes a policy set for each API service, with default policy sets nested under it. You can add your own policies under Custom policy sets in the tree.

Screen capture showing the API Access Management policy tree expanded to the Custom policy set for Inbound Requests.

The location of custom policies in the tree determines whether they are relevant to particular requests or responses. For example, a custom policy at the location selected in the image above would target any inbound request to the Meme Game API service. For more information, see Adding custom policies for API services and operations.

Policy components

Use the following components in policies and rules to capture authorization logic:

Targets

Targets use comparisons to enable the decision service to determine which policies or rules are relevant to a particular request.

Statements

Statements instruct the policy decision service to perform additional processing in conjunction with an authorization decision. In addition to allowing or blocking access to a resource, using statements, the decision service can attach information to decision responses and filter and transform API payloads.

Combining algorithms

To evaluate the overall decision of a policy, the decision service applies a combining algorithm. The algorithm determines how rules are combined to produce an authorization decision.

Note:

Each environment can have up to 2000 entities. This limit includes policies and rules, and also entities in the Trust Framework.

Testing policies

You can test policies from end-to-end with visualization tools that show the complete decision flow. For more information, see Testing policies.