Show HN: Permify – Open-source authorization service based on Google Zanzibar
github.comHey 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.
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.
- 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.
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.
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.
What you can except from Permify in following months;
- Message broker to support more Databases. - Redis Cache support. - Better debugging and auditing tools such as transparency logs. - More compatibility with the Zanzibar paper.
[0]: https://research.google/pubs/pub48190/
[1]: https://www.permify.co/post/why-decouple-authorizations
[2]: https://medium.com/building-carta/authz-cartas-highly-scalab...
[3]: https://medium.com/airbnb-engineering/himeji-a-scalable-cent...
[4]: https://dbconvert.com/blog/postgresql-change-data-capture-cd...
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.
Hey there,
Tolga from Permify here!
Yes this is very true. But we have this in our road.
First we’ll be focusing on message broker, and improving CDC.
Then we’ll add Zookies.
I’d love to connect & chat about anything related Authorization. - tolga@permify.co
"Google thing, but without all that pesky correctness" is a sadly common pattern.
SpiceDB does fully support all consistency described in the Zanzibar paper[0] and even allows the requests to specify consistency on the fly[1]. We've designed around this from the start because it'd be very difficult to add after the fact. We also built a CI pipeline that leverages ChaosMesh[2] to test for the New Enemy Problem.
[0]: https://docs.authzed.com/reference/zedtokens-and-zookies
imo i would add to your docs more details around what to do when you ex. update a relationship but fail to persist a zedtoken, or at least the options and what the ramifications are. these are things that people may not truly reason through and your team has the most context on how these decisions can affect user experience.
Thanks. This is great feedback. We've written a blog post[0] about some of strategies developers are using to write relationships, but we haven't covered explicitly the failure scenarios.
For the scenario that you've described, you should be able to retry persisting the zedtoken, but if there's some fundamental reason that's not working, you can always perform a fully consistency check and persist the resulting value -- fresher zedtokens are always safe.
[0]: https://authzed.com/blog/writing-relationships-to-spicedb/
I hate to detract from the Show HN post, but frankly, you have my attention. I'm taking a look at SpiceDB.
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?
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.
The problem you're describing is sometimes called the "ACL Aware Indexing" problem [1]. In a permissions service based on Zanzibar, this can partially be solved by walking the permissions graph in a reverse fashion: SpiceDB exposes this API as the LookupResource API [2]. However, even this approach has performance implications for very large datasets, so we're also working on improving resource lookup via a LookupWatch API [3], which can be used by consumers to actively cache the available set of resources as access changes over time.
[1]: https://authzed.com/blog/acl-filtering-in-authzed/
[2]: https://buf.build/authzed/api/docs/main:authzed.api.v1#authz...
According to one of the original designers of Zanzibar, they specifically designed the semantics to be able to answer this [1]. Whether a given implementation is able to do this efficiently is another matter though!
[1]: https://mobile.twitter.com/leakissner/status/141001671864303...
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?
Hey Soco!
I'm Tolga one of the co-founders of Permify. We have couple of ideas around there such as a better cache or using Redis persistence as writeDB.
I don't know if this totally answers your questions. But I'd love to discuss further more - tolga@permify.co
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.
Nice, love that you launched with React components! I need to decide to show a button before I decide to allow a button's action :)
Interesting to see another project open sourced around Google Zanzibar. On a timeline for context:
- Ory came out first with Ory Keto ( https://github.com/ory/keto ) 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)
- Authzed came out as a SaaS only, open sorucing the code base later on at https://github.com/authzed/spicedb
- Auth0 has been playing around with Zanzibar concepts in various forms and published a beta service at https://dashboard.fga.dev - apparently now also open source parts of it similar to what Authzed did: https://github.com/openfga
- Permify - who on a side note spammed me quite a lot with outreach because I was active in these communities - joins as well https://github.com/Permify/permify
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.
What's refreshing though with Permify is that they are trying a bit of a different approach to Zanzibar!
Hey there,
Sorry for the outreach spam, just were trying to get feedback. Sometimes me and my co-founders reach out same person :) I hope we didn't bothered you a lot.
Thanks for the kind words, hopefully we believe there are a lot more space for players in the space. I guess we should wait and see.
About the approach thanks for the kind words :) We're trying to focus on 2 main issues with Permify. 1. Modeling of authorization: Make it dead simple so everyone can build future-proof system without the effort. 2. Data Orchestration: Make it easy to move and sync authorization data, especially for. distributed systems. So you don't have to.
We love to chat about these topics so would love to connect and chat :)
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.
https://github.com/DeluxeOwl/kala-go https://kala.andreisurugiu.com/
Disclosure: I'm the founder of Oso (osohq.com).
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!
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.,
- What is Google Zanzibar (https://www.osohq.com/learn/google-zanzibar)
- Authorization Academy, a series of technical guides on building authorization into an application (https://www.osohq.com/academy)
- Why Authorization is Hard (https://www.osohq.com/post/why-authorization-is-hard)
- Best Practices for Authorization Microservices (https://www.osohq.com/post/microservices-authorization-patte...)
- Authorization Patterns in GraphQL (https://www.osohq.com/post/graphql-authorization)
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!
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)?
Hey Jimmy,
I'm Tolga one of the co-founders of Permify. Lovely to be in the space. Thanks for the kind words we're always open to chat as well.
Right there things we have to improve such as data consistency as you mentioned. We'll be following Zookie model. And we will be adding message queue, and planning to add a message broker soon.
You can check this article for more: https://www.permify.co/post/why-decouple-authorizations
Would love to discuss further more.
Congratulations on the launch!
Do you have any repos with example implementations?
Right now we don't have, but we would love to help you personally. As well as, we'll be sharing updates about these at our discord community :)
Very cool.
See also https://openfga.dev/, Auth0's open-source ReBAC solution