PingOne

Authorization attributes

PingOne Authorize attributes provide contextual information that informs fine-grained dynamic authorization decisions.

Attributes, like variables, have a name and store a value. Attribute values come from many sources, including:

  • Constants defined in the Trust Framework.

  • Information points that provide the decision point with information. These data sources, modeled as services in PingOne Authorize, are sometimes referred to as Policy Information Points (PIPs).

  • Decision requests that package information coming from your application. For example, an attribute might correspond to an element of an HTTP request, such as the access token subject.

  • JSON schema properties defined in another attribute.

Attribute hierarchy

Group attributes under parent attributes organized hierarchically in a tree structure. A simple and consistent structure can help your organization understand, update, and debug the Trust Framework.

In addition to the built-in Connectors and PingOne parent attributes, you might want to create parents for attributes used in policies, attributes that retrieve information from requests and services, attributes used in statements, and attributes that provide user details. You can also group attributes based on the decision flows they’re used in, the actions they facilitate, and the teams that are responsible for them.

Screen capture of the Attributes tab showing parent attributes.

You can define up to 4000 objects in each environment. This limit includes attributes and other elements in the Trust Framework. System-owned objects do not contribute to this limit.

Attribute components

You can use the following components in attributes. For more information, see Adding an authorization attribute.

Resolvers

Resolvers define source values for attributes. PingOne Authorize comes with built-in attributes that resolve PingOne identity and service information. Generated attributes resolve against other attributes to automatically extract properties from parent attributes.

Using a pull model, the decision point resolves attribute values only when they’re needed during policy evaluation.

Processors

You can make the original value of an attribute available for use in policies, or you can manipulate the value using processors that convert an attribute value to a different format or extract a specific part of it, such as a specific part of an HTTP response.

You can use the transformed value in other attributes and in named conditions.

Value settings

Attributes have value settings that define the data type of the attribute and an optional default value.

Attribute testing

You can test attributes to validate their output values.