PingAuthorize

Testing Trust Framework elements

Test 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 parsing 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 engine 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 processors.

    The decision engine’s conversion of request parameters from string 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 before runtime whether such processing produces the desired outcome.

  • 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 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. In the Domain list, select any domains you want to include as request parameters.

    2. In the Service list, select any services you want to include as request parameters.

    3. In the Identity Provider list, select any identity providers (IdPs) you want to include as request parameters.

    4. In the Action list, select any actions you want to include as request parameters.

    5. 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 JSON text editor.

    6. 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 engine resolves that attribute from the Overrides configuration.

      You can override any attribute’s value, regardless of its resolution or processing details.

    Example:

    The Datetime attribute defined in the following example 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 engine 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 following scenario 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 December 9, 2024 configured as input

  4. Click Execute.

    If the test scenario exceeds 50 kB in size, sample values will not be stored in the local cache after executing the test request.

    Result:

    The Output tab displays the value and type of the attribute being tested.

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

  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.

Testing repeating attributes

Repeating attributes are resolved from values in a specified collection. A repeating attribute requires a repetition source that points to a collection. Additionally, to get its values from each repetition of the collection, the repeating attribute’s resolver must be set to Current Repetition Value. When you properly configure a repeating attribute, you can test it the same way you test standard, nonrepeating attributes.

The Output tab in the test results will show results for each matching value from the collection. The results are ordered with indices that reflect the order of resolution.

Learn more about these variables in Repeating policies and attributes.