Ask HN: Does OpenFGA Support Multi-Level Indirect Relationship Evaluation?

1 points by idlefeature 1 year ago | 1 comment

I've been evaluating OpenFGA for relationship-based access control (ReBAC) and I believe I've identified a significant limitation: *OpenFGA does not support multi-level indirect relationship evaluation beyond one level of indirection*.

## Example Scenario: Management Chain Authorization

Imagine a scenario where permissions should propagate up a management chain:

1. *Object A* is *owned* by *User B*. 2. *User B* is *managed* by *User C*. 3. *User C* is *managed* by *User D*.

### What OpenFGA Can Handle

If I define an authorization rule like:

``` allow manager from owner ```

Then *User C* inherits access to *Object A* because:

> "User C manages User B, who owns Object A."

### What OpenFGA Cannot Handle

OpenFGA does not allow further relationship chaining:

> "User D should be able to view Object A, because User D manages User C, who manages User B, who owns Object A."

This limitation exists because OpenFGA does not allow the `from` clause (also called a tupleset) to reference another relation. The documentation explicitly states that OpenFGA will *throw an error* if an authorization model attempts this kind of multi-level evaluation:

- ["Referencing Relations on Related Objects"](https://openfga.dev/docs/configuration-language#referencing-relations-on-related-objects) - ["Modeling Parent-Child Relationships"](https://openfga.dev/docs/modeling/parent-child#05-check-if-bob-is-an-editor-of-documentmeeting_notesdoc)

## My Questions for HN:

1. *Have I correctly understood this limitation of OpenFGA?* 2. *Are there any authorization frameworks/tools that do support recursive evaluation of indirect relationships?*

Would love to hear if anyone has encountered and solved this issue, or if OpenFGA's approach is just a fundamental design tradeoff in this space. Thanks!

rhamzeh 1 year ago |

Hey @idlefeature

Member of the OpenFGA team here.

TLDR: OpenFGA supports recursive nesting - you can find many examples (e.g. GDrive) of that in the sample stores repo [1] and the documentation.

For your case:

> "User C manages User B, who owns Object A."

In the model, that is represented by:

```

model

  schema 1.1

type user

  relations

    define manager: [user]

type folder

  relations

    define owner: [user]

```

So:

- Object A is owned by User B.

- User B is managed by User C.

- User C is managed by User D.

These can all be expressed as tuples:

```

- user: user:D, relation: manager, object: user:C

- user: user:C, relation: manager, object: user:B

- user: user:B, relation: owner, object: folder:A

```

> "User D should be able to view Object A, because User D manages User C, who manages User B, who owns Object A."

The model would become

``` model

  schema 1.1

type user

  relations

    define manager: [user]

    define managed_by: manager or managed_by from manager

type folder

  relations

    define owner: [user]

    define can_view: owner or managed_by from owner

```

Notice how on the folder, you cannot say `manager from manager from owner`, but you can model your way around it by adding the `managed_by` relation on the user.

You can play with this sample on the FGA Playground here [2] (give it any name to continue, note that this is publicly viewable/editable). Your use-case is similar to the expenses sample [3]

Another option the docs is warning you of is that in order to use a relation as the base of a `from`, it MUST be just a directly assigned type, for example the below is not allowed as owner has redirects (or manager from owner), so cannot be used as the base of a recursive from

```

type folder

  relations

    define owner: [user] or manager from owner

    define can_view: owner or manager from owner

```

but as you saw above, you can work around it with modeling slightly differently to reach the desired solution

In case it is easier for you, feel free to ask on our Discussions page or CNCF channel [4] as they render markdown a bit better than here on hn.

As for other AuthZ frameworks that support recursion, most of the Zanzibar[5][6] inspired ones (like what OpenFGA is) do, in fact it's one of the strong suits of a Zanzibar inspired approach to AuthZ.

[1] https://github.com/openfga/sample-stores/tree/main/stores

[2] https://play.fga.dev/stores/create/?id=01JNPQKC4TMHBW271V6N4...

[3] https://github.com/openfga/sample-stores/tree/main/stores/ex...

[4] https://openfga.dev/community

[5] Zanzibar is a Google paper from 2019 around how Google handles authorization for their products: https://research.google/pubs/zanzibar-googles-consistent-glo...

[6] https://zanzibar.academy/