Built-in attributes are nested under the PingOne parent attribute on the Attributes tab. PingOne Authorize owns the PingOne attribute and its children.

The Shield (Screen capture of the shield icon.) icon indicates that these attributes are system-owned and editing restrictions apply. You can’t move, update, or delete these attributes, or nest your own attributes under them. This ensures that built-in attributes are configured correctly and always available.

User attributes

Built-in User attributes model user identity information for use in other attributes and directly in policies.


Screen capture of the Attributes tab in the PingOne Authorize Trust Framework showing the User and ID attributes nested under the PingOne parent attribute.
User attribute

The User attribute (PingOne.User) resolves from the userContext.user.id property of the decision request and returns a JSON object that provides data about the identity requesting access to a resource.

This attribute retrieves the PingOne user object through the /environments/{envID}/users/{userID} endpoint. For information about the properties of the user object, see Users data model.

User ID attribute

The User ID attribute (PingOne.User.ID) resolves from the userContext.user.id property of the decision request and returns the ID of the identity requesting access to a resource.

Note:
  • To use these attributes, make sure the PingOne SSO service is in your environment. This enables Identities in PingOne.
  • When you run test scenarios for these attributes on the Test tab, use the PingOne User field to simulate a request from any user in the current environment.
  • These attributes resolve identities stored in PingOne and do not access user information in external identity stores. If you’re using an external identity store, create your own user attributes that resolve against your identity store.

You can derive your own attributes for user data from built-in user attributes. For example, the following attribute uses a JSON path value processor to resolve the PingOne user’s email address.

Screen capture showing a PingOne User resolver and a JSON Path value processor that work together to extract the PingOne user's email address.

API Access Management attributes

API Access Management attributes model API servers and operations, HTTP requests and responses, and access tokens. PingOne Authorize generates these attributes when you define an API service.

Screen capture of the Attributes tab in the PingOne Authorize Trust Framework showing API Access Management attributes nested under the PingOne parent attribute.

You can derive your own attributes from built-in API Access Management attributes, as shown in the following examples:

Custom access token claim attribute

In the following attribute, a value processor is used to resolve a custom claim called title from the built-in PingOne.API Access Management.Identity.Access Token attribute. To ensure that a token without the custom claim is resolved successfully, the attribute has an empty string as its default value. In this example, the claim’s JSON data type is String. Access token claims can have other data types, including Number and Collection.

Screen capture showing an Access Token attribute resolver and a JSON Path value processor that work together to extract the custom Title claim from the access token.
HTTP request header attribute

To allow policy authors to use a custom header in policies, you can define an attribute that extracts a custom header value from an HTTP request or response. In the following attribute, a value processor is used to resolve the X-Shared-Secret value from the built-in PingOne.API Access Management.HTTP.Request.Headers attribute as a collection. To ensure that a header without the custom value is resolved successfully, the attribute has an empty collection as its default value.

Screen capture showing a Request Headers attribute resolver and a JSON Path value processor that work together to extract a custom header value.