Resolvers

Resolvers define where attributes pull information from.

An attribute can have one or more resolvers. Resolvers can be conditional. In addition, you can add a processor to a resolver to modify the attribute value.

PingOne Authorize resolves an attribute when the attribute value is used in a decision evaluation. Multiple resolvers are resolved in order of appearance in the attribute definition until one of them produces a value. You can drag collapsed resolvers to change their order. If a resolver fails to resolve successfully, processing moves on to the next resolver.

Learn more in Adding resolvers to an attribute.

Resolver types

You can use the following types of resolvers:

Resolver type Description

Attribute

Resolves an attribute from other attributes. This enables you to extract a child attribute or subset from an attribute that contains multiple pieces of information.

For example, consider a Customer.Name attribute that returns the following JSON representation:

{ “firstname”: “Andrew”, “middlename”: “James”, “surname”: “Martin” }

You can use an Attribute resolver to extract the surname. Create a Customer.Name.Surname attribute that resolves against the Customer.Name attribute. Then, add a JSON path processor to extract the Surname property of the JSON using the expression $.fullname[0].surname.

When an attribute has a defined JSON schema, you can generate attributes from schema properties.
When an attribute has a parent, you can click the Add Parent Resolver button to resolve the child attribute against its parent.

Constant

Takes a constant value defined on the resolver itself. The type and value of the constant are required.

Constants undergo any value processing defined for the attribute.

Current Repetition Value

Resolves an attribute from a repetition source attribute. The source attribute’s value setting must be Collection. You can use this resolver in attributes that have repetition settings.

PingOne User

Resolves the attribute from the user ID provided in the decision request and returns the entire user object. This resolver uses the built-in PingOne User attribute without requiring any additional configuration.

When you run test scenarios for the attribute on the Test tab, use the PingOne User field to simulate a request from any user in the current environment.

PingOne User ID

Resolves the attribute from the user ID provided in the decision request and returns the ID. This resolver uses the built-in PingOne User ID attribute without requiring any additional configuration.

When you run test scenarios for the attribute on the Test tab, use the PingOne User field to simulate a request from any user in the current environment.

Request Parameter

Looks inside the decision request to determine whether the attribute has been provided by the caller. Specify the full name of the attribute, including any parents, in the request.

Service

Resolves the attribute by using a Trust Framework authorization services endpoint to invoke the service at runtime. The service might rely on other attributes being supplied to invoke the service.

System

Uses the following standard system attributes without the need for any additional configuration:

Current DateTime

This returns the current system datetime according to the data type defined in the attribute’s value settings.

Current DateTime reflects local time for your organization’s geographic region, which might differ from the user’s geographic region. To determine local time for the user’s geographic region:

Add an attribute that retrieves the user’s timezone.
Add an attribute for the current date-time that uses the Current DateTime system resolver.
Add an attribute for local date-time with a Spring Expression Language (SpEL) value processor that uses the toDateTimeInTimezone function to transform the current date-time. Learn more about this function in Date and time library.

Learn more in Example: Determining a user’s local time.

Null

This returns no value. For example, you can use Null to compare the value of an attribute to an empty string. To check against a null value, create an attribute with a System resolver and a value of Null.

Conditional resolvers

Resolvers can have conditional logic that invokes the resolver only under defined conditions. As with other conditions in PingOne Authorize, you can add comparisons or named conditions, combine multiple conditions using All, Any, or None, and add subgroups.

Learn how to add conditions to resolvers in Adding an authorization attribute.

In the following example of a conditional resolver, the game player’s email address is resolved only when the User is over 18 attribute has a value of true.

Screen capture showing an attribute resolver with a condition that resolves the game player’s email address only when the user is over 18.

Value processing for a resolver

Resolvers can have value processors that extract details and modify data when the attribute value is being resolved. As with other processors, value processors for resolvers are processed in order, with each processor receiving the output of the previous processor.

Learn how to add processors to resolvers in Adding processors to an attribute.

Example: Removing an account prefix

Consider an account ID that has a standard prefix that you want to remove. In this example, a condition and a processor work together to identify and remove the prefix. A second resolver with no processing resolves account IDs that don’t have the prefix.

Screen capture showing an attribute resolver with a condition that identifies Account IDs that begin with a 512 prefix and a processor that removes the prefix.

Example: Determining a user’s local time

If a user is in a different geographic region than your system, you can use the Current DateTime system resolver and a SpEL processor to determine the user’s local time.

Add an attribute that retrieves the user’s timezone.

For example, you can use a resolver and a processor to extract the Timezone property from the built-in PingOne User attribute, if the timezone is specified in the user’s PingOne user profile.
Add an attribute for the current date-time that uses the Current DateTime system resolver.

Make sure the attribute’s value setting type is Zoned Date Time.
Add an attribute for local date-time with a SpEL value processor that uses the toDateTimeInTimezone function to transform the current date-time.

Learn more about the toDateTimeInTimezone function in Date and time library.

The following attribute resolves against the Current DateTime attribute, then uses a SpEL processor to convert the time to the user’s local time with the following SpEL expression. The expression includes the timezone attribute that you added in step 1.
```
#datetime.toDateTimeInTimezone(#this.value, {{PingOne.User.timezone}}, 'yyyy-MM-dd HH:mm:ss')
```

Example: Adding processors directly to resolvers

Adding value processors directly to resolvers, rather than to the attribute itself, can be useful when pulling data from distinct sources that require different formatting.

For example, consider a bank that wants to pull in user information either from a modern system or a legacy system to authorize transactions. These systems are represented by the Account Details System and Legacy Account Details System HTTP services, respectively. With the following resolver configuration, the decision service calls to the Account Details System service if the user ID is above 10000 (indicating a new user), or to the Legacy Account Details System service if the user ID is less than or equal to 10000 (indicating a legacy user):

Screen capture of the Account Details resolver with a condition comparing the Request.User ID attribute to 10000, a Service resolver type calling to the Account Details System, and a final value processor

Screen capture of the Legacy Account Details resolver with a condition comparing the Request.User ID attribute to 10000, a Service resolver type calling to the Legacy Account Details System, and a final value processor

Data collected from the Account Details System service is formatted as JSON and requires a JSON Path processor defined on the Account Details resolver to extract a new user’s total balance:

Screen capture of the Extract total balance JSON processor defined on the Account Details resolver, with a JSON Path processor and value type of Number

Data collected from the Legacy Account Details System service is formatted as XML and requires an X Path processor defined on the Legacy Account Details resolver to extract a legacy user’s total balance:

Screen capture of the Extract total balance XML processor defined on the Legacy Account Details resolver, with an X Path processor and value type of Number

After the decision service pulls in user data from either service, common value processing might be required regardless of where the data comes from. For example, suppose the bank has a 500 USD minimum for an active account and anything above that is available for transfers. The following SpEL processor subtracts 500 from the result of resolver processing to obtain the user’s available balance for transfers:

Screen capture of the Obtain User’s Available Balance for Transfers value processor defined on the User.Available Balance attribute, with a SpEL processor for enforcing a 500 USD account minimum and a value type of Number