Interesting read! It kind of a became a rule nowadays to never store logic in the database nowadays, but it's always refreshing to see when it could work. Please give us an update in few months of how it is going on the long run!
I have similar concerns, like how to reconcile authz with search. Search wants to be its own thing, and so does authz. Pray tell how I'm supposed to get a paginated list of authorized results? You have to filter or have the search service call the authz service. Life is easier when the main database can handle everything.
We should develop and translate this extension to other databases.
> The big problem that we kept running into was keeping everything in sync all the time. Every time we add a new user, organization, repository, etc. in our database, we also had to add the corresponding tuples in OpenFGA.
This is a fundamental problem with all Zanzibar-inspired authorization systems[0] that require centralizing ~all authorization data and led us @ Oso to build a more flexible system[1] that grants more control over what authorization-relevant data you centralize vs. decide keep locally.
Not sure couldn't it just have been multiple different tokens/sessions and based on the request, use the correct one? It obviously only solves the issue specifically for multi-tenancy, but if that meant being able to stay on RBAC and well, not doing that effort, I'd wager it'd be worth the trade-off
6 comments
[ 2.4 ms ] story [ 22.6 ms ] threadWe should develop and translate this extension to other databases.
This is a fundamental problem with all Zanzibar-inspired authorization systems[0] that require centralizing ~all authorization data and led us @ Oso to build a more flexible system[1] that grants more control over what authorization-relevant data you centralize vs. decide keep locally.
0: https://www.osohq.com/post/authorization-for-the-rest-of-us
1: https://www.osohq.com/docs/develop/facts/local-authorization
disclosure: founding engineer at Oso