PingAuthorize

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.

PingAuthorize resolves an attribute when the attribute 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.

Resolver types

You can use the following types of resolvers:

Resolver type Description

Request

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.

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.

Service

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

Attribute

Resolves an attribute form 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 parent, you can click the Add Parent Resolver button to resolve the child attribute against its parent.

System

Use standard system attributes without the need for any additional configuration:

CurrentDateTime

This returns the current system datetime according to the type defined for the attribute.

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.

Configuration Key

The policy engine can resolve attribute values using policy configuration keys.

When using external PDP mode, you can declare local, file-based trust stores and key stores by providing an options file during setup. Learn more in Specifying custom configuration with an options file.

When using embedded PDP mode, you do this by creating Policy Configuration Keys in the Policy Decision Service. Learn more in Use policies in a production environment.

Conditional resolvers

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

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.

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.

If you expect responses from different resolved sources to vary, you can add a processor to the resolvers to normalize the output. In this example, the attribute’s value can come from one of the following resolvers:

  • A service named GET User Profile

    With this resolver, if the Cache is Valid attribute is false, the resolver calls the GET User Profile service and uses a JSON Path processor to extract the key from the profile JSON.

  • An attribute named Key

    In the second resolver, the attribute value comes from the Key attribute, and the value requires no processing.

The following image shows the resolvers. The resolvers apply in the order shown.

Screen capture of two resolvers. The first is a service with a condition and a post-resolution value process that outputs a value. The second is an attribute that captures and stores a value without conditions or processing.

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 defined with a condition holding if Request.User ID is greater than 10000, a resolver type of Service, and an Extract Total Balance JSON value processor
Screen capture of the Legacy Account Details resolver defined with a condition holding if Request.User ID is less than or equal to 10000, a resolver type of Service, and an Extract Total Balance XML 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 value processor, with a processor type of JSON Path and a path value of $.balance

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 value processor, with a processor type of X Path and an X Path value of /legacy/xyz/balance

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 processor, with a processor type of SpEL and a processor value of #this.balance - 500