Support tuple metadata

[paulosuzart]

Checklist

• I agree to the terms within the OpenFGA Code of Conduct.

Describe the problem you'd like to have solved

We use FGA to store permissions for several tenants in one single store and use in-context tuples to bind the permissions to a specific tenant. The tuples are placed together without a way of managing/distinguishing them under a tenant concept or any other form of marking tuples.

Describe the ideal solution

Ideally, tuples allow for arbitrary metadata (just key=valye, maybe) and a proper API to manage tuples by metadata. This way, we could ditch an intermediate database to keep extra attributes about the tuples.

The metadata usage would be for administrative purposes, not to be accessed during evaluation.

Alternatives and current workarounds

To solve this problem, we keep a separate database with extra attributes around the tuples for easy look-up (by tenant, by origin system, creation date, etc).

Another alternative is using a store per tenant, but that requires provisioning a store in a very specific moment of tenant onboard, and more importantly, several tenants can participate as parents of the other tenants (as described here), making it inconvenient to store tuples in separate stores.

Additional context

Delete operations could happen by metadata, even via a separate endpoint that is not the regular delete. Updating tuples to attach metadata could also be of great help to make existing tuples. In the end, the tuples are managed by other systems, and although they can and will keep a much bigger context around the tuples, more often than not, the place where tuples administration happens (CI/CD pipes, CLIs, Some UI, etc) will not have this full context.

[aaguiarz]

Thanks @paulosuzart for the feedback.

Adding metadata support it's something we discussed, but we are not convinced yet that we should build it.

OpenFGA's goal is to implement fast and scalable authorization. Adding metadata support would make it evolve into a general database, where you'd eventually need to filter/order by metadata fields. This will increase the complexity/scope of the product significantly.

However, we see the value of building this, and it will be in our radar in the future.