The Trust Framework provides several built-in attributes that enable you to use PingOne services and data right out of the box.
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 () 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.
- User attribute
-
The User attribute (
PingOne.User
) resolves from theuserContext.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 theuserContext.user.id
property of the decision request and returns the ID of the identity requesting access to a resource.
- 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.
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.
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-inPingOne.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. - 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-inPingOne.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.