Exclusive relations

[netthier]

I want it to be possible to have relations where it is guaranteed that there only ever is a single such relationship tuple per subject.
This can be useful when implementing things like parent-child relations where one wants to guarantee that any given object only has one parent.
It is also useful in cases where some kind of state is stored for an object, such as in the entitlements example, where it is useful to ensure that an organization is only ever subscribed to a single plan.
While it is already possible to guarantee this exclusivity in the code interacting with OpenFGA, i.e. just deleting existing tuples before creating a new one, it would be very useful if such a constraint could be expressed directly in the modeling language, as manually implementing such logic can be error-prone, especially if repeated in multiple places.

[ethanjcohen]

I'd like to add some use cases to this request and really highlight the importance for our authorization problems.

First - I think this applies to many use cases. Here are some:

1. Parent child relations, as stated above. There should only ever be one parent relation.
2. Entitlements - it might not make sense for a user to be paying for two levels of service
3. Ownership - a given entity should only have a single "owner." This could be called the "creator" but could also be a more general "owner" or really any 1-to-1 relationship like the Reporter or Assigned fields in Jira.
4. Generally, any attribute that we force into a Zanzibar style schema. For example, the privacy setting on a post in your social feed. You might have a "privacy" relation that should exist only once for a given post - the relation could specify that all users can see it, or just your friends, or only your close friends. But only one of relations should exist at a time.

Second - I think solving this at the storage layer gives us the type of database constraints we'd expect from a typical SQL or NoSQL setup, where there can only be a single record for a given index value, and we can "update" that record... vs deleting the record and creating a new one. Eventual consistency is expected in a Zanzibar solution, but this constraint will help ensure the integrity of the data, in the case where the data does NOT become eventually consistent because of a bug, etc. As a developer on call, I'd prefer to find and fix the WRONG value than to see multiple values and have to clean up a more complicated state.

Third - This could make it easier to sync data and overall integrate with OpenFGA. As it stands today, when you want to change the value of an exclusive relation, you have to know what the old value is in order to delete it, but that's not always trivial. In a microservice architecture I've seen a few common event driven patterns: 1) events state that something changed, and give the entire current state of the object or 2) events state that something changed, and give the new value or 3) events state that something change, but give no details - it's up to the consumer to fetch the current state if needed. In all of these cases, the old value is not available. For OpenFGA to work, the events have to be specifically designed to include BOTH the old value and the new value. Easier said than done in some existing services. Ideally, a job that's syncing to OpenFGA wouldn't have to know the old value, and instead could just UPDATE the relation to the new value. This would greatly simplify the code on our side as we're integrating with OpenFGA.

[aaguiarz]

Hi @ethanjcohen and @netthier

Thanks for the feedback. I absolutely see the value that this would bring.

They way I see it is that these restrictions in the model are not really about "Authorization". They are 'business logic' that you want to be enforced at the database level, the same way you can do it in a relational database.

OpenFGA's goal is to help you answer authorization questions at scale. From that perspective, I'm not sure if OpenFGA is the right place to enforce those constraints. You'll probably need to have that logic elsewhere too.

I think it would be useful to dig in each use case, understand the complete implementation of each one (e.g. what checks are you currently doing and that you'll keep doing, or which constraints are already being enforced by your current database), see what is the additional complexity that not having the check in OpenFGA adds.

For example, let's take the "an entity needs to have a single owner". In general, you'll have an "owner" field in that a database table that you are setting when it's created, and maybe it can be updated when ownership changes.

In the 'add entity' endpoint, you'll write the owner to your DB and you'll write the tuple to OpenFGA.

In the 'update entity' endpoint, you'll change the owner in your DB, and you'll delete a tuple and create a new one in OpenFGA in a single transactional write.

It's true that OpenFGA won't enforce the fact that there can be a single one, but it's not a state that you'd get into unless there's an application bug somewhere.

It's true that having the constraint in OpenFGA will protect you from those specific application bugs. But in the same way you don't put all your business validation logic in your database because it would be impractical/hard to scale, we need to find the right balance on when to put additional validation logic on OpenFGA.

I'm not saying it's a bad idea or that it should not be done, but I'd love to get deeper on the use cases.

@ethanjcohen you mention another scenario that is not about validation but about updating tuples. I see the point, and I think it's interesting to explore too. To be able to update a relationship you need to know that there's only one possible value for a specific entity/relationship, so it's related to the issue described above.