Resolvers define where attributes pull information from.
An attribute can have one or more resolvers. Multiple resolvers are resolved in order until one of them produces a value. 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. You can drag collapsed resolvers to change their order. If a resolver fails to resolve successfully, processing moves on to the next resolver.
For information about adding resolvers to attributes, see 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
You can use an Attribute resolver to extract the surname. Create a
|
Constant |
Takes a constant value defined on the resolver itself. The type and value of the constant are required. Note:
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. Tip:
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. Tip:
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 out-of-the-box system attributes without the need for any additional configuration:
|
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.
For information about how to add conditions to resolvers, see 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.
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.
For more information about how to add processors to resolvers, see Adding processors to an attribute.
For example, consider an account ID that has a standard prefix that you want to remove. 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.