One mistake that should never be made is to assume permissions and identity access are easy. If you plan on just throwing some rows in the database and then making an authorization decision based on the existence (or nonexistence) of a row… then you might not be “secure”. And further, once you are successful, you should also start to consider a scalable and more accurate approach.
Identity and access management (IAM) is a critical part of an application (Security! Compliance!). When done correctly IAM can reduce operational spend and allow your business to tackle new initiatives with a more agile approach. Unfortunately, building permission systems — even basic ones — can be an overwhelming task and probably something that should be outsourced to the “right” platform.
The founders of Authzed (Jake Moshenko, Joey Schorr and Jimmy Zelinskie) saw many developers struggling to build permissions into their application and they knew there had to be a better way.
In 2019, Google released the Zanzibar paper. The research described how to take the best concepts from distributed systems and combine them with a reliable, performant system with no single points of failure — that also happens to be infinitely horizontally scalable.
Following the release of the paper, Jake, Joey, and Jimmy sought to see how this approach could help build a more effective IAM function in their open-source project, Quay (the first private Docker registry). They had already integrated basic permission controls into Quay, but they were nowhere near the level of Zanzibar.
They realized the value in the Zanzibar approach and started to consider how distributed permissions could help them. They came up with the following value system for this approach:
One other final requirement: they wanted to create a platform that was significantly more approachable and less daunting than Zanzibar.
In 2021, they launched Authzed with the intent to build out a Zanzibar inspired IAM platform and help further the concept of GIFEE (Google Infrastructure For Everyone Else). They built an open source implementation of Zanzibar called SpiceDB, an open-source database system for managing security-critical application permissions. And recently, they launched their Authzed managed service, which delivers a fully managed platform to validate application permissions.
Modern IAM solutions all have a similar goal: to decouple policy from the application. SpiceDB takes this one step further by also decoupling the data that policies operate on. This means that SpiceDB creates a single unified view of permissions across all of your organization’s applications.
This strategy has become an industry best-practice and is being used at companies large (like Airbnb) and small (like Carta). However, there are a few aspects of SpiceDB that make it unique from other solutions:
The SpiceDB schema language is built on top of the concept of a graph of relationships between objects. This ReBAC design is capable of efficiently supporting all popular access control models (such as RBAC and ABAC) and custom models that contain hybrid behavior. By developing a SpiceDB schema, you can iterate far more quickly and test designs before altering the application code.
SpiceDB is “identity vendor-neutral” meaning you can use multiple identity providers (like Auth0 and Okta) together and ask questions of different heterogeneous user sets. This capability is not possible today in Zanzibar.
SpiceDB has support for globally replicated backends, meaning that you can run this service all over the globe as a single, globally-deployed permissions database. It’s cost-effective because they share that single cluster with multiple users and federated out into smaller chunks. So you get the benefit of being globally deployed without the costs.
[Watch the team demo Authzed here: https://authzed.com/demo ]
SpiceDB acts as a centralized service that stores authorization data. Developers create a schema that models their permissions requirements, use a client library to apply the schema to the database, and insert data into the database.
Once stored, data can be performantly queried to check permissions in your applications. You can answer questions such as “Does this user have access to this resource?” and “What are all the resources this user has access to?”
Since SpiceDB is an open-source version of Google’s Zanzibar model, many of Zanzibar’s major design concepts exist in SpiceDB. It starts with the life of a request which is handled by the dispatch interface and then persisted into a datastore. Here’s a high-level architecture overview of a SpiceDB deployment:
(Credit: Authzed blog post The Architecture of SpiceDB)
And, yes, SpiceDB is a database — but it’s a purpose-built graph database for computing and commissions. This means there is still a need for a distributed backend store for the relational data to allow performing generalized queries.
Zanzibar uses Spanner as its backend distributed datastore. Spanner delivers low latency, high availability, immediate consistency, and ACID transactions. The team at Authzed wanted a Spanner replacement that would provide the same capabilities, and their search ultimately led them to CockroachDB. Similar to Authzed, CockroachDB is another GIFEE company (with some differences of course) that gives developers the freedom to deploy anywhere across any cloud – no vendor lock-in.
With support from CockroachDB, SpiceDB’s storage backends have a Spanner equivalent which gives users globally distributed data with ACID semantics. (If you would like to hear more about why Authzed chose to build on CockroachDB, check out this video: How Authzed Built an OSS, Zanzibar-Inspired Permissions Database).
Thank you to Authzed’s Jake Moshenko (co-founder) and Even Cordell (software engineer) for providing the information for this post. If you want to watch them explain the architecture and the use cases for SpiceDB check out the full interview here:\
Nubank, a leading Brazilian financial technology company valued at more than $45 billion dollars, needed a scalable SQL …Read More
We’ve been building for this for three years, said Naveen Molloy, COO of Bitski, a startup company based in San …