Handling multiple ABAC conditions

[jeremywestwood]

We are investigating using OpenFGA as part of our authorization layer but am running into a scenario which I feel like may have a better solution to what I am doing currently. OpenFGA is doing the right thing with the tuples provided (so its not a bug) but I'm looking for suggestions of how I could implement this kind of check in a better way to avoid the pitfalls or workarounds that I'm having to use.

Our model setup (very simplified and changed to fit a google doc type structure) looks like this (full test file: test-conditions.fga.yaml.txt):

Model

model: |
  model
    schema 1.1

    type user

    type role
      relations
        define member: [user]


    type folder
      relations
        define view_type_check: [role#member with type_check]
        define view_status_check: [role#member with status_check]
        define viewer: view_type_check and view_status_check


    condition type_check(allowed_type: string, requested_type: string) {
      allowed_type == requested_type
    }

    condition status_check(allowed_status: string, requested_status: string) {
      allowed_status == requested_status
    }

The key piece is that we have two ABAC checks which need to be done, which are linked together on a role (as in they should be checked together).

E.g. Role 1 is allowed to view Documents that are in the Editing status in a particular folder
Role 2 is allowed to view Presentations that are in the Approved status in a particular folder.
A user can have multiple roles

The issue comes in in that if you add both roles at the same time to the user, the condition checks are handled separately and so you get allowed access when you wouldn't expect it. (e.g. a user with both roles can view Presentations in Editing and Documents in Approved even though each role only gives half of the access)

Example Tuples

tuples:
    # setup user 1, a member of role 1 which allows viewing of records of type Document and status Editing"
    - user: user:USER_1
      object: "role:DocumentViewer"
      relation: member
    - user: role:DocumentViewer#member
      object: "folder:folder_1"
      relation: view_type_check
      condition:
        name: type_check
        context:
          allowed_type: "Document"
    - user: role:DocumentViewer#member
      object: "folder:folder_1"
      relation: view_status_check
      condition:
        name: status_check
        context:
          allowed_status: "Editing"

    # setup user 2, a member of role 1
    # and role 2 which allows viewing of records of type Presentation and status Approved"
    - user: user:USER_2
      object: "role:DocumentViewer"
      relation: member
    - user: user:USER_2
      object: "role:PresentationViewer"
      relation: member
    - user: role:PresentationViewer#member
      object: "folder:folder_1"
      relation: view_type_check
      condition:
        name: type_check
        context:
          allowed_type: "Presentation"
    - user: role:PresentationViewer#member
      object: "folder:folder_1"
      relation: view_status_check
      condition:
        name: status_check
        context:
          allowed_status: "Approved"

Tests
You can see it in these test cases:

The first one passes correctly (by returning false), but ideally we would like the second one to also return false but it returns true.

tests:
  # this test fails, correctly
  - name: "Test User 1 with SINGLE correct type and status"
    check:
      - user: user:USER_1
        object: "folder:folder_1"
        context:
          requested_type: "Presentation"
          requested_status: "Editing"
        assertions:
          viewer: false

  # this test fails (as it allows User 2 to view the Presentation in editing) but ideally it would pass
  - name: "Test User 2 with Presentation and Editing"
    check:
      - user: user:USER_2
        object: "folder:folder_1"
        context:
          requested_type: "Presentation"
          requested_status: "Editing"
        assertions:
          viewer: false

Workarounds

1. Currently the workaround I have implemented is to split out all the role checks into contextual tuples and then do multiple checks for each user to only check a single role at a time, but this results in some fairly complex code on the application side and I can't store tuples in OpenFGA to take more advantage of cache etc.
2. We could combine the two checks into a single condition check, however the actual checks contain lists of items so there is a concern of hitting the CEL limits, and also its possible we will need to add additional checks which will then make the check too complex.

Questions
Is there any other way to model this kind of requirement that I'm not thinking off?
Ideally it would be nice to be able to write the relation as: define viewer: [role#member with status_check and type_check] and then define the tuple with multiple conditions, but I realise that will take additional development.

    - user: role:PresentationViewer#member
      object: "folder:folder_1"
      relation: view_type_check
      conditions:
        - name: type_check
          context:
            allowed_type: "Presentation"
        - name: status_check
          context:
             allowed_status: "Approved"

Apologies for the long post and thanks for any input!

[aaguiarz]

Hi @jeremywestwood

Please take a look at this example https://github.com/openfga/sample-stores/blob/main/stores/groups-resource-attributes/store.fga.yaml. The idea is that you specify attributes in a single condition.

Let me know if that helps,

[jeremywestwood]

@aaguiarz Thanks, that example is what helped me originally setting this up.

The combining the attributes in a single condition was one option that I looked at, the downside is that it makes the individual conditions more complex (and therefore you risk hitting the CEL limits) as you add more conditions and, if you want to have a set of checks that differ depending on the relation (e.g. in my example a create relation would only need the type check, not the status check) you would need to potentially create many different checks with all the different combinations of attributes.

But I'll consider whether its likely that we will need many different conditions in the long term and the risks of the CEL limit with the current types and statuses.