permify VS spicedb

However, in this piece we're focusing on the PBAC model also known as Policy-Based Access Control and how it differentiates itself these from traditional access control models in terms of scalability, flexibility and security.

Hi I'm Karan, one of the maintainers of Permify (https://github.com/Permify/permify), an open source authorization service to build scalable authorization systems.

I want to share with you that we've built an AI assistant to help modeling your desired authorization logic! You can basically describe your authorization logic in Permify AI and it will generate the respective model and semantics accordingly. Think of it like ChatGPT for authorization modeling/policy generation.

Here's the project if you would like to play with it: https://ai.permify.co/.

Brief backstory:

Since authorization is generally a domain specific issue use cases vary widely - roles, relationships, attributes, hierarchies between business units, contextual permissions, etc.

To address this, we're offering a domain specific language that we built purely using golang to help model authorization logic programmatically. You can see what it looks like with sample examples in our playground: https://play.permify.co/

Although our domain specific language helps our users significantly, the general idea of policy generation is hard challenging if you have complex authorization logic and versatile permission requirements. Additionally, the flexibility of our modeling language allows for achieving the same policy/permissions through various approaches. But creating the best possible policy is crucial for several reasons including the performance of access checks, the readability of the authorization logic, visibility, and achieving least privilege, etc.

When we tallied up all those reasons, it hit us: using AI could really smooth out the policy generation process. It could not only reduce the engineering effort but also yield the best possible results. That's why we integrated Groq to make to create Permify AI!

Would love to get your feedback on this!

At that point consider exploring our solution, Permify. It's a Google Zanzibar-based open-source authorization service that helps to build scalable authorization systems.

Additional to shifts from large tech companies, ReBAC based solutions increased over the time. We're also one of them, building an open source authorization service that builds its core on top of ReBAC and Google Zanzibar.

Permify is an open-source service for creating and managing complex permissions in applications, inspired by Google Zanzibar. It offers a flexible authorization language compatible with various models like RBAC, ReBAC, and ABAC, and allows for efficient authorization data management in preferred databases. Permify's API facilitates access checks, resource filtering, and bulk permission analyses. It also includes comprehensive testing tools for authorization logic, including scenario-based testing and policy coverage analysis. Additionally, Permify supports multi-tenancy, enabling distinct authorization models for different applications within a single instance.

As Permify we're building open source authorization infrastructure to build fine grained authorization systems at scale. Would love to learn your use case and help you to build robust authorization systems. Don't hesitate to reach us from our Discord Channel!

I’m one of the maintainers of the OSS project Permify (https://github.com/Permify/permify), an open-source authorization service inspired by Google Zanzibar, which is the global authorization system used at Google to handle authorization for hundreds of its services and products, including YouTube, Drive, Calendar, Cloud, and Maps.

Hi folks,

I’m one of the maintainers and co-founder of the Go OSS project Permify (https://github.com/Permify/permify), an open-source authorization infrastructure inspired by Google Zanzibar.

I would like to share a post where we aimed to provide a brief overview of how we integrated WASM with Golang to provide a richer user experience in our open-source playground. You can use the playground to create and test any authorization logic in a browser.

The playground has three main sections:

Schema: to model your authorization logic through our domanin specific language we built.

Data: to create sample authorization data according to the model for use in tests.

Enforcement: to test your authorization structure bt access check scenarios.

Here's the post if you're interested: https://www.permify.co/post/wasm-go/

And here's the playground: https://play.permify.co/

Appreciate your time!

Have you taken a look at SpiceDB? The Authzed blog has a few posts that are useful to improving your understanding -- I can think of two: New Enemies and Writing relationships to SpiceDB.

Things I can't live without in a new Go project in no particular order:

- https://github.com/golangci/golangci-lint - meta-linter

- https://goreleaser.com - automate release workflows

- https://magefile.org - build tool that can version your tools

- https://github.com/ory/dockertest/v3 - run containers for e2e testing

- https://github.com/ecordell/optgen - generate functional options

- https://golang.org/x/tools/cmd/stringer - generate String()

- https://mvdan.cc/gofumpt - stricter gofmt

- https://github.com/stretchr/testify - test assertion library

- https://github.com/rs/zerolog - logging

- https://github.com/spf13/cobra - CLI framework

FWIW, I just lifted all the tools we use for https://github.com/authzed/spicedb

We've also written some custom linters that might be useful for other folks: https://github.com/authzed/spicedb/tree/main/tools/analyzers

At AuthZed, we think about this topic regularly while developing SpiceDB[0], except we believe feature flags are a subset of authorization. I'd disagree with the author that permissions are always long-lived -- authorization can also be ephemeral (and often that's how it's most secure) or dependent on run-time context[1]. What's more, using SpiceDB, we can often collapse checking for authorization and feature-flags into a single round-trip by defining a permission that can additionally require a feature flag (e.g. permission = admin & has_feature_flag).

It's a little silly, but lots of folks ask for the moon when it comes to performance for authorization because it's critical to every request, but then go on and sprinkle a dozen feature flag RPCs each adding more and more latency. We think you should be able to have both.

What we're excited about is use cases beyond feature flags and authorization: we've also seen some folks use SpiceDB as an update graph or others as a dependency graph.

[0]: https://github.com/authzed/spicedb

[1]: https://authzed.com/blog/caveats/

It scaled well compared to a naive graph abstraction implemented outside the database, but when performance wasn't great, it REALLY wasn't great. We ended up throwing it out in later versions to try and get more consistent performance.

I've since worked on SpiceDB[1] which takes the traditional design approach for graph databases and simply treating Postgres as triple-store and that scales far better. IME, if you need a graph, you probably want to use a database optimized for graph access patterns. Most general-purpose graph databases are just bags of optimizations for common traversals.

[0]: https://github.com/quay/clair

[1]: https://github.com/authzed/spicedb

I get the sentiment. We held off on building an operator until we felt there was actually value in doing so (for the most part, Deployments cover the operational needs pretty well).

Migrations can be run in containers (and they are, even with the operator), but it's actually a lot of work to run them at the right time, only once, with the right flags, in the right order, waiting for SpiceDB to reach a specific spot in a phased migrations, etc.

Moving from v1.13.0 to v1.14.0 of SpiceDB requires a multi-phase migration to avoid downtime[0], as could any phased migration for any stateful workload. The operator will walk you through them correctly, without intervention. Users who aren't running on Kubernetes or aren't using the operator often have problems running these steps correctly.

The value is in this automation, but also in the API interface itself. RDS is just some automation and an API on top of EC2, and I think RDS has value over running postgres on EC2 myself directly.

As for helm charts, this is just my opinion, but I don't think they're a good way to distribute software to end users. The interface for a helm chart becomes polluted over time in the same way that most operator APIs become polluted over time, as more and more configuration is pulled up to the top. I think helm is better suited to managing configuration you write yourself to deploy on your own clusters (I realize I'm in the minority here).

[0]: https://github.com/authzed/spicedb/releases/tag/v1.14.0

To my understanding, the only ReBAC system that supports dynamic attributes is SpiceDB.

If you're curious to see a Postgres-based implementation, SpiceDB has a Postgres driver: https://github.com/authzed/spicedb/tree/main/internal/datast...

Interesting, for SpiceDB[0], one place we've struggled with MySQL is preemptively establishing connections in the pool so that it's always full. PGX[1] has been fantastic for Postgres and CockroachDB, but I haven't found something with enough control for MySQL.

[0]: https://github.com/authzed/spicedb