Open-Source Authorization as a Service

Background Information

The story starts back in 2007 when our founders, Omri Gazitt and Gert Drapers, were working on what would eventually become Azure Active Directory. At that time, Active Directory was a keystone workload for Windows Server. It enabled IT admins to map users and groups into the roles that enterprise apps exposed.

However, when enterprise software moved to the cloud, there was no longer a server operating system that could authenticate the user and keep track of what groups they’re a member of. As a result, every cloud application was forced to reinvent both authentication and authorization. The Azure Access Control Service and Azure Active Directory were early efforts towards reimagining identity and access for the age of SaaS and cloud.

Fine-Grained Access Control as a Service

Fast forward fifteen years, and we now have an interoperable identity fabric built on standards like OAuth2, OpenID Connect, SAML, and JWT, supported by all major cloud platforms. In addition, companies like Okta, Auth0, OneLogin, and PingID have developed cloud-neutral solutions, so no one has to reinvent login.

Authorization, on the other hand, remains widely underserved. In mid 2020, when Omri and Gert were searching for the next hard problem to solve, they immediately thought of creating a definitive solution for application and API access control.

CTOs and VPs of engineering confirm that authorization is a pain point. They find themselves continuously building and rebuilding their access control systems based on ever evolving requirements. IT is frustrated with every app authorizing differently, based on separate sets of permissions, data, and backend models. Having to navigate through dozens of consoles to manage policies is no walk in the park either. Omri and Gert knew there had to be a better way.

Modern Authorization

Let’s start by defining the problem. Authentication is the process of proving who you are to a system. It can be done through a combination of user ID and password, or through single sign-on (SSO), multi-factor authentication, or biometrics.

Authorization, or access control, is downstream from authentication. It is the process of evaluating what a logged in user can do in the context of your application. This is a different problem than authentication and it is surprisingly complex.

In the beginning, simple, rudimentary roles, like admin and viewer, might suffice. But, as you grow and evolve your application and onboard more sophisticated customers with advanced requirements, these simple roles simply don’t cut it anymore. At that point, you need fine-grained access control.

Modern authorization is fine-grained, policy-based, real-time access control. It is based on your resource hierarchy and domain model, and streams real-time data to local decision points to allow for millisecond enforcement based on the latest data. It is secure by default and employs principles of least privilege. It is easy to integrate and fits into your environments. Most importantly, it offers developers the flexibility to evolve access control models and policies as needs evolve.

Open-Source Access Control System

We built Aserto leveraging the best open-source, cloud-native projects, including Open Policy Agent (OPA), which is the basis of our decision engine. Rather than invent our own policy engine and language, we chose to join the OPA ecosystem, which has a good general-purpose decision engine.

We’re focusing Aserto on solving the hard problem, which is: how do you build scalable API and application authorization on top of those open-source assets?

One of the hardest challenges is getting data from policy information points to the decision engine, caching it to enable execution over local data, but keeping it in sync with the source. Aserto solves this problem by streaming user attribute and resource information to the policy decision points that are in your cloud in real-time, so you can make authorization decisions in milliseconds and based on real-time data.

Our open-source strategy is what we call “open edge:” Topaz, the authorizer software that applications call to make authorization decisions, is open-source, while our control plane is proprietary. Our control plane is where we feel we add value for organizations that are looking to coordinate or manage the lifecycle of their policies, connect all their identity providers, bring all that data to the edge, and bring decision logs from the edge back to the control plane.

Policy CLI

Along the way, we’ve created some general-purpose open-source projects to help move the ecosystem forward.

By default, OPA policies are built into tarballs. The Policy CLI brings a Docker-like workflow for building OPA policies into OCI images, which you can sign with cosign, to provide a secure software supply chain for your policy images.

Policy-as-Code and Policy-as-Data

There’s an interesting debate in the industry between two ecosystems—we call them “policy-as-code” and “policy-as-data.”

• Policy-as-code: Argues you can define everything in your policy. You can build general purpose rules, and use a logic engine to evaluate those rules, and decide whether or not this user has permission to perform this operation on this resource.
• Policy-as-data: Stems from a belief that most access control problems fit within a relationship-based model where the rule structure relates a subject, action, and object, essentially constructing a relationship graph between subjects and objects. This isn’t a new idea, but it has been revived by the Google Zanzibar paper, which describes how they built the permissioning system for Google Docs.

We don’t believe this is an either-or: you actually get a more interesting and flexible system when you combine the two.

The Aserto directory is built around the Zanzibar model, where you can define a set of object types like organizations, projects, teams, folders, or lists. You can then define a set of subject types like users and groups. Finally, you create relation types that connect the two, and hang permissions off of those relationships.

But if you want to extend the relationship-based model with attribute based access control rules, you can create a single policy that does both. Bringing these concepts together is the foundation for a flexible system that will grow with you. A system that lets you start simple, but scales with your requirements over time.

Conclusion

Today, every cloud application is forced to build and rebuild its own access control system. Application authorization seems simple at first, but it is surprisingly complex. Authorization is in the critical path of every application request, and getting the most up-to-date data to the decision engine to allow for millisecond decisions is a distributed systems problem that most engineering teams simply cannot justify solving.