Defining field-level permissions / passing outputs in QueryPlan

[nadavami]

First off, thanks for an awesome product!

We are currently using Cerbos and the Cerbos mongoose orm adapter to create auth rules that filter our database. Is it possible to define rules in cerbos that only allow updates to certain database fields.

For example we would love to be able to do something like:

    - actions: ['create', 'find', 'update']
      effect: EFFECT_ALLOW
      roles: ['Admin']

    - actions: ['find', 'update']
      effect: EFFECT_ALLOW
      roles: ['User']
      condition:
        match:
          expr: P.id == R.id
     allowedFields: ['language']

We would manage what to do with allowedFields in our backend, but it would be very useful to be able to define extra metadata in cerbos and have it passed through. "Outputs" comes close to this, but they aren't available in the QueryPlan output and we would like to avoid making two multiple requests to cerbos if we can avoid it.

[charithe]

Hi. I am trying to understand your use case a bit better. Is it correct to say that you want to figure out the field on which find or update is being done? If so, one way to achieve that would be through prefixing your actions (e.g. language:find). Cerbos supports wildcards so the following rule would still work the same as above.

    - actions: ['*:find', '*:update']
      effect: EFFECT_ALLOW
      roles: ['User']
      condition:
        match:
          expr: P.id == R.id

[nadavami]

It would be the other way around for our use-case. We would like to use cerbos to define more fine grain rules which determine the fields that the principal is ultimately allowed to read or update.

So where P.id == R.id would filter out the relevant documents, something like allowedFields would allow us to use cerbos to define which fields in the documents we want to allow the user to update (or see).

So if our document was something like:

{ id: 123, language: "en", email: "abc@example.com", internal_value: "xyz" }

We could allow the a "User" role to read/update: ["language", "email"] but allow an admin to read/update: ["language", "email", "internal_value"].

[charithe]

Can't they be stored as variables? For example:

# user_variables.yaml
apiVersion: api.cerbos.dev/v1
exportVariables:
  name: common_variables
  definitions:
    allowedFields: '["language", "email"]'

# foo.yaml
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: default
  resource: foo
  variables:
    import:
      - common_variables
  rules:
    - actions: ['create', 'find', 'update']
      effect: EFFECT_ALLOW
      roles: ['Admin']

    - actions: ['find', 'update']
      effect: EFFECT_ALLOW
      roles: ['User']
      condition:
        match:
          all:
            of:
              - expr: P.id == R.id
              - expr: R.attr.field in V.allowedFields

[nadavami]

Unfortunately, no. Using variables would still only allow us to control access to the entire resource.

What we are hoping for is to have some extra metadata associated to a rule (and available in the QueryPlan output) that would allow us to apply extra filtering logic in our app in order to:

• Exclude fields from being included in a database update because the user is not allowed to change them
• Return a partial resource based on what the user is allowed to see

We don't need cerbos to be able to do this filtering, but having this metadata associated with a rule would allow us to keep all our authorization rules in one place.