Authorization Data for Attributes: Facts or Context Facts?
In this section you will:
- Write facts for toggle and multiple state attributes
- Learn what data is best for storing in Oso Cloud or sending as context facts
For this tutorial we designed an example application where the attribute data has two key properties:
- It contains information that would appear on user interfaces: account status (active/inactive) and rewards status (rewards, bronze, ...).
- The state of the attribute changes based on app usage and user interactions (not backend admin maintenance).
Because these attributes need to be presented to users within the app, it makes sense for the application to store the data itself. However, as you observed in the previous section, the application logic, makes use of these attributes in all of its permission rules. Oso Cloud needs this data to make accurate authorization decisions. Some potential questions typically arise with this scenario:
- Are two copies of the data needed — one for the app and one for Oso Cloud?
- If two copies of the data are needed, how should they be kept in sync?
Sending these kinds of attribute data as context facts is generally the preferred approach. This is because context facts are only evaluated at the time an authorization check is made (no data is permanently stored). Therefore, when an attribute changes, you won't need to update Oso Cloud every time to keep your data properly synced. It is not the case that attribute data must be sent as context facts. Instead, the decision is being made based on the fact that the attributes used in this example also need to be stored by the app.
Authorization Data Paths (Only the components relevant to the data path are highlighted): > 1. Attribute data is stored in app resources and databases. > 1. User and resource data such as roles, permissions, and relationships are sent to Oso Cloud and stored there. > 1. Attribute data is pulled from the application and used during authorization checks as needed.
Role Data as Facts Tell Oso Cloud that:
- paula owns the card account paulas-account-123.
oso-cloud tell has_role User:paula owner CardAccount:paulas-account-123
- kristian is a member on the card account paulas-account-123.
oso-cloud tell has_role User:kristian member CardAccount:paulas-account-123
- paula has the credit card paulas-card.
oso-cloud tell has_role User:paula card_holder CreditCard:paulas-card
- kristian has the credit card kristians-card.
oso-cloud tell has_role User:kristian card_holder CreditCard:kristians-card
- paula is a member of the rewards program rewards-r-us.
oso-cloud tell has_role User:paula member RewardsProgram:rewards-r-us
- kristian is a member of the rewards program rewards-r-us.
oso-cloud tell has_role User:kristian member RewardsProgram:rewards-r-us
Relationship Data as Facts Tell Oso Cloud that:
- paulas-card is under the card account: paulas-account-123.
oso-cloud tell has_relation CreditCard:paulas-card parent_account CardAccount:paulas-account-123
- kristians-card is under the card account: paulas-account-123.
oso-cloud tell has_relation CreditCard:kristians-card parent_account CardAccount:paulas-account-123
In the next section you'll apply context facts to your authorization checks. For now, review the information you'll use to generate more informed authorization decisions.
|Application Data Needed
|Authorization Check Use Case
|CardAccount and Account Status
|Required for Check API calls made on all CardAccount, CreditCard, and RewardsProgram resource permissions.
|CreditCard and Card Status
|Required for Check API calls made on certain CreditCard permissions
|Rewards Member, CardAccount, and Rewards Status
|Required for Check API calls made on certain RewardProgram permissions
NOTE: You can always consult your policy to determine what facts are needed to support a given rule.
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.