Hey HN! Ege from Permify here. Permify is an open-source authorization service and policy engine based on Google-Zanzibar[0] with our own twist. Me and my co-founders have known each other for years since high school. And we love building things.<p>We have both worked with fortune 500 companies to small businesses [1], and every authorization system was unique. Yet we always tackle the same problems.<p>- Modeling the authorization logic was hard. As the product grows things get complicated very fast. So, it’s challenging to design a model that’s both easy to start with and future-proof. [2]
- Designing the architecture was a dread. It’s not a huge problem when you have a monolith. But when it comes to micro-services it’s a nightmare since authorization data is a subset of application data. [3]
- Authorization checks occur in so many places; like user interfaces, routers, API endpoints, database queries… So, choosing where to enforce authorization, and loading the authorization data is hard.<p>So, Permify syncs your authorization data as relation tuples with CDC(Change Data Capture) from Databases you want to a DB you point at.[4] And based on this data you can get boolean returns for your access control checks.<p>I know many alternatives had launched at HN over the course of time. So what’s the twist. What we concurrently encountered was orchestrating the authorization data was a nightmare.<p>What you can except from Permify in following months;<p>- Message broker to support more Databases.
- Redis Cache support.
- Better debugging and auditing tools such as transparency logs.
- More compatibility with the Zanzibar paper.<p>[0]: <a href="https://research.google/pubs/pub48190/" rel="nofollow">https://research.google/pubs/pub48190/</a><p>[1]: <a href="https://www.permify.co/post/why-decouple-authorizations" rel="nofollow">https://www.permify.co/post/why-decouple-authorizations</a><p>[2]: <a href="https://medium.com/building-carta/authz-cartas-highly-scalable-permissions-system-782a7f2c840f" rel="nofollow">https://medium.com/building-carta/authz-cartas-highly-scalab...</a><p>[3]: <a href="https://medium.com/airbnb-engineering/himeji-a-scalable-centralized-system-for-authorization-at-airbnb-341664924574" rel="nofollow">https://medium.com/airbnb-engineering/himeji-a-scalable-cent...</a><p>[4]: <a href="https://dbconvert.com/blog/postgresql-change-data-capture-cdc/amp/" rel="nofollow">https://dbconvert.com/blog/postgresql-change-data-capture-cd...</a>
It doesn't seem to deal with consistency issues solved by the Zanzibar design, at least that I can see. While this is understandable since it is probably the most complicated bit of the Zanzibar paper, it is a bit disappointing that, as far as I can tell, nobody has really gotten that far.
A use case that I wish authorization service providers would talk more about is support for "list" queries e.g. What resources of type foo can the user read?<p>In really simple cases you may model this as a one-shot check on a logical collection resource e.g. If I have an organization, and an organization owns many repositories, I may check for action:read on resource:/organizations/:id/repositories. It's very limiting though. What if I want to list all repositories across all organizations I have access to? What if I have multiple levels I want to cut across? Do I need to do all the sub-queries and aggregations myself? Do I need to do a one-shot check on every potential resource? What if the answer is "no" for every one, and I end up doing a table scan of the entire DB just to produce an empty result set? etc.
How does that look in a microservice/distributed environment in terms of network traffic? Do you have some thoughts about it, minimizing number of queries, minimizing payload, such things?
It's interesting to see this project published shortly after our launch of Warrant Sync[0][1], an automatic data-syncing solution for Warrant's authorization service.<p>[0]: <a href="https://blog.warrant.dev/introducing-sync/" rel="nofollow">https://blog.warrant.dev/introducing-sync/</a><p>[1]: <a href="https://docs.warrant.dev/quickstart/setting-up-sync" rel="nofollow">https://docs.warrant.dev/quickstart/setting-up-sync</a>
Interesting to see another project open sourced around Google Zanzibar. On a timeline for context:<p>- Ory came out first with Ory Keto ( <a href="https://github.com/ory/keto" rel="nofollow">https://github.com/ory/keto</a> ) which is trying to be a close adaptation of the paper. Initially, many concepts were missing but they are making a lot of progress with the DSL and it interfaces with the rest of Ory (OAuth2, User Mangement)<p>- Authzed came out as a SaaS only, open sorucing the code base later on at <a href="https://github.com/authzed/spicedb" rel="nofollow">https://github.com/authzed/spicedb</a><p>- Auth0 has been playing around with Zanzibar concepts in various forms and published a beta service at <a href="https://dashboard.fga.dev" rel="nofollow">https://dashboard.fga.dev</a> - apparently now also open source parts of it similar to what Authzed did: <a href="https://github.com/openfga" rel="nofollow">https://github.com/openfga</a><p>- Permify - who on a side note spammed me quite a lot with outreach because I was active in these communities - joins as well <a href="https://github.com/Permify/permify" rel="nofollow">https://github.com/Permify/permify</a><p>It's exciting to see so much movement, yet also sad that so many companies are brewing their own beer instead of working collaborative on the more succesful projects. Feels like we'll just end up with one or two successful projects (looking at Ory / Auth0 here) with the rest perishing. I'm wondering if there truly is a business model for just this permission system as a saas service (looks like this is what everyone is going with). Here I'm giving Auth0 probably the biggest plus as they have an established identity service. Then again, Okta (parent of Auth0) and Auth0 themselves are not particularly known for good business practices that we usually expect from developer tooling.<p>What's refreshing though with Permify is that they are trying a bit of a different approach to Zanzibar!
I also wrote something similar that also has a dashboard where you can see the graph between relations (code quality is really lacking though). It uses a DSL built on yaml.<p><a href="https://github.com/DeluxeOwl/kala-go" rel="nofollow">https://github.com/DeluxeOwl/kala-go</a>
<a href="https://kala.andreisurugiu.com/" rel="nofollow">https://kala.andreisurugiu.com/</a>
Disclosure: I'm the founder of Oso (osohq.com).<p>It's good to see more activity in this domain. One thing I've noticed over the last several years has been: beyond the fact that we haven't had good options for authorization tools, the world doesn't have enough mental models and good language for describing the authorization _problem_. It's mostly RBAC and ABAC. That is...limited!<p>As more people work on this problem, I hope we'll continue to build out the collective knowledgebase in addition to having tools that supercharge us. To get the ball rolling, we've written a number of articles, e.g.,<p>- What is Google Zanzibar (<a href="https://www.osohq.com/learn/google-zanzibar" rel="nofollow">https://www.osohq.com/learn/google-zanzibar</a>)<p>- Authorization Academy, a series of technical guides on building authorization into an application (<a href="https://www.osohq.com/academy" rel="nofollow">https://www.osohq.com/academy</a>)<p>- Why Authorization is Hard (<a href="https://www.osohq.com/post/why-authorization-is-hard" rel="nofollow">https://www.osohq.com/post/why-authorization-is-hard</a>)<p>- Best Practices for Authorization Microservices (<a href="https://www.osohq.com/post/microservices-authorization-patterns" rel="nofollow">https://www.osohq.com/post/microservices-authorization-patte...</a>)<p>- Authorization Patterns in GraphQL (<a href="https://www.osohq.com/post/graphql-authorization" rel="nofollow">https://www.osohq.com/post/graphql-authorization</a>)<p>Onward :)
Welcome! Glad to see more folks joining the open source FGA/Zanzibar space! Making synchronization first-class is a great area to explore. It'd be nice to connect and chat about all things Zanzibar, not just data syncing!<p>The Authzed team[0] built Postgres syncing with the SpiceDB Postgres Connector[1] to explore syncing, but we never got it into a place that the community could agree upon. Users in the SpiceDB community are using technologies like CDC external to SpiceDB successfully, but there are many foot-guns to syncing because it can violate data consistency. Is there documentation on how Permify handles consistency (e.g. the Zookies/The New Enemy Problem from the Zanzibar paper)?<p>[0]: <a href="https://github.com/authzed/spicedb" rel="nofollow">https://github.com/authzed/spicedb</a><p>[1]: <a href="https://github.com/authzed/connector-postgresql" rel="nofollow">https://github.com/authzed/connector-postgresql</a>