You can now use the Policy Editor with PingAuthorize Server. First though, explore the interface, paying particular attention to the Trust Framework and Policies sections in the left pane.
Trust Framework
In the Trust Framework section, shown below, you define the foundational elements that you use to build policies and make access control decisions.
The Trust Framework provides several types of entities. The following table describes the ones you will use most.
| Entity | Description |
|---|---|
| Services |
Services perform two functions. Most often, they represent a specific API service or API resource type to be protected by your policies. They can also define policy information points, external data sources (such as APIs or LDAP directory servers) that PingAuthorize can use to make policy decisions. |
| Attributes |
Attributes provide the context that informs fine-grained policy decisions. Attributes often correspond to elements of an HTTP request, such as an access token subject. However, you can obtain their values from a variety of sources. |
| Actions |
Actions label the type of a request and generally correspond to HTTP methods (GET, POST, and so on) or CRUD actions (create, delete, and so on). |
Look at the Trust Framework's default attributes and consider how you could use them in your own policies. Some important Trust Framework attributes include those in the following table.
| Attribute | Description |
|---|---|
HttpRequest.AccessToken |
This is the introspected or deserialized access token from the HTTP request. |
HttpRequest.RequestBody |
This is the HTTP request body, typically present for POST, PUT, and PATCH operations. |
HttpRequest.ResponseBody |
This is the upstream API server's HTTP response body. |
SCIM.resource |
For SCIM operations, this is the SCIM resource being retrieved or modified. |
TokenOwner |
For requests authorized using an access token, this is the user who granted the access token. |
Policies
In the Policies section, shown below, you define your organization's access control policies.
- Policy Set
- A container for one or more policies.
- Policy
- A policy, which defines a set of rules that yield a policy decision when evaluated.
When the policy engine receives a policy request from PingAuthorize Server in response to an API call, it starts at the Global Decision Point and walks down the policy tree, first checking if each policy set or policy is applicable to the current policy request, and then evaluating the rules defined by each policy. Each rule returns a policy decision, typically PERMIT or DENY. Likewise, each policy might return a different policy decision. The policy engine evaluates an overall decision using combining algorithms.
The default policy tree contains the following policy sets and policies:
- Global Decision Point
- This is the root of the policy tree. Place all other policy sets or policies under this
point. This node's combining algorithm is set to A single deny
will override any permit. This algorithm requires no denies
and at least one policy to permit the API call.
- Token Validation
- For most cases, this is the only default policy. It checks for a valid access token. In combination with the Global Decision Point combining algorithm, this is rather permissive. Any API caller can succeed with a valid access token.
- PDP API Endpoint Policies
- The PingAuthorize Server XACML-JSON PDP API uses these policies. They are not discussed further in this tutorial.
You will use the following items in the UI in a tutorial.
- Library
- The default policy library contains example advice and rules.
- Decision Visualiser
- You will use this tool to examine policy decisions in detail.