Time flies when you’re having fun… this week, we celebrated Topaz’s one-year anniversary!
Topaz has come a long way in the last year, and we’re excited to announce version 0.30, launching this week at KubeCon North America 2023.
Topaz is designed to be fast, flexible, and easy. By fast, we mean that authorization decisions are designed to take on the order of 1ms. By flexible, we mean that Topaz can run any authorization model (RBAC, ABAC, ReBAC), on any cloud. And by easy, we mean that it’s “falling-off-a-log easy” to integrate into your applications and APIs.
Before we dive into what’s new, what makes Topaz special? It’s the only open source authorization service that combines the two best ideas we’ve come across in the authorization space: a policy plane that uses Open Policy Agent for its decision engine and language, and a data plane that implements a Google Zanzibar style relationship-based data model.
Over the last year, we’ve worked with developers from many companies, and incorporated their excellent feedback into what became a HUGE release. Here are some highlights.
The modeling language for defining object types, relation types, and permissions received a big upgrade. It’s now possible to define permissions (like
can_read) that can be inherited from relations on different types (
folder->viewer), and combined using either union or intersection semantics. This generalizes support for subject-relations and intersections, which was previously awkward to express in the model, and required help in the policy.
With the updated modeling language, most scenarios that don’t require attribute-based access control can be implemented with our default policy, which makes it much easier to get started: you don’t need to customize the policy until you hit a requirement that can’t be satisfied via the modeling language.
We don’t know of any open source authorization service that includes a full management console experience as part of the product. The Topaz console makes it easy to visualize and edit the policy, model, objects, and relationships that are loaded in Topaz. It also has an evaluation environment where you can easily formulate authorization queries and get responses.
Here’s some eye-candy :)
One of the hardest problems in authorization is how you get data to the decision engine. Unfortunately, OPA doesn’t have much of an answer here - you bake the data into the policy (in the form of a data.json document). Topaz includes a full data plane - it stores objects and relationships in an embedded database, resulting in lightning-fast authorization decisions, while allowing you to scale the data well beyond what can fit in memory.
Loading data into Topaz just got a lot easier. In addition to a set of REST and gRPC APIs, and language SDKs, we’ve released an open source extract-transform-load (ETL) toolchain called
ds-load. It has a plug-in architecture that makes it easy to extract data from any source, transform it into objects and relations using a template, and load those into Topaz.
ds-load comes with plug-ins for many identity providers, including Okta, Azure AD, Google Workspace, Auth0, and Cognito, and has an SDK that makes it easy to build your own.
Directory REST APIs
The directory has an updated set of gRPC APIs, and the corresponding REST bindings. You can now add, update, and remove objects and relations using either API, and also walk the graph between subjects and objects, allowing you to answer questions like “what subjects have the
can_read permission on this document”, and “what documents does this user have the
can_read permission on?”
Node.js, Python, Golang, Java, .NET, and Ruby SDKs
Topaz 0.30 includes a full complement of language SDKs. These are all built on the gRPC bindings, so it’s possible to set up a long-running session with a Topaz directory rather than having to re-establish and tear down a TLS connection for every request.
Each SDK includes bindings to the APIs, as well as higher-level middleware that makes it easy to add Topaz authorization to frameworks like Express.js, Flask, Spring, ASP.NET, and Rack/Rails.
Templates for RBAC, ABAC, and ReBAC scenarios
Many developers struggle with how to get started on their authorization model. This is certainly true for people that come from the Open Policy Agent, where things are so open-ended that anything is possible.
We’ve created a set of onboarding templates for common scenarios - simple RBAC, multi-tenant RBAC, Google Docs, and ABAC scenarios, to name a few. These solve the “blank sheet of paper” problem, and give you a great starting point for your own authorization model.
Test harness for validating the model and policy
Testing is a critical part of getting the authorization model right. Topaz now includes built-in support for executing a test suite of both positive and negative test cases, to prove that subjects have the right permissions on objects based on the model and the policy.
Aserto SaaS improvements
Aserto hosts a multi-tenant SaaS environment where you can try Topaz without installing anything. We’ve streamlined the onboarding process to make it much easier to get started. If you don’t want to create a new account, you can sign in using GitHub. You can then select one of six onboarding templates, each with a Quickstart for getting you up and running in under 5 minutes.
A huge thanks!
Thank you to all of the developers out there that gave us tremendously valuable feedback, as well as the Topaz developers that worked tirelessly to get all of these improvements merged!
Try it out
And if you’d like to take a quick peek without installing anything, sign up for a free Aserto account and check out our SaaS version.
Hard coded logic vs externalized authorization service
Most developers start building permissions by sprinkled in authorization logic to various parts of the code. While a common pattern, embedding authorization logic within the application code has several limitations compared to externalized authorization. In this post, we describe those limitations and the benefits of externalized authorization.
It's time for authorization standards: AuthZEN
Today each authorization vendor supports its own APIs and protocols. But there's an appetite to change this. We’re in the early innings of a promising effort called AuthZEN, where the authorization community is hoping to establish a set of patterns and standards for externalized authorization. Read all about in this post.
Using scopes vs. permissions for application authorization
One of the earliest authorization patterns applications implement bases access on OAuth 2.0 scopes that are embedded in access tokens issued by an identity provider. While convenient, this method has significant limitations. In this post, we describe those limitations and provide alternatives for managing application permissions.