Mirror permissions on backend DB or openFGA as single source of truth

[Raid55]

Is it recommended to keep a "mirror" of the permissions in our backend DB, such as groups, guests, members, their roles, etc...
Existing in our DB as well as tuples in openFGA's DB.
Or is it better practice to keep openFGA as a single source of truth and to get info as to who has permissions on a specific document by querying openFGA (with ListObject, ListRelation, and Read calls).
For example:
We have a group table in the database to represent user groups and the groups display name and avatar. But now with openFGA, do we also need a group_member_user join table? Would we just be able to query openFGA to get the members of a specific group or is that and incorrect way to use openFGA?

To expand on this, this is mostly a UI question. When rendering a UI in the frontend we need to query the backend that will return the users who have access to the document (and what role they have). Should that information be stored in the backend database as join tables or is it "safe" and good practice to just call:

const guests = client.read({	 
    "tuple_key": {
        "relation": "guest",
        "object": "workspace:acme"
    }
})
const members = client.read({	 
    "tuple_key": {
        "relation": "member",
        "object": "workspace:acme"
    }
})
const admins = client.read({	 
    "tuple_key": {
        "relation": "admin",
        "object": "workspace:acme"
    }
})

and then query our database by filtering the ID's in a sql query.

The alternative is storing those relations such as (with typeorm) we can call await workspace.members/await workspace.guests and it will join the users.
This would mean that every time we change a permission we also need to change that relation in our backend.

For reference I read: https://openfga.dev/docs/interacting/search-with-permissions
but where this differs is that i am not trying to check for access on a resource, i am trying to determine the level of access on each resource to return to the user and render them "share modal" UI along with their permission level.

[Raid55]

@xtc on discord left some useful points to take into consideration and I believe it answers my question.

some thoughts on this:

• How comfortable do you feel coupling your data relationships with OpenFGA? If you ever need to consider moving away form OpenFGA, you would need to either remodel your data or replicate the current source of truth (if possible) in the new service.

• When your applications scales, how do you ensure you're able to differentiate the resources required for your authz service and your "business data" service?

• It's generally best practise to have a separate DB for your OpenFGA, which means you'll likely need both services to have a complete picture of your data. Consider a scenario where you need to give a BI team access to this data, this means your BI tooling would require access to both services / databases.

• You should only be storing information that is relevant for the purpose of authz, could using OpenFGA as the source of truth for some relations mean you might end up having to introduce data that would no longer be relevant?

• How would this impact performance compared to having your data in the one place where you may be able to easily retrieve these with a join? Maybe something to benchmark vs an extra round trip to OpenFGA.

• How does his impact your DR strategies? You would need to ensure your backups are now linked or can be linked during recovery, potentially impacting Recovery Point Objective (RPO).

My personal opinion: I don't think this would be good practise. I would keep your authz layer (OpenFGA) and your business data layer decoupled. They are doing fundamentally different things and just because OpenFGA is providing some endpoints to do this, using it as the source of truth for potentially unrelated things (i.e. rendering UI) may not be its intended use.

[bytefish]

Thanks for the write-up @Raid55!

I am currently in the process of trying to understand the "best practices" as well and I am writing a small end-to-end example using .NET.

It's not finished yet, but I would enjoy some feedback or throw ideas around:

• https://github.com/bytefish/gitclub-dotnet

It basically aims at providing something similar to the Oso GitClub example (https://github.com/osohq/gitclub), and I am trying to find a good set of abstractions to better integrate OpenFGA with the .NET stack (EntityFramework Core, ASP.NET Core). The idea is to have something to a blueprint, that I could rip out code from. The project uses the OpenFGA "GitHub Permission model" shared by the OpenFGA team at https://github.com/openfga/sample-stores.

After a lot of back and forth I came to the conclusion, that it's best to keep the relational database as the Single Source of Truth and mirror the relations to OpenFGA. I need to be able to reconstruct the relation tuples at any time, when accidentally running a docker compose down on the OpenFGA container. 🫣

At the moment I am writing the relation tuples to OpenFGA when writing to the database.

This is similar to what Oso does in their "GitCloud" example:

• https://github.com/osohq/gitcloud/blob/cd14baa18508ae7be6579289b3c0e94a535adf9a/services/gitclub/app/routes/repos.py#L47-L52

I am sure there's a much better way in .NET to integrate with the frameworks and to write relations "automagically" to OpenFGA (for example using the ORM ChangeTracker and alike). But doing it explicitly is probably more obvious, flexible and better to debug if things go wrong.

My general feeling is, that you need a massive amount of integration tests and test scenarios to keep both systems synchronized and to feel safer, when refactoring either side. Probably it's more foolproof to have a Background Job, that is updating the tuples periodically and checks for dangling relation tuples.

These are just my impressions and the approaches I am thinking of and play around with.

It would be great to see more OpenFGA examples emerging.