Introduction

Authorization is a critical component of every business application. If the authorization system is down, the application is down, so it must run at very high availability. It also needs to evaluate every decision correctly or risk elevation of privilege or information disclosure vulnerabilities. Finally, it has to run at very low latencies, because authorization is in the critical path of every application request.

Identity and access management (IAM) has long been considered a “workload”, in the sense that organizations must think about it holistically and have dedicated teams that ensure 24x7 operations. From traditional systems such as Active Directory to modern ones like Okta, most organizations have a distinct team that manages a centralized identity platform.

However, authorization tends to be application-specific, and the latency requirements for authorization are stringent enough that many organizations believe that they have no choice but to leave authorization to each application or microservice, rather than attempt to operate a shared authorization service. In other words, today authorization is very decentralized and bespoke.

In this article, we’ll describe the benefits of a centralized authorization system, and explore the functional, performance, isolation, and integration requirements that must be satisfied by such a system.

The benefits of centralizing things

For decades, there’s been a tension between having each of the organization’s lines of business own their technology stack versus having a centralized, shared platform that IT manages on behalf of multiple teams.

Centralization brings with it some distinct advantages:

• Standardizing the capability across the enterprise - no need for each business unit or application to develop duplicative capabilities or skills.
• Lowering costs by standing up a shared platform - amortizing the cost of building and operating the platform across all the applications that consume it.
• Applying governance, risk, and compliance in a uniform manner - making it easier to manage these for the enterprise as a whole.

Over the decades, centralization has moved up the stack. Some obvious examples include:

• 1990s: A shared data center providing “ping, power, pipe” for all lines of business.
• 2000s: Virtual machines on shared infrastructure instead of each application procuring its own hardware.
• 2010s: Shared cloud platforms and Kubernetes clusters for running multiple applications on the same cloud infrastructure.
• 2020s: Platform services teams delivering logging, monitoring, source code control, and CI/CD capabilities shared across many application teams.

Centralization in Identity & Access

Centralized IAM is not a new idea. In the 2000s, IT was responsible for running LDAP or Active Directory for the organization. Over the last decade, as identity moved to the cloud, IT shifted its expertise to operating cloud identity platforms such as Okta and Entra ID.

Similarly, application developers don’t build their own authentication into their applications: instead, they depend on an external authentication service (such as Auth0 or Clerk), federated with their workforce or customer identity systems, to verify that the user is who they say they are. By externalizing authentication, applications can plug into a common organizational single sign-on service (such as Okta or Entra ID), simplifying the process of provisioning and de-provisioning users across all applications.

Moreover, the organization has a single source of truth for its users and groups, and a single platform to manage the applications connected to the identity system. Finally, they have a uniform log and audit system for application logins, which are valuable for compliance and forensics.

The benefits of centralized authorization

The idea behind centralized authorization is not new. It typically goes hand-in-hand with the idea of “externalizing” authorization - i.e. factoring authorization out of the application code, and expressing it in its own domain-specific language - a practice also known as “policy as code”.

When applications externalize their authorization, access control logic is no longer opaque; common organizational policies can be applied uniformly; changes in authorization policy can be controlled and audited; and decision logs can be generated and stored uniformly across all applications.

Authorization as a shared responsibility

As with many shared capabilities across the enterprise, there are two constituencies that have a stake in authorization: application developers and the central services team.

Developers care about application-specific authorization logic

As mentioned in the introduction, authorization is application-specific: each application needs to define and enforce a set of permissions for the resources it manages. For example, a document management system needs to evaluate whether a user can view a document, and a candidate tracking system needs to evaluate whether a user can update a job description.

Today, these authorization rules are mostly encoded as “if” and “switch” statements inside the application logic. In order to properly externalize this logic to a centralized authorization system, that system must be expressive enough to capture that logic, performant enough to enforce access rules within a small latency budget, and easy to integrate with the application.

IT cares about uniformly applying organization-wide policies

While each application has domain-specific authorization requirements, most organizations have global policies that are important to enforce uniformly for every application. Central teams are often tasked with this responsibility.

Examples include:

• Users can only use the application from a known device
• Users must be logged in to the corporate VPN to use the application
• Users must not be in a “suspended” state in order to use the application
• Contractors can only use the application on weekdays and during working hours
• Trust signals must be used continuously to evaluate whether a user’s identity has been compromised

While some of these policies could conceivably be evaluated and enforced at login-time, the underlying conditions may change during the lifetime of an application session. For example, a user may become suspended, switch networks, or cross outside of a designated time window.

For these reasons, organization-wide policies need to be evaluated in real-time, right alongside the application-specific rules that govern whether a user can perform an operation on a resource.

Headwinds for centralizing authorization

The four big challenges around centralizing authorization revolve around expressivity, performance, isolation, and integration.

Expressivity

At its core, a centralized authorization system must facilitate writing authorization rules that express the organization’s policy as well as enforce permissions specific to the application. In other words, the functional requirements for both the organizational policy and application-specific permissions must be expressible in the authorization system.

Organizational policy is often expressed in natural language by governance, risk, and compliance (GRC) professionals, who are typically not engineers. That policy needs to be transcribed into a more precise language, which often involves attributes about users (e.g. the user’s department or managerial level); devices (e.g. managed status, device type); or the environment (e.g. VPN state, timezone). Attribute-based access control (ABAC) languages such as Rego or Cedar are the most popular way to author such policies.

Application-specific authorization rules are typically focused on answering the question “does this user have this permission on this object”. These rules lend themselves to be written using a Relationship-based Access Control (ReBAC) language, such as the ones inspired by the Google Zanzibar system. With these languages, a domain model describes the object types; the relationships that users can have with object instances (e.g. owner, editor, viewer, etc); and the permissions that are granted via these relationships (“can-read”, “can-write”, “can-delete”, etc).

It’s probably evident that these two constituencies have different requirements, so a centralized authorization system that delivers for both of these audiences must be expressive enough to write both ABAC rules and ReBAC schemas.

Performance

Authorization is in the critical path of every application request, so it has to be performed within a small number of milliseconds. This means that a centralized authorization system must execute a request quickly, as well as sit very close to the application - i.e. in the same cluster or availability zone.

An authorization system with a P99 latency of 5 milliseconds isn’t much good if it’s sitting in a vendor’s cloud infrastructure, 100ms away from the application. Likewise, even a co-located authorization system may not be fast enough to handle authorization requests quickly enough if it has to gather the data necessary to satisfy the authorization request from external systems. It follows that authorization systems need to both run close to the application, as well as cache authorization state locally.

In short, authorization is a latency-sensitive workload that often needs to serve 100’s or 1000’s of requests per second at low latencies for each application it serves. This can be a tall order for a homegrown system.

Isolation

A centralized authorization service that supports many applications must provide isolation for both policies and data for each of the applications it supports. Therefore, the service must be inherently multi-tenant. Even if the service is used only for the organization’s customer-facing B2B SaaS application, tenant isolation for each customer organization may be desired or even required.

Integration

There are two main aspects of integrating an externalized authorization system: how applications call it, and how application and organizational data gets fed into it.

For application developers to adopt an externalized authorization system, it has to be as easy (or easier) to call from their native language as it would be to call another function or module. And it needs to be easier (and more maintainable) to articulate authorization rules in a domain-specific language than it would be to write the “if” or “switch” statements in their native language.

In addition, when the application stores relationships between users and objects (for example, “Alice owns document 1”, “Bob is a viewer of document 1”), it must be trivial for developers to store these relationships in the authorization system.

Finally, many organizational policies are written around user attributes and group memberships. A centralized authorization system needs to easily import these attributes and memberships from identity platforms, so that it can execute authorization rules over local data. As mentioned in the section on performance, without storing authorization data locally, authorization systems struggle to meet the latency and availability requirements of their calling applications.

Overcoming the headwinds

While the requirements for a centralized authorization system may seem daunting, the good news is that there are open-source and commercial systems that can help you thread the needle and deliver against all of these requirements.

Expressivity

A key justification for rolling out a centralized authorization system is the ability to express and enforce organizational policies. But without getting application developers to adopt the centralized authorization system for their application-specific authorization rules, the value to the organization is limited.

Therefore, the centralized authorization system must support authoring both ABAC- and ReBAC-style authorization rules, and be able to compose them into a single policy.

One way of doing this is to choose distinct open source projects such as OPA and OpenFGA for each of these requirements, and have an OPA policy call an OpenFGA endpoint during policy evaluation time.

A more compact and performant approach is to use the Topaz open-source authorizer to augment OPA ABAC-style policies with native, built-in ReBAC functionality, executed against an embedded database. Having a single platform that can do both plays a huge role in optimizing performance, discussed next.

Performance

Authorization is a performance-critical workload: authorization requests must complete in a small number of milliseconds, and authorization throughput for a large B2B SaaS application must scale to 1000’s of requests per second. If many applications are sharing the service, this number may rise to 100K RPS or more.

A centralized authorization system must therefore scale horizontally - adding more authorizer instances should linearly scale the authorization throughput of the system.

A centralized service that is shared across many applications may have different performance requirements for each of these applications. Some applications may be so latency-sensitive that they cannot risk “noisy neighbors” affecting authorization latency. For those latency-sensitive applications, a dedicated authorizer needs to be available as a deployment option, without sacrificing the benefits of a centralized service.

A single-tenant authorizer like Topaz can handle on the order of 1000 RPS for reasonable policies, ReBAC schemas, and data sizes, and can scale horizontally in a linear fashion. Commercial solutions like Aserto offer a multi-tenant authorizer which can be used for applications that aren’t concerned about “noisy neighbors”, and augmented with dedicated authorizers for latency-sensitive applications.

Isolation

Multi-tenancy is a core requirement for a centralized authorization service. While there are many open-source options available for single-tenant authorizers, multi-tenancy tends to be the domain of commercial solutions that build on top of these open-source platforms.

Aserto builds a full multi-tenant solution around the Topaz open-source authorizer, including a multi-tenant directory, authorizer, discovery service, and control plane. The state for each tenant lives in its own Postgres schema, so data from different tenants isn’t intermixed. Each tenant has its own ReBAC schema and policy, supporting full isolation between applications.

This is significantly simpler to manage than operating a discrete authorization service per application.

Integration

A centralized authorization service is only worth operating if the organization’s homegrown applications use it as standard capability. This in turn only happens if it’s easy for developers to target.

Fortunately, most open-source authorization platforms have language SDKs and APIs. For example, Topaz and Aserto have a set of language SDKs for Typescript/Node, Python, Java, .NET, Go, and Ruby, as well as REST and gRPC APIs. This makes Topaz trivial to integrate into a wide variety of applications.

Furthermore, Topaz is easy to integrate at the API gateway level, which may be the only practical way to provide modern access control for legacy applications that aren’t worth re-platforming.

Stateful authorization systems such as Topaz also provide native APIs and SDK support for managing objects and relations stored inside the system. Identity and group membership data is especially relevant for authorization systems, and Topaz relies on an open-source ETL toolchain called ds-load to import users, attributes, and groups from a wide variety of identity platforms such as Okta, Entra ID, LDAP, Cognito, Google Workforce, Auth0, and FusionAuth.

Finally, keeping users and group memberships in sync with the source-of-truth systems is a vital integration problem. SCIM provides a mature solution for this problem, and Aserto provides SCIM integration with many sources that support it.

Conclusion

Over the years, we’ve seen an inexorable trend towards centralizing capabilities that can be shared across an organization. VMs, cloud computing, Kubernetes clusters, identity platforms, source control, logging, monitoring, and CI/CD are all examples of this pattern.

Centralized authorization is next. The value to the organization is significant: authorization across various applications can be implemented in a standard way, reducing the cost of standing up discrete systems, and allowing the enterprise to perform governance, risk, and compliance functions holistically across applications.

The headwinds for centralizing authorization revolve around expressivity, performance, isolation, and integration. They may feel significant, but fortunately a new set of platforms is emerging that address these challenges. Aserto provides one of the leading modern authorization platforms, and evaluating it should be on your technology roadmap.

To find out how we can help you with centralizing authorization, contact us here, or set up a call!