Skip to main content

Policy Builder Examples

This section uses Policy Builder examples to show you how Policy Builder is used. To follow these examples, enable the Policy Builder feature. The example uses a new Entitlements System, using the default sample data and the Entitlements Playground sample application.

note

The examples in the following sections build upon previous examples and assume that all examples are completed. The examples are not intended as standalone tasks. Use the same Entitlements System for all example tasks.

Using the Entitlements System Playground​

The following task uses the Entitlements System Playground.

  1. Create a new Entitlements System.
  2. Select System > Settings > Install > Entitlements Playground.
  3. Follow the instructions to Launch the Entitlements Playground.
  4. In the Entitlements Playground, verify the requests are Denied.
  5. Navigate to System > Decisions and verify that all decisions are Denied. It takes a minute or so for decisions to appear.

You are ready to test the following examples.

Implementing Role-Based Access Control​

In this example, we will implement a Role-Based Access Control (RBAC) policy using Styra’s built-in snippets.

  1. In your Entitlements System, go to Policy > rules.rego.
  2. In the authoring toolbar, click Add rule.
  3. Select RBAC: Role explicitly allows subject access to resource.

Previewing the Rule​

You have created a policy implementing RBAC. However, the added rule is set in Monitor mode by default, meaning it is not enforced. Any data the rule returns will be included in the final decision data, but access will be denied. Verify this by previewing the rule using an input document.

  1. In your Entitlements System, go to Policy > rules.rego.
  2. In the toolbar, click the Preview icon.
  3. Toggle Coverage to on and Exclude Stacks to off.
  4. Click Preview, and in the Input pane, add the following: 
    {
      "subject": "alice",
      "resource": "/cars",
      "action": "GET"
    }
  5. Click Preview.

The outcome in the Policy Dashboard to the right of our rule should say Denied. Click the Arrow next to the outcome line to expand a description of the outcome.

In the Output panel, you can see more detailed decision information, including the data the rule returned under the key monitored. It should be similar to the following:

"monitored": [
  {
    "allowed": true,
    "entz": [],
    "message": "Access is allowed by roles car-readers"
  }
],

To start enforcing the rule:

  1. Go to the Rule card and click Monitor.
  2. Click Enforce.
  3. Click Preview.

You should now see a tag on the Rule card that says Allowed, and the outcome on the policy dashboard should also say Allowed. If you expand the details, you should see an explanation of why the request was allowed.

To finalize the policy and use it with the Entitlements Playground:

  1. From the toolbar, click Publish.
  2. Click Publish changes.
  3. In the Entitlements Playground, verify that the relevant requests are allowed. It takes a minute or so to update.

You have now successfully implemented a policy that enforces access by using RBAC.

Combining Conditions for Fine-Grained Authorization​

Implementing RBAC with Styra DAS Entitlements is easy and will cover many typical access control scenarios. You can also make more fine-grained access checks, for example, limiting access on certain days.

In this example, we will combine the RBAC condition with Attribute Based Access Control (ABAC). Attributes can be associated with a user, or other contextual information such as the day of the week, used in the following example.

  1. In your Entitlements System, go to Policy > rules.rego.
  2. In the Rule card where a rule was previously created, click the Plus icon.
  3. Click Add condition.
  4. Select Calendar: Match a Day of the week.
  5. In the open panel, type the current day of the week into the days parameter input field.
  6. Click Save.

The Rule card will now be updated to include the new condition. Preview the policy to make sure that it is still Allowed. You have now modified the Rule to combine the RBAC condition with an ABAC condition that checks that the current weekday matches an expected value and only then allows access.

To verify that this does deny access on other days, modify the condition to change the expected days:

  1. Hover over the current weekday condition.
  2. Click the Pen icon or double-click on the condition summary.
  3. Change the days parameter input so it does not include the current weekday, either by leaving it empty or setting a different day than the current weekday. For example, if today is Friday, change the days parameter to "tuesday".
  4. Click Save.

Preview the policy using the same input as before.

The outcome should now be Denied.

Before publishing this policy, change the condition only to allow access on weekdays, not weekends.

  1. Open the current weekday condition panel.
  2. Change the days parameter input to only include weekdays, for example "monday", "tuesday", "wednesday", "thursday", and "friday".
  3. Click Save.
  4. Click Publish in the toolbar to apply the changes to your policy.
  5. Navigate to the Entitlements Playground and verify that access is allowed if the current day of the week is a weekday, and denied if it is the weekend.

You have successfully modified the policy to combine RBAC with ABAC.

Combining Multiple Rules​

In the previous example, RBAC was combined with ABAC by checking for an environmental attribute – the current day of the week.

In this example, you will modify the policy to add an additional rule, combining RBAC and ABAC. However, instead of checking for an environmental attribute, you will check for a user attribute.

  1. In your Entitlements System, go to Policy > rules.rego.
  2. Click Add rule to create a new Rule using RBAC: Role explicitly allows subject access to resource condition.
  3. The new Rule is added to the top of the list, and is in Monitor mode by default.
  4. Click the Plus icon to add a condition to the new Rule.
  5. Click Add condition and select ABAC: User has attributes.
  6. Set the Key input to "team".
  7. Set the Value input to "SLT".
  8. Click Save.
  9. Change the status of the rule to Enforce.

The new Rule checks if the user has a role that allows access and also inspects the user’s attributes to see if there’s a key called team that has the value SLT.

In the sample dataset, the user alice does not have this attribute, so when you Preview this rule using the same input document as before the outcome should be Allowed, but the new Rule that was added should not show a tag. The icons next to the conditions shouldn't be all checkmarks either.

Use the following steps to inspect what happened.

  1. Hover over the Checkmark icon beside the first condition in the new Rule card, it should specify Allowed.
  2. Hover over the Stop icon beside the second condition, it should specify Denied. Hover over the Indeterminate icon beside the rule decision, it should specify Not evaluated.

This indicates the first condition succeeded but the second failed, and because the second failed the rule decision was never evaluated. That means this rule did not explicitly deny access, but it also did not allow access, so a decision was not made.

If this were the only rule in the policy, the outcome would have been Denied because that is how the Entitlements System works. If no rule explicitly allows access, then the default decision is to deny access.

Use the following task to test the outcome.

  1. In the bottom Rule that was created, change the status to Ignore to cause the rule to not contribute to the decision at all.
  2. Preview the Policy using the previous input document.
  3. Verify that the outcome is now Denied, and expand the details to see an explanation of why.
  4. Change the subject key in the input document to have the value "bob" instead of "alice".
  5. Verify that the outcome is Allowed. This is because bob has the team attribute set to SLT.
  6. Publish the policy, leaving the old Rule ignored and the new rule enforced.
  7. Open the Entitlements Playground.
  8. Verify that the requests with alice as the subject are denied.
  9. Verify that the requests with bob as the subject are allowed.

You have modified the Policy to add a rule combining RBAC and ABAC, using a user attribute instead of an environmental one in the check.

To give alice her access back (on weekdays), change the status of the old Rule back to Enforce and Publish the Policy. In the Entitlements Playground, if it is a weekday, alice and bob should now be allowed access, but if it is the weekend, only bob will be allowed access.

Conclusion​

These examples show how to combine conditions to create fine-grained authorization policies and combine rules to create complex authorization scenarios where some users are allowed access while others are not, depending on data attributes or environmental factors.

As shown in these examples, using the Policy Builder makes it simple to implement complex scenarios combining RBAC and ABAC without having to author policies using Rego.

Use Policy Builder to experiment further with other policies (for example, adding or removing conditions, rules, or modifying parameters) to understand how the Policy Builder works in the Entitlements System.