Authorization Enforcement with Attributes as Context Facts

In this section you'll:

Use context facts to better support your authorization checks
Examine how authorization checks can be used to control app views
Make various authorization checks against your policy and authorization data

So far you've modeled a credit card application, stored some role and relationship facts in Oso Cloud, and reviewed the information you'll need to provide as context facts for each type of authorization check you'll make. Now it's time to see it all in action and test out the authorization checks you can use for enforcement.

Controlling Client-Side App Views

Account Owner View

Account Member View

CardAccount Owner View(left image): Paula, the account owner has access to view and modify accounts, as well as perform actions on credit cards such as adding a new card.
> CardAccount Member View (right image): Kristian, the account member does not have the account view. They also do not have the ability to add new cards. However, both account owners and member can access rewards tied to the account.

There are two account views shown in the images above: account owner and member views. The policy used in this tutorial defines resources that have role based permissions. For each resource component in your app you can use the Check API list command to find all the resources a user is allowed to view.

*NOTE: We added a view permission to each resource in the policy which makes this type of check more convenient.*

Action Items

Use the example application data from the previous section to construct context facts that support your policy.

Use the context facts to complete the Check API calls discussed in each section below.

Check if the user paula should have any CardAccount resources displayed in the app view.
```
oso-cloud list User:paula view \
        -c "is_active CardAccount:paulas-account-123" \
    -c "is_active CreditCard:paulas-card"
```
Returned Values
Expected result: [paulas-account-123] (paula is a CardAccount owner).
Check if the user paula should have any CreditCard resources displayed in the app view.
```
oso-cloud list User:paula view \
        -c "is_active CardAccount:paulas-account-123" \
    -c "is_active CreditCard:paulas-card"
```
Returned Values
Expected result: [paulas-card, kristians-card] (as a CardAccount owner, paula inherits all CreditCard permissions).
Check if the user kristian should have any CardAccount resources displayed in the app view.
```
oso-cloud list User:kristian view \
        -c "is_active CardAccount:paulas-account-123" \
    -c "is_active CreditCard:paulas-card"
```
Returned Values
Expected result: None (kristian is not a CardAccount owner).
Check if the user kristian should have any RewardsProgram resources displayed in the app view.
```
oso-cloud list User:kristian view \
        -c "is_active CardAccount:paulas-account-123"
```
Returned Values
Expected result: [rewards-r-us] (kristian is a RewardsProgram member).

Controlling Field Level Access

The process of controlling the field level access is analogous to the process described above for rendering the right resources. In the app, the various RewardsProgram tiers are displayed through special fields within the resource. The same field can return different data to a user depending on what reward status they have achieved. That being the case, RewardsProgram permissions can be used to control what data is use to populate the resource fields.

RewardsProgram Resource Fields: Each diagram shows example RewardsProgram windows with text boxes representing > fields. The app retrieves and displays the appropriate content based on the user's reward status.

Within your app you can check permissions for each reward tier individually using authorize. However, using the actions command will generally be the preferred method in this case. When you make a call with the actions command it returns all the permissions a user has for a given resource. The benefit is that you'll only need to make one authorization call to Oso Cloud (instead of up to N calls). This can reduce the overall latency and bandwidth associated with populating data for your resource fields.

Check to see what rewards kristian has within the RewardsProgram "rewards-r-us".
```
oso-cloud actions User:kristian RewardsProgram:rewards-r-us \
        -c "is_active CardAccount:paulas-account-123" \
    -c "has_rewards_status CardAccount:paulas-account-123 bronze"
```
Returned Values
Expected result: [view, rewards, bronze_rewards] (kristian is a RewardsProgram member).

The application can use the returned list of permissions to determine what data should be used to populate the resource fields (see pseudo code below).

... CONST user_permissions_list = oso.actions(user, rewards_program, context_facts) rewards_program_filed_data = EMPTY; if "view" in user_permissions_list: FOR reward_permission IN ["platinum_rewards", "gold_rewards", "silver_rewards", "bronze_rewards","rewards"]: IF reward_permission IN user_permissions_list: rewards_program_filed_data = GET_REWARDS_PROGRAM_FIELD_DATA(reward_permission) BREAK; RENDER_REWARDS_PROGRAM_ELEMENT(rewards_program_filed_data) ...

Additional Resources

Authorization Enforcement: Where and What to Enforce (opens in a new tab)

Talk to an Oso Engineer

If you'd like to learn more about using Oso Cloud in your app or have any questions about this guide, connect with us on Slack. We're happy to help.

Get started with Oso Cloud →

Code Examples