In a world where security is paramount, application developers and engineering leaders require innovative solutions to address the complexities of application authorization.

Aserto CEO, Omri Gazitt, discusses the current state of modern authorization with Damian Schenkelman from Okta in this episode of the Authorization in Software podcast. They dive deep into fine-grained authorization, what it is, the underlying design principles, why it is gaining momentum, and review an open-source authorization engine that combines cutting-edge ideas from the last few years.

Read on for all the details, or listen to the podcast here.

The three pillars of modern authorization

The phrase “modern authorization” can mean many things to many people, so let’s start by defining what we mean by it. Modern authorization hinges on three main ideas:

1. Policy-based access management: The first step to modernizing your authorization system is to extract all the authorization logic out of code and into an external policy. Once extracted, policies can be handed over to the security or IAM engineers to own. This separation of concerns not only frees application developers from writing authorization logic, which is not their speciality, but also increases agility as the policy and app can now evolve independently from each other.
2. Fine-grained access control: Modern authorization provides organizations with granular permissions over protected assets, often down to individual resources. This enables organizations to make the shift to zero trust by adhering to one of the most important principles of the framework: the principle of least privilege. Based on this principle, a user should only have access to what they need to perform their function. Defining access at the resource-level ensures that users only have access to what they should.
3. Real-time evaluation: Modern authorization requires we depart from the traditional approaches of overprovisioned roles, or treating a set of scopes embedded in access tokens minted by identity providers as a sufficient form of authorization. Instead, authorization is treated as a distinct process that happens downstream from authentication. The application will call the modern authorization services just before access is granted to a protected resource. It will share user, resource, and policy context so that the decision engine knows who is trying to perform what action on which resource. That, together with the latest authorization logic form the basis of an approve/deny decision.

These are the three big ideas that are at the heart of modern authorization. There are a couple additional requirements of modern authorization systems, including the need for an audit trail, or authorization decision logs, for every access decision made. These logs are valuable for compliance, forensics, and auditability. Modern authorization services also require a distributed systems architecture to allow for the low latency and high availability a critical service like authorization must have.

For more about these design principles, check out the five laws of modern authorization.

Rising demand for modern authorization

Modern authorization is fairly new. Most projects were launched in the past 3-5 years. We’re now seeing increased awareness of the concept, as well as demand for modern authorization services. We’re also seeing growth in open-source authorization projects, from policy languages to decision engines, a leading indicator of adoption of innovative technology.

Several factors are contributing to this growth:

1. Shift from the perimeter to the application: Traditional perimeter-based security is obsolete. Following zero trust, the burden of securing applications has shifted from the environment to the applications themselves, making authorization a critical concern.
2. Broken access controls is the #1 application security risk: Unfortunately, most applications haven’t kept up and exhibit broken access controls. In fact, the OWASP found some form of broken access controls among an astonishing 94% of the applications it tested, propelling this issue to the #1 threat on the OWASP top ten list of application vulnerabilities.
3. Broken access controls is the #1 API security risk: The OWASP recently published the 2023 API security top 10, with broken access controls featured as the the #1 risk to API security. The third and fifth most common risks were also forms of broken access control, indicating that it is a widespread problem.

Every year, we see more breaches. We also witness the detrimental effects these breaches have over the affected organizations. Organizations are realizing the inadequacy of the status quo and are seeking finer-grained controls over protected resources. This is a big driver of the growth in awareness and adoption of modern authorization services.

Implementing modern authorization with Topaz

The decision to build the Topaz open-source authorizer stemmed from the observation that existing authorization engines lacked a robust solution for application authorization.

We leveraged the Open Policy Agent as a foundation and added to it the data plane it was lacking. We also added support for graph-based authorization in addition to policy-based access management. This addition enables Topaz to be flexible enough to support any authorization model, regardless if it is based on roles, attributes, data, relationships, or combinations.

We used the following building blocks:

1. Decision engine: OPA has a great decision engine, which Topaz uses to make lightning-fast access decisions.
2. Embedded graph directory: Topaz comes with an embedded BoltDB database to manage relationship data and support relationship-based access controls (ReBAC). It also optionally allows you to store concrete objects, like users and all their properties, adding support for attribute-based access control (ABAC).
3. Authorization decision logs: Topaz automatically keeps a record of every decision made, which you can download and import into your SIEM or logging tool of your choice.
4. Developer tools: gRPC and REST APIs, a complete set of SDKs, quickstarts, policy templates, and docs to make it “fall off a log easy” to get up and running in minutes.

Subjects and objects

Many organizations have a number of applications and microservices that they maintain. Each has its own domain-specific objects, but they often share common subjects. Given that most applications have the concepts of users and groups, it made sense to use these as shared concepts with the ability to assign them as subjects across any of the organization’s applications or services.

An organization can also define their own subjects. For example, we can decide to organize our departments in a particular way. If we treat departments as subjects we can assign access to departments. We could assign view permissions to a folder to everyone in a specific department. This way we can have an organizational principle on the subject side that can span multiple applications, significantly simplifying administration of permissions.

Every application will have its own domain model, so it makes sense that objects are application specific. A document sharing app will have folders and documents as objects, while a to-do application will have todos and lists as objects. Each application defines its object types, relation types, and permissions in a domain-specific fashion.

When to use attributes vs relationships

There are many instances when the same concept can be modeled as an attribute and a relationship. For example, the user’s department can be applied as an attribute of the user, or as a “member” relationship between the user and the department object. So it begs the question, when do you use attributes vs relationships?

This decision seems to be mostly stylistic. I can understand if you choose to express the user’s department as an attribute of the user. I can also understand if you think it’s best expressed as an object with which users have a relationship.

With that said, there are some cases where it's a bit more clear cut. For example, there may be a set of states on a piece of data: a document may have a state property that could have the values of “draft,” “in-review,” and “published.” Writing attribute-based rules that determine access based on this status tends to be much simpler than defining distinct relationships for each of these states.

There is also logic that is difficult to express with relationships. Calculations are great examples. For example, if we’re trying to leverage a user’s approval limit to determine whether they can approve an invoice or not. We’ll need to pull in the invoice value and compare that to an attribute that reflects the user’s approval limit. The user’s approval limit is an expression; they can approve invoices under $50,000, for example. These expressions are much easier to express as attribute-based rules than relationships. Beyond that there is a lot of room for developers to use their judgment.

Overall, while there are apps that only use attributes or relationships, we find that most organizations would actually like to combine the two. They want to have global roles/user attributes, like seniority or location, to cover the simple logic (e.g. only employees in the HR department can view other employee information in an HR app), and a more granular approach for the more advanced logic (managers can view the information of their direct reports in the HR app). They want to be able to reason about user attributes, resources and relationships.

This is how Topaz implements fine-grained authorization, by supporting graph and attribute-based authorization.

Conclusion

Modern authorization is fine-grained, policy-based, and enforced in real-time. It is new technology that is gaining popularity among organizations looking to provide users with granular permissions.

The shift away from perimeter-based security and the prevalence of broken access controls among applications and APIs have driven awareness and demand for modern authorization solutions, like Aserto and Topaz.

Topaz emerges as a powerful solution addressing the evolving challenges of fine-grained authorization. By combining the strengths of policy as code and real-time decision-making, Topaz offers a comprehensive approach to access control.

Aserto was built on top of Topaz and adds a control plane for easy management of policies, users, attributes, resources, and relationship data. It also adds a high-speed data fabric to facilitate real-time synchronization between the control plane and every Topaz authorizer.

If you’d like to learn more or share your feedback drop us a line, or join our community Slack.