[HN Gopher] Show HN: Permify 1.0 - Open-source fine-grained auth...
___________________________________________________________________
Show HN: Permify 1.0 - Open-source fine-grained authorization
service
Author : ucatbas
Score : 44 points
Date : 2024-08-21 15:58 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ucatbas wrote:
| Permify was born out of our repeated struggles with
| authorization.
|
| Like any other piece of software, authorization starts small but
| as things grow scaling it becomes a real pain and begins to
| hinder product development processes.
|
| Ad-hoc authorization systems scattered throughout your app's
| codebase are hard to manage, reason about, and iterate on as the
| company grows.
|
| Also you will need to have more specific access controls as
| things grow. Traditional approaches like RBAC is inefficient for
| defining granular permissions such as resource-specific,
| hierarchical, or context-aware permissions.
|
| Architecture is another problem, in a distributed system you're
| going to need a solid plan to manage permissions between your
| services -- all while ensuring high availability and providing
| low latency in access checks for sure.
|
| We've created an open-source project to eliminate the
| authorization burden for devs.
|
| It's Permify, an Authorization-as-a-Service to help developers
| build and manage their authorization in a scalable, secure, and
| extendable manner.
|
| And last week, we released the first major version (v1.0.0) of
| it!
|
| Here is how Permify helps you handle authorization.
|
| - Centralize & Standardize Your Authorization: Abstract your
| authorization logic from your codebase and application logic to
| easily reason, test, and debug your authorization. Treat your
| authorization as a sole entity and move faster within your core
| development.
|
| - Build Granular Permissions For Any Case You Have: You can
| create granular (resource-specific, hierarchical, context aware,
| etc) permissions and policies using Permify's domain specific
| language that is compatible with RBAC, ReBAC and ABAC.
|
| - Set Custom Authorization For Your Tenants: Set up isolated
| authorization logic and custom permissions for your
| vendors/organizations (tenants) and manage them in a single
| place.
|
| - Scale Your Authorization As You Wish: Achieve lightning-fast
| response times down to 10ms for access checks with a proven
| infrastructure inspired by Google Zanzibar, Google's Consistent,
| Global Authorization System.
|
| Try it out and send any feedback our way!
| cmcconomy wrote:
| How does this compare to auth0's OpenFGA (based on Zanzibar)?
|
| https://openfga.dev
| EgeAytin wrote:
| Hi there, Ege from Permify here.
|
| Here are the major differences,
|
| - Better Performance: Observed guess, not necessarily a fact:
| Many folks have come to us from OpenFGA due to latency and
| performance issues. We're implementing various levels of
| caching mechanisms to meet the required performance. We have
| also documented the differences in caching between us and
| OpenFGA in the following document:
| https://permify.notion.site/Cache-Differences-Between-
| Permif....
|
| - Schema Management: We're taking an approach that help
| engineering teams to ease and streamline the management and
| collaboration of their authorization logic. We have features
| like: - Schema Staging: Handle authorization
| model (schema) changes at different stages and deploy schemas
| with our GitOps workflow, specifically designed to approve,
| merge, and monitor schema changes. - Partial Schema
| Update: Gives you the ability to update a schema partially
| without needing to change the entire schema. - Data
| Bundles: Handle multiple data creation and deletion actions in
| your applications.
| akajla wrote:
| I think one major difference between the Zanzibar
| implementations that are out there is support for the 'zookie'
| consistency token (as mentioned in the original paper). OpenFGA
| afaik doesn't implement zookies yet[1]. With zookies, each
| permission write generates a unique token that represents that
| particular write. Clients can store that token (per resource)
| and optionally provide it during runtime checks to ensure
| checks are consistent up to that write. It also helps the
| system guard against the 'new-enemy problem' (incorrect
| permissions checks due to permissions changes being read out of
| order) by ordering writes.
|
| I'd argue that it also unlocks a variety of caching
| implementations on the Zanzibar server while still allowing
| clients to specify desired consistency on a per-request/per-
| resource level. In other words, a Zanzibar implementation with
| support for zookies can guarantee consistency at a much higher
| throughput than one that relies on time (second, millisecond
| delay). This is important for generic 'read after write'
| scenarios.
|
| Disclaimer: I'm a former founder of Warrant[2] which was
| recently acquired by WorkOS. Our team has spent a ton of time
| building our Zanzibar-based authorization service (WorkOS
| FGA[3]) which supports zookies[4] and other Zanzibar concepts.
|
| [1] https://openfga.dev/docs/interacting/consistency#future-
| work
|
| [2] https://warrant.dev/
|
| [3] https://workos.com/docs/fga
|
| [4] https://workos.com/docs/fga/warrant-tokens
| EgeAytin wrote:
| Forget to mention, thanks for the reminding. Permify also
| supports zookies[0], here is the official docs for it.
|
| [0]https://docs.permify.co/operations/snap-tokens
| nkko wrote:
| Authorization is such a critical yet underappreciated part of
| system design. It's great to see open source projects tackling
| this space. I'll definitely be checking this out for my next
| project. How does this handle multi-region deployments?
| EgeAytin wrote:
| Thanks for the support, and don't hesitate to join our Discord
| community[0] for further questions.
|
| Regarding multi-region deployment, we offer PostgreSQL as the
| production database option. We support multi-region databases
| that share the same interface as PostgreSQL, such as Amazon
| Aurora. CockroachDB is also on our roadmap
|
| [0]https://discord.com/invite/n6KfzYxhPp
| mindigow wrote:
| So is this something similar to casbin? What are benefits and
| caveats of permify compared to auth libraries like casbin?
| EgeAytin wrote:
| Authorization libraries can be useful but often fall short in
| key areas. They typically lack fine-grained access control,
| limiting their ability to handle complex permissions. Casbin
| does provide RBAC and ABAC but as far as I know they don't
| support ReBAC.
|
| Libraries was designed to operate directly on an application's
| existing data structures without imposing a standardized model
| for how that data should be organized.
|
| Direct interaction with diverse data structures can lead to
| inefficiencies and performance bottlenecks. Without a
| standardized model, the library might not optimize data access
| and manipulation as effectively as it could with a uniform data
| structure.
|
| Additionally, they struggle in microservices architectures,
| creating challenges in maintaining consistent security policies
| across services. In a microservices architecture, each service
| might require access to the authorization library, but
| replicating this library across services can lead to
| maintenance, synchronization, and consistency challenges.
| ttsemih wrote:
| Can Permify 1.0 be used for multi-tenancy architectures?
| EgeAytin wrote:
| You can use Permify for multi-tenant authorization.
| Specifically, you can create custom authorization schemas and
| authorization data for different tenants and manage them in a
| single place.
|
| To learn more, refer to our docs[0]
|
| [0]:https://docs.permify.co/use-cases/multi-tenancy
| cryogenicplanet wrote:
| been amazing to see the amount of iteration in the product to get
| to 1.0!
___________________________________________________________________
(page generated 2024-08-21 23:01 UTC)