It’s time to put the previous steps together into a policy that addresses your business requirements. So far, you’ve defined an API operation that matches API requests used to start a new game, and you’ve created attributes in the Trust Framework for the authenticated user’s email address and the invitee list of other game players. Now, you’ll create and test a policy that compares these three components to authorize the specific conditions under which a user can start a game.

Your business requirements:

  • A user from a generic domain cannot invite others to play with them.
  • A user from a generic domain can play the game alone, to see how it works.
  • A user from a non-generic domain can play with or without inviting other players.
  1. Add a policy that targets the API used when users start a new game:
    1. In PingOne, go to Authorize > API Services and click Meme Game.
    2. Click the Operations tab, expand the Start a new game operation, and copy the ID to a convenient location. You’ll use it in your policy and for policy testing.
    3. Go to Authorize > Policies.
    4. Select the root policy set Policies, then click the + icon and select Add Policy.
    5. For the policy Name, enter Users starting a new game.
      Screen capture of the policy Details tab showing the policy name.
    6. In the Applies When section, click + Comparison.
    7. In Select an attribute, select PingOne > API Access Management > Operation > ID.
    8. For the comparator, select Equals.
    9. For the constant, enter the operation ID that you copied in step 1b.
      Screen capture of the Applies When condition showing the PingOne.API Access Management.Operation.ID equal to the ID copied earlier.
  2. For the Combining Algorithm, select Unless one decision is permit, the decision will be deny.

    This ensures that only the specific combinations of attributes that the policy checks will be allowed to start a game. All other combinations will be denied.

    Next, add rules to check whether the user’s email address is from a generic domain.

    Note:

    To simplify this tutorial, you'll assert that the generic domain is example.com. In a real use case, you would use Authorization services in the Trust Framework to periodically obtain a current list of generic email domains.

  3. Add a rule that permits users from non-generic domains:
    1. Click + Add Rule.
    2. For the rule Name, enter Permit users from trusted domains.
    3. Click the hamburger menu next to the Name field and select Add "Applies When".
    4. In the Applies When section, click + Comparison.
    5. In Select an Attribute, select Game player email address (this is an attribute you created earlier).
    6. For the comparator, select Does Not End With.
    7. For the constant, enter @example.com.
      Screen capture of the Permit users from trusted domains rule showing the email domain comparison.
  4. Add a rule that permits users from generic domains, but only if they play alone:
    1. Click + Add Rule.
    2. For the rule Name, enter Permit users from generic domains to play alone.
    3. Click the hamburger menu next to the Name field and select Add "Applies When".
    4. In the Applies When section, click + Comparison.
    5. In Select an Attribute, select Game player email address.
    6. For the comparator, select Ends With.
    7. For the constant, enter @example.com.
    8. To add another comparison, click + Comparison.
    9. In Select an attribute, select New game invitee list (this is an attribute you created earlier).
    10. For the comparator, use the default Equals.
    11. For the constant, enter open and closed square brackets to signify an empty list with no invitees, [].
      Screen capture of the Permit users from generic domains rule showing both comparisons.
    12. Click Save changes.

      Next, you'll test the policy using testing features in Policies. The Testing Scenario defines a decision request and optional attribute and service overrides to serve as input for a test. Overrides let you test combinations of attributes without having to concern yourself with how the attributes are resolved at runtime. For example, you can test different values for the invitee list without having to form a properly formatted API request body.

  5. Test the policy for the four combinations of users and invitees:
    1. Click the Test tab.
    2. In Overrides, for Attributes, select PingOne > API Access Management > Operation > ID and enter the same operation ID that you copied in step 1b.
    3. For the next attribute, select Game player email address and enter the value user@example.com.
    4. For the last attribute, select New game invitee list and enter the value friend@example.com.
      Screen capture of the Testing Scenario tab showing the attributes being tested.
    5. Click Execute.

      Because neither rule was true, the policy resulted in a deny decision. This is the expected result because a user from a generic domain cannot invite others to their game. You can examine additional details for test results on the other tabs.

      Screen capture of the Test Results tab showing the visualization of the deny decision.
    6. Repeat the test using different combinations of Game player email address and New game invitee list.
      All other combinations should result in permit decisions. For example, change the Game player email address to user@google.com and the test results in a permit decision, because the email address no longer has a generic domain.
      Screen capture of the Test Results tab showing the visualization of the permit decision.

Your policy codifies requirements for the conditions under which a user can start a new game using rules that compare the user’s email address to the invitee list of other game players.

Next, you’ll test the end-to-end use case for starting new games by using Postman to simulate API requests from the game application.