Adding a policy for the API operation - PingOne - PingOne Cloud Platform - PingOne Authorize

Adding a policy for the API operation - PingOne - PingOne Cloud Platform - PingOne Authorize - PingOne Services

PingOne Cloud Platform

bundle

pingone

ft:publication_title

PingOne Cloud Platform

Product_Version_ce

PingOne

PingOne Cloud Platform

category

Administratorguide

ContentType

Guide

Product

Productdocumentation

p1cloudplatform

ContentType_ce

Product documentation

Guide > Administrator Guide

Guide

Learn how to add and test a custom policy in PingOne Authorize that uses API attributes.

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.

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.
  
  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.
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.
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.
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, [].
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.
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.
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.
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.
  
  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.
Go to Authorization > API Services and select the Meme Game API service.
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.