Show HN: Permify – Open-source authorization service based on Google Zanzibar

122 点作者 freddgn将近 3 年前

13 条评论

EgeAytin将近 3 年前

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.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]: <a href="https://research.google/pubs/pub48190/" rel="nofollow">https://research.google/pubs/pub48190/</a>[1]: <a href="https://www.permify.co/post/why-decouple-authorizations" rel="nofollow">https://www.permify.co/post/why-decouple-authorizations</a>[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>[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>[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>

jchw将近 3 年前

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.

评论 #32100278 未加载

评论 #32101309 未加载

评论 #32100821 未加载

评论 #32108339 未加载

diggs将近 3 年前

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.

评论 #32103577 未加载

评论 #32107905 未加载

soco将近 3 年前

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?

评论 #32097878 未加载

kkajla将近 3 年前

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.[0]: <a href="https://blog.warrant.dev/introducing-sync/" rel="nofollow">https://blog.warrant.dev/introducing-sync/</a>[1]: <a href="https://docs.warrant.dev/quickstart/setting-up-sync" rel="nofollow">https://docs.warrant.dev/quickstart/setting-up-sync</a>

colinclerk将近 3 年前

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 :)

scorpiopie将近 3 年前

Interesting to see another project open sourced around Google Zanzibar. On a timeline for context:- 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)- 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>- 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>- 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>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!

评论 #32101230 未加载

评论 #32102432 未加载

techn00将近 3 年前

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

gneray将近 3 年前

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 (<a href="https://www.osohq.com/learn/google-zanzibar" rel="nofollow">https://www.osohq.com/learn/google-zanzibar</a>)- 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>)- 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>)- 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>)- Authorization Patterns in GraphQL (<a href="https://www.osohq.com/post/graphql-authorization" rel="nofollow">https://www.osohq.com/post/graphql-authorization</a>)Onward :)

jzelinskie将近 3 年前

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)?[0]: <a href="https://github.com/authzed/spicedb" rel="nofollow">https://github.com/authzed/spicedb</a>[1]: <a href="https://github.com/authzed/connector-postgresql" rel="nofollow">https://github.com/authzed/connector-postgresql</a>

评论 #32097803 未加载

mlejva将近 3 年前

Congratulations on the launch!Do you have any repos with example implementations?

评论 #32097753 未加载

_jezell_将近 3 年前

Very cool.

lkurtz将近 3 年前

See also <a href="https://openfga.dev/" rel="nofollow">https://openfga.dev/</a>, Auth0's open-source ReBAC solution