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, you have a built-in attribute for the authenticated user’s email address, and you’ve created an attribute in the Trust Framework for 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 can play the game alone, to see how it works.
  • A user from a generic domain cannot invite others to play with them.
  • 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 Authorization > API Services and click Meme Game.
    2. On the Operations tab, expand the Start a new game operation and copy the ID to a convenient location.

      You’ll use it later for policy testing.

    3. Go to Authorization > Policies.
    4. In the API Access Management policy set, select the Inbound Request > Custom policy set for the Start a new game operation.
      Screen capture showing the API Access Management policy tree expanded to the Custom policy set for Start a new game Inbound Requests.

      This is where you add custom policies that target inbound requests for the API operation. The Custom policy set is owned by its parent operation, so there are restrictions around updating, moving, or deleting it, but you can add your own child policies.

    5. Click the + icon and select Add Policy.
    6. For the policy Name, enter Users starting a new game.
      Screen capture of the policy Details tab showing the policy name.
  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 PingOne.User.email (this is a built-in PingOne user attribute).
    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 PingOne.User.email.
    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 PingOne.User.email 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 evaluated as 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 PingOne.User.email and New game invitee list.

      All other combinations should result in permit decisions. For example, change PingOne.User.email to user@google.com and the test will result 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.

      Now that you’ve tested your policy, it’s ready to publish. You’ll deploy the Meme Game API service to publish the latest version of the policy tree.

  6. Go to Authorization > API Services and select the Meme Game API service.
  7. Click Deploy.

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

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