Two years ago, we founded Aserto to simplify authorization for developers. Authorization is critical and hard to get right, yet isn't a source of differentiation for most applications.

Google, Airbnb, Netflix, Carta, Intuit, and others have written about their authorization systems. It's clear that these are all significant undertakings by sizable teams. Most engineering organizations don't want to spend their precious cycles reinventing this wheel.

Over the last two years, we've collected a set of best practices that are common across these projects. We call them the Principles of Authorization. Our goal has been to democratize these principles, and save you time and effort.

Today, we're open sourcing a solution you can use to start building robust authorization in minutes. Read on below to learn more!

What's hard about authorization

1. Authorization needs to be consistent across an application. But in a microservices architecture, each service tends to implement its own authorization. This makes it hard to evolve the application in a consistent way.
2. Modern applications that follow the Principle of Least Privilege need fine-grained authorization models. But attribute-based access control (ABAC) and relationship-based access control (ReBAC) models are hard to build and evolve. As customers ask for finer-grained access, applications have to revisit their access control implementation.
3. Developers code authorization logic as a set of if/switch statements in each service. This makes it hard for security engineers to reason about the logic in a consistent way.
4. Done correctly, authorization is in the critical path of every application request. So it needs to provide low latency and high availability to its consumers, while computing authorization decisions with fresh data.
5. Modern application security in a zero-trust environment requires fine-grained authorization logs. More for engineering teams to build and maintain

Introducing Topaz

Topaz provides fine-grained, real-time, policy-based access control for modern cloud applications. You can deploy it as a sidecar or a microservice in your cloud, ensuring low latency to your application.

Topaz combines the best ideas from two cloud-native authorization ecosystems: Open Policy Agent (OPA) and Zanzibar.

OPA

Topaz uses OPA as its decision engine. Authorization policies can leverage user attributes, environmental attributes, and group membership. They can also check relationships between users, groups, and application resources. A docker-style workflow allows building policies into signed OCI images.

Using a domain-specific language (Rego) for authorization enables separation of concerns. Application developers own the business logic, while security engineers can manage authorization policies. It also enables logging and aggregating authorization decisions for compliance and forensics purposes.

Zanzibar

OPA is a general-purpose decision engine that doesn’t bring “opinions” to the table. This is where Zanzibar's opinionated ReBAC model comes in.

Topaz allows developers to express their domain model (e.g. organizations, projects, teams, lists, items). It also enables defining relationships (e.g. owner, member, editor, viewer) between objects and subjects. These relations carry the permissions for the application (e.g. viewing a document).

Topaz can check whether a user has a permission on an object by walking this graph and computing a decision. By providing a set of OPA built-ins like check_permission and check_relation, Topaz makes it easy to leverage your data model in your authorization rules.

Topaz stores all schema and data used for authorization in an embedded database. This enables quick and efficient authorization decisions.

Developer resources

Topaz has a set of gRPC and REST APIs, as well as language SDKs for Javascript/Typescript, Go, Python, .NET, and Ruby. For more, check out the documentation.

Join the community Slack to ask questions and get support around Topaz.

Why did we build Topaz?​

• Authorization for applications is hard to get right. There are many open-source libraries that help with RBAC and ABAC. But very few incorporate all the principles of cloud-native authorization.
• The two cloud-native authorization ecosystems, OPA and Zanzibar, both have advantages. But there isn't a solution that combines the best of both.
• Authorization requires both rules and data. Zanzibar hard-codes its rules, and focuses only on data. OPA lets you specify rules, but data is left as an exercise to the user.
• Developers deserve an open-source, self-hosted authorization service that makes it easy to build (and combine) RBAC, ABAC, and ReBAC models; supports a policy-as-code workflow; and provides built-in support for fine-grained authorization.

Principles of Authorization​

Topaz follows the five principles of cloud-native authorization:

1. Authorization as its own microservice. Instead of each microservice implementing access control on its own, it calls out to a purpose-built authorization service.
2. Fine-grained. Instead of relying on coarse-grained roles, the access model follows the Principle of Least Privilege. This enables assigning the smallest set of fine-grained permissions to each user or group.
3. Policy-based. Instead of authorization implemented as a set of if/switch statements (a.k.a. spaghetti code), policy is expressed in its own domain-specific language. It can be managed as code, and built into an immutable, signed artifact. This enables Separation of Duties - application developers own the app logic, and security engineers manage the policy.
4. Real-time. Instead of using token scopes as permissions, the app calls the authorization service before accessing any resource. This avoids stale permissions and follows the principle of Continuous Verification.
5. Comprehensive decision logging. Instead of only keeping coarse-grained login records, every authorization decision is logged. This enables fine-grained audit trails, compliance, and forensics, following the principle of Comprehensive Monitoring.

Comparing Topaz​

Topaz vs OPA​

OPA provides a strong foundation for an authorization service, and Topaz uses the OPA decision engine as a library. OPA is a general-purpose decision engine that enables attribute-based access control (ABAC) policies. OPA is often used in infrastructure scenarios such as Kubernetes admission control or API gateway policies.

Because it is a general-purpose engine, OPA has no "opinion" on how to structure policies. Topaz is an opinionated authorization system that is laser-focused on  application/API authorization.

Topaz addresses the hardest problem in this scenario: how to bring user, resource, and relationship data to the decision engine. This is critical in implementing a performant, robust fine-grained authorization system.

Topaz vs Zanzibar / ReBAC​

Google's Zanzibar is the authorization system for Google Drive and many other Google services. It implements an opinionated, fine-grained, relationship-based access control model (ReBAC).

In ReBAC, subjects (e.g. users, groups) link to objects (e.g. organizations, teams, projects, lists, items) via relations (e.g. owner, admin, editor, member, viewer).

There are many OSS implementations of the Zanzibar ideas. Topaz natively brings together the policy-as-code and decision logging capabilities of OPA with policy-as-data, through a Zanzibar-inspired directory. As a result, authorization policies can combine ABAC-style rules with ReBAC-style graph queries via a set of Rego built-ins.

Happy hacking!