Relations that exist by default

[nazar-kostiv-moodys]

Good time of day. Earlier this year we encountered a problem where we wanted to allow both granular and broad access to a given type.

• Granular - user can access one or multiple instances of a type
• Broad - user can access all instances of a type

We have solved it in the following manner:

type user

type admin_access
  relations
    define reader: [user]
    define can_read: reader

type feature
  relations
    define admin_access_ctx: [admin_access]
    
    define reader: [user]
    define can_read: reader or can_read from admin_access_ctx

With the above model, we can grant user:A ability to read a subset of features by creating direct relation to them. We can also grant user:B ability to read all current and future features but creating admin_access:feature -> reader -> user:B. Relationship between feature:X -> admin_access_ctx -> admin_access:feature is then provided as contextual tuple at run-time (which means this only works for check operations and not for list operations).

A useful piece of functionality would be to define a relation that exists by default for a given type. Something along the lines of

type feature
  relations
    define default admin_access_ctx: admin_access:feature

This way any feature instance that exists now (or will be added in the future) would be related to admin_access:feature. This is particularly useful when the instances of a given type are externally controlled and may appear/disapper without notice.

[rhamzeh]

Hi @nazar-kostiv-moodys - for these situation we generally recommend having a higher level type - that will simplify things for you a lot.

For example,

model
  schema 1.1

type user

type system
  relations
    define admin: [user]

type feature
  relations
    define system: [system]
    
    define reader: [user]
    define can_read: reader or admin from system

Then you can either persist the system<>feature tuple by writing one whenever a feature is created

- user: system:<a name for your system> # you probably will only have one, and that's OK
  relation: system
  object: feature:X

Or if you don't want to persist that, you can always send that as a contextual tuple when checking for access on a feature (aka is the system behind this feature).

Now when you want to assign someone as a system admin, it's as simple as adding a tuple

- user: user:jimmy
  relation: admin
  object: system:<my system name>

On check, a user will have access if they were either directly assigned or are a system admin

[nazar-kostiv-moodys]

Yep, that's exactly what we are doing. system type in your example is logically equivalent to admin_access type in ours. And for types that we control, I agree that we can store the relation feature:x -> system -> system:feature, and both check and list requests will work as expected.

However, this approach would not work for types that we don't control (we are not the authority of). In our model, we have type instances that are managed by an external provider (we have no access to their code, and they never call our openfga system). We then create relations in our system to the ids of those type instances. Below is a simplified example using system to keep our language aligned.

type user # we are the authority of all users

type system # we are the authority of system(s)
  relations
    define reader: [user]
    define can_read: reader

type client # we are NOT the authority of clients. They are created/managed/deleted externally. But we create relations to them
  relations
    define system: [system]

    define reader: [user]
    define can_read: reader or can_read from system

    define member: [user]
    define can_access: member

type feature # we are the authority of all features
  relations
    define system: [system]

    define reader: [user]
    define can_read: reader or can_read from system

    define client: [client]
    define member: [user]
    define can_access: member and can_access from client

So, for the above model, each time a feature is created, we can also create feature:x -> system -> system:feature relation. But we have no visibility over when clients are created/deleted. It is in this scenario that it would be useful to say something like:

type client 
  relations
    define default system: system:client

We have solved it by using contextual tuples (as you mentioned). Each time we want to CHECK if user:a -> can_read -> client:x, we also pass a contextual tuple client:x -> system -> system:client. This gives us the correct and expected result.

But if we want to get a list of clients user:a can_read, we would have to pass a relation between each client and system:client in context, which depending on the number of clients may be infeasible (or just computationally inefficient).

---

To summarise, my point is that relying on contextual tuples like this runs into problems when executing LIST requests.

Now, having said all of the above, I appreciate that using openfga to dictate access to a resource we don't have full (or any) control over may not be the use case for openfga. It's just a situation we found ourselves in, and I thought I'd share our experience.