PingOne

Testing Trust Framework elements

Test PingOne Authorize Trust Framework elements from end-to-end with tools that show the complete processing flow.

About this task

Testing enables you to validate the type conversion of policy information points (PIP) included in decision requests and the logical behavior of conditions. Although policy testing indirectly tests your Trust Framework elements, testing each Trust Framework element individually allows you to immediately view the output of element processing without needing to parse policy test results.

Use Trust Framework testing to:

  • Verify attribute or service value settings.

    If you are testing an attribute with a value type other than String, the decision service must convert this attribute from a string provided in the request to the correct type. Testing an attribute or service allows you to verify that the formatting required for this conversion is correct.

  • Test the behavior of value processors.

    The decision service’s conversion of request parameters from strings to other data types, such as Number, might involve a chain of processors configured in the attribute definition. Testing an attribute allows you to determine whether such processing produces the desired outcome, before runtime.

  • Test the behavior of resolvers.

    If you define multiple resolvers on an attribute, you can use testing to confirm the order in which the decision service checks these resolvers for a value.

  • Test the logic of conditions.

    With testing, you can confirm that your conditional logic produces the desired outcome, before implementing that logic in your authorization policies.

Steps

  1. Go to Authorization → Trust Framework.

  2. Click the tab of the appropriate Trust Framework element type, select the element that you want to test, and then click the Test tab.

  3. Define the test scenario:

    1. Optional: To include a PingOne user ID as context in the decision request, search for a user in the PingOne User field.

      If you are testing an element that depends on the PingOne.User attribute, you must select a user to avoid a MISSING_ATTRIBUTE error.

      The selected user must be defined in the current PingOne environment.

    2. In the Attributes list, select the attribute that you want to test and any other attributes that you want to include as request parameters, and provide sample values.

      Click the angle brackets next to an attribute to display a rich JSON text editor.

    3. In the Overrides section, configure attribute and service values if you want to override those elements' default behavior.

      For example, if an attribute is defined with a request parameter resolver, and no value is specified in the test request, the decision service resolves that attribute from the Overrides configuration.

      You can also click the Import JSON button to define the test scenario with a rich text editor.

      Example:

      The Datetime attribute defined below has a value type of Zoned Date Time, resolves from a decision request parameter, and has no processors defined. Testing this attribute verifies whether the decision service can directly convert this attribute from a string.

      Screen capture of the Datetime attribute defined with a Request Parameter resolver and a value type of Zoned Date Time

      The scenario below tests the Datetime attribute with an ISO 8601-formatted string as input:

      Screen capture of a Datetime attribute testing scenario with an ISO 8601-formatted representation of June 6, 2022 configured as input

  4. Click Execute.

    Result:

    The Output tab displays the value and type of the attribute being tested, along with a Copy to clipboard button.

    Screen capture of the Output tab displaying the result of the above Datetime test

    If the element being tested is of type JSON, the Output tab also displays a rich JSON editor.

  5. Click the other tabs for additional details:

    • Request: Shows the JSON request sent to the decision, allowing you to confirm the expected information was sent.

    • Response: Shows the complete, high-verbosity response for the decision, including expanded errors and other helpful information.

      This tab can be helpful when troubleshooting value processing failures.

    • Attributes: Shows details about the attributes used in the decision.

    • Services: Shows details about the services used in the decision.

Examples

You can test additional Trust Framework elements with multiple value processors or resolvers.

Testing an attribute with multiple resolvers

The following example extends the Datetime attribute by adding a Constant resolver. The expected behavior is that the decision service first checks the decision request for a Datetime parameter to resolve the attribute from, and if there is no such parameter, the decision service resolves the attribute from a specified constant value.

Screen capture of a Request Parameter and a Constant resolver defined on the Datetime attribute, in that order.

After executing the testing scenario without any parameters defined, you can check the attributes.Datetime.resolvedBy field under the Response tab to verify the order in which the decision service checks resolvers for attribute values.

Screen capture of the resolvedBy array in the attributes field displayed by the Response tab, first showing failure in resolving from the request and then success in resolving from a constant

Testing an attribute with multiple processors

The following example defines a User.Age attribute of type Number, which uses a series of processors to calculate a user’s age:

Screen capture of the Age attribute definition with a Calculate Age of User value processor and value type of Number

The primary value processor, Calculate Age of User, defines three subordinate PingOne Expression Language processors that each use the Datetime attribute from above and a new User.Date of Birth attribute. The User.Date of Birth attribute is not connected to the built-in PingOne.User attribute.

  • Calculate year:

    #datetime.getYear({{Datetime}}) - #datetime.getYear({{User.Date of Birth}})

  • Calculate month:

    #this.value - (#datetime.getMonth({{Datetime}}) < #datetime.getMonth({{User.Date of Birth}}) ? 1 : 0)

  • Calculate day:

    #this.value - ((#datetime.getMonth({{Datetime}}) == #datetime.getMonth({{User.Date of Birth}})) && (#datetime.getDayOfMonth({{Datetime}}) < #datetime.getDayOfMonth({{User.Date of Birth}})) ? 1 : 0)
    Screen capture of the Calculate year, Calculate month, and Calculate day SpEL processors defined for the Calculate Age of User value processor

The decision service resolves the User.Date of Birth attribute from the User attribute and uses the following JSON Path and SpEL processors:

Screen capture of the User.Date of Birth attribute with a JSON Path processor to extract the dob value, a SpEL processor to get only the date, and another SpEL processor to append the time

The following testing scenario verifies that the above chain of processing works as intended, where a user’s birthday is February 11, 2000:

Screen capture of an Age attribute testing scenario with an example JSON User object with a birthday of February 11, 2000

The test produces the following output as expected. Click the Response tab to view detailed processing steps.

Screen capture of the test result Output tab displaying 24