PingAuthorize

Creating a policy to check consent and then permit or deny access

Using the Trust Framework attributes and services we created, we now create a policy for the meme game API to get a user’s answers. The policy permits access if consent exists and the consent status is accepted.

Steps

  1. In the Policy Editor, go to Policies in the left pane and then click Policies along the top.

    The following steps create a policy under an existing policy called meme-game policies. This existing policy is for all requests to the meme game.

  2. Select the existing meme-game policies policy.

  3. From the menu, select Add Policy.

  4. For the name, replace Untitled with Requests for a user’s answers.

  5. Click the next to Applies to.

  6. Click Add definitions and targets, or drag from Components and add the meme-game.user_answers service, which we set up in Getting a path component from the request URL. Also add the inbound-GET action.

  7. Set Combining Algorithm to Unless one decision is permit, the decision will be deny.

  8. Add a rule so that a user can access their own answers.

    1. Click Add Rule.

    2. For the name, replace Untitled with Permit a user to request their own answers.

    3. Click Comparison.

    4. From the Select an Attribute list, select Users identifier from the URL, which we also set up in Getting a path component from the request URL.

    5. In the second field, select Equals.

    6. In the third field, click the C to toggle to an A (for attribute) so that you can select the HttpRequest.AccessToken.subject attribute.

      The following image shows this configuration.

      Screen capture that shows the rule to permit a user to request their own answers, configured as specified

    7. Click Save changes.

  9. Test the rule.

    The following image shows a test with Postman making a request to the user.0 answers as user.0. The response shows the rule works.

    Screen capture of request to /meme-game/api/v1/users/user.0/answers by user.0

    If we try again with user.1, the request is denied. Even though user.1 does have a consent record in our consent store, the policy does not do anything with that consent record. We need another rule to look at the consent record and get the status from that record.

  10. Add a rule to get status from a consent record.

    1. Click Add Rule.

    2. For the name, replace Untitled with Permit if resource owner gave consent to share answers.

    3. Click Comparison.

    4. From the Select an Attribute list, select Sharing consent status, which we set up in Getting consent status from the consent record.

    5. In the second field, select Equals.

    6. In the third field, type accepted.

      This value is the status to check against.

      The following image shows this rule.

      Screen capture that shows the rule to permit if the resource owner gave consent to share answers, configured as specified

    7. Click Save changes.

  11. Test the policy with both rules in place now.

    A request to the user.0 answers as user.1 should now work.

    However, a request to the user.0 answers as a user without a consent record, say user.2, is denied.

    The user.2 request is denied because of the combining algorithm, Unless one decision is permit, the decision will be deny. When the policy engine evaluates the policy rules, the Permit a user to request their own answers rule does not produce a permit because user.2 is not requesting their own answers. The Permit if resource owner gave consent to share answers rule uses the Sharing consent status attribute. Because user.0 does not have a consent record for user.2, there is no consent status and the policy engine cannot evaluate the rule. So this rule also does not produce a permit. Thus, the combining algorithm produces a deny for the user.2 request.

    If user.0 revokes the consent given to user.1, the status in the consent record becomes revoked. The rule no longer applies, so user.1 requests are then denied.