Model Resource Fields as Resources
To implement field-level authorization, you can model each of a resource's fields as separate resources.
For alternative approaches and more context, see Field-Level Authorization.
Implementation overview
In this approach, you create an additional resource for any resource's fields. This typically involves creating new rules to express the relationship between the "parent" resource and its field resources.
With this strategy, you can apply rules to specific fields by identifying them:
You can also use the same Field
resource for all resources that have fields:
While this approach can be more complex to model, it is well integrated into
Oso's API. For example, it fits naturally into the
query
subcommand of Oso's clients (examples).
In contrast to the "fields in permissions" approach which implicitly creates resources by mentioning them in permissions, "fields as resources" explicitly creates a resource for fields.
Example
We'll model a social app with an Account
whose fields we want to apply
granular access to––specifically two rules that are simpler to model using
field-level authorization.
User role | Special case |
---|---|
community_admin | Can update other accounts' username fields, but no other fields. |
visitor | Can read accounts, but none of their fields. |
Policy
To accomplish the conditions stated above, we'll include:
-
A
Field
resource: -
allow_field
rules to correlateAccount
s and theirField
s, e.g.
This policy shows all of the pieces working together.
Limit the set of valid Field identifiers
The policy defined has_relation
between some named Field
resources and all
Account
s:
This provides the flexibility to:
- Allow actions on any
Field
using wildcard matches (_
): - Require the field have a defined relation:
However, not all policies will need to define a relation between explicit field identifiers and their parent resources.
Client
By modeling fields as resources
and introducing a new allow_field
rule,
we can use the Oso client query
subcommand to determine users' field-level
authorization for accounts.
To determine charlie
's permissions on alice
's Account
:
bob
can read any (_
) field from the alice
account, but can only update
the username
field.
For his own account, bob
can update all fields:
The redundant update
permission comes from the fact that a community_admin
can edit their own username using their community_admin
privileges in addition
to the update
permissions granted to the account owner.