We rewrote OpenFGA in pure Postgres

We rewrote OpenFGA in pure Postgres(getrover.substack.com)

52 points by wbadart 208 days ago | 13 comments

forks 208 days ago |

> 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.

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

esafak 208 days ago |

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.

jschorr 208 days ago | |

Reconciling externalized authz with search is actually quite a challenging problem. For standard externalized authz, the recommendation is some form of pre-filtering or post-filtering [1], for which we actually built LookupResources (pre-filtering) and CheckBulkPermission (post-filtering) into SpiceDB.

However, as you mentioned, life is easier when the main database can handle everything, so we actually built a solution in that space called Materialize [2], which heavily denormalizes the authorization data and allows for joining within application databases such as Postgres. My colleague Evan actually put together a really cool video about using it with Gitea [3].

Recognizing that even with Materialize, however, the need to consume events can be a bit annoying, I've been doing some work to allow Postgres itself to do native JOINs against SpiceDB (and other operations). I demo it briefly in our recent announcements video [4] and I think it effectively solves this problem within Postgres, while still allowing for all the benefits (scale, performance, redundancy, distribution) of externalized authz.

[1]: https://authzed.com/docs/spicedb/modeling/protecting-a-list-...

[2]: https://authzed.com/products/authzed-materialize

[3]: https://www.youtube.com/live/u3i1SEd9Ll8?si=mCz5mZterxthoEwj

[4]: https://www.youtube.com/live/uz_gxz3whS0?si=g4NUZAIltYVyFzYj...

Disclaimer: I'm cofounder and CTO at AuthZed and we build SpiceDB and Materialize

vrama628 208 days ago | |

Have you looked into Local Authorization? https://www.osohq.com/docs/develop/facts/local-authorization it lets you apply authz filters to paginated search over a database, even if some of the data the authz depends on isn't stored in the database

babelfish 208 days ago | |

Authorized search isn't difficult. Store authorized readers (people, groups, etc) on each result to pre-filter results, then post-filter results with an additional authorization check in case the authorization store was updated but the search results store was not. Context: I've built an authorized search solution before.

ygouzerh 208 days ago |

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!

5Qn8mNbc2FNCiVV 207 days ago |

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

bsder 208 days ago |

I originally read that as OpenFPGA (note the extra P) and wondered what kind of eldritch abomination they had created ...

nocman 208 days ago | |

Oh, good, I'm not the only one then.