Forem: Warrant

Why Google Zanzibar Shines at Building Authorization

Karan Kajla — Wed, 28 Jun 2023 22:45:00 +0000

Over the last couple years, authorization (AKA “authz”) has become a hot topic of debate. Proponents of various authz frameworks, libraries, and philosophies have voiced their opinions on how it should be implemented, jockeying for position to become the de facto way to implement authz. Among the contestants in this debate, Google’s Zanzibar has recently emerged as a popular way of not only modeling and enforcing authorization for modern, fine grained use cases, but also of scaling to meet the requirements of today’s large-scale, cloud-native applications.

When we started Warrant in 2021, we set out to build developer-friendly authorization infrastructure that all engineering teams could use. We knew that Warrant would be a core piece of infrastructure for our customers, so our authz service had to be (1) generic enough to model all of their use-cases and (2) scalable enough to support access checks across their authz models globally and with low latency. After reading the seminal Zanzibar paper, we decided to build Warrant’s core authorization engine based on many of the concepts described in the paper (e.g. tuples, namespaces, zookies, etc. – more on these concepts later). We believed that Zanzibar had zeroed in on a set of fundamental concepts and patterns that would help us build a generic solution to the authorization challenges of any application.

We launched Warrant to much discussion and debate and have tackled a wide variety of authorization challenges since then, helping many companies build production-ready authz. In this post, I’ll talk about why we believe Zanzibar is a great foundation for implementing authorization, discuss some areas where it falls short, and share how we’ve addressed those shortcomings with enhancements of our own.

A Flexible, Uniform Data Model for Authorization

Zanzibar provides an intuitive and (more importantly) uniform data model for representing authorization. Its authorization paradigm, known as relationship based access control (ReBAC), is based on the principle that all resources in an application are related to each other via directed relationships (e.g. [user:123] is [owner] of [report:abc]), and the application’s authz rules (i.e. the abilities granted to users of the application) flow from these relationships either explicitly or implicitly. Representing authorization in this way feels intuitive because it’s similar to how most of us already design data models (e.g. relational database schemas) for our own applications, making it easy to understand and reason about authz models in Zanzibar. ReBAC is also extremely flexible, capable of representing any authz model you can throw at it, including other authz paradigms like role based access control (RBAC) and attribute based access control (ABAC).

“Zanzibar provides a uniform data model and configuration language for expressing a wide range of access control policies from hundreds of client services at Google[...]”

–from Zanzibar: Google’s Consistent, Global Authorization System

In practice, each relationship between two resources is represented as a “tuple” composed of three parts:

The object (resource) on which the relationship is being specified.
The relationship being specified.
The subject (a resource or group of resources) that will possess the specified relationship on the object.

Together, the set of all tuples makes up a big graph of relationships in which the objects and subjects are the nodes, and the relationships between them are the edges. This graph is powerful because it can be traversed in various ways to determine the capabilities of users in an application. For example, a path between a user and a resource might mean that the user has write privileges on the resource. In another scenario, it might mean that the user is not allowed to perform writes on a different resource. To dictate how the graph can be traversed and to assign semantic meaning (for authz) to the relationships it represents, Zanzibar provides us with namespaces.

Authorization Logic Decoupled from Application Logic

Namespaces allow us to assign meaning to the relationships represented by our graph for the purpose of authorization. Each namespace defines the available relationships (e.g. admin, writer, reader) on a type of resource (e.g. report), and optionally, a set of logical rules that specify how each relationship can be inferred from others (e.g. an [editor] of a [report] is also a [viewer] of that report). They are similar to database schemas in that they allow us to define the structure of an authorization model, but unlike database schemas, namespaces also allow us to express logic on top of that structure. For example, the namespace for a report object type might define three relationships: admin, editor, and viewer. In addition to defining these relationships, the namespace can also specify:

A subject can only have the admin relationship on a report explicitly.
A subject can have the editor relationship on a report explicitly OR implicitly if it has the admin relationship on that report.
A subject can have the viewer relationship on a report explicitly OR implicitly if it has the editor relationship on that report.

The ability for namespaces to specify logical rules (or policies) like these between relationships makes it possible to separate authorization logic from application logic. This makes application code much simpler. The application only needs to confirm that a user has a particular capability (e.g. editor) before executing a section of code (e.g. persisting a proposed edit on a document).

Stateful, Centralized, Query-able Permissions

While modern, policy-driven authz solutions like Open Policy Agent (OPA) offer some of the features and benefits described so far, one thing remains unique to Zanzibar. It’s a stateful, centralized service, meaning that all tuples (the relationship graph) and namespaces are pieces of data that are stored and updated centrally. A major benefit of this design is the ability to query the data, not only to check if a particular subject has access to a specific resource, but also to get the list of resources a particular subject has access to. This is extremely useful in practice, for example, to audit a user’s privileges for regulatory compliance or to understand the impact of a change to the authorization model before applying it. In our opinion, having the ability to query permissions like this should be a requirement in any authorizaton system and can only be done in a stateful system with a global view of all authz data. However, as with any system design decision, this approach comes with its trade-offs.

Global Scale, Low Latency

Since Zanzibar stores all authorization data centrally, client applications must make requests to it to check permissions, making it a potential performance bottleneck for those applications. To minimize the end-to-end response times of authz queries, Zanzibar is distributed globally (as close to client applications as possible) and utilizes aggressive caching, responding to queries from cache (in single milliseconds) whenever possible. Because access patterns and freshness requirements for authorization data vary from application to application, Zanzibar has the concept of a “zookie” – a global, incrementing version number for each change made to the authorization data. Zookies make caching feasible while still allowing client applications to dictate when they favor correctness over speed.

Our Take on Zanzibar

While the concepts and features of Zanzibar are great, Google never built a publicly available implementation because they built Zanzibar to solve their own authorization needs for services like Drive, Docs, YouTube, and more. Fortunately, Warrant implements all of the concepts we’ve discussed so far, many of them with slight variations intended to either improve developer experience or add functionality that we feel Zanzibar lacks.

In Warrant, tuples are known as warrants. A warrant includes the same three major components (object, relationship, and subject) as a tuple but can also include an optional component that we call a policy. The policy component is a user-defined boolean expression that is evaluated at query-time to determine whether the warrant is available to the query or not. If a warrant matches a query and its policy evaluates to true, that warrant is considered during the query. Otherwise, the warrant is ignored.

Policies can reference dynamic contextual data that is passed in by the query (e.g. [user:123] is an [approver] of [transaction:abc] [if transaction.amount <= 100]). Having the ability to do this makes Warrant capable of modeling attribute based access control (ABAC) scenarios in which external data (e.g. the transaction amount) is required to make an authorization decision, something Zanzibar’s purely ReBAC approach struggles with. You can learn more about warrants in our documentation.

namespaces : tuples :: object types : warrants

Namespaces, as described in Zanzibar, are known as object types in Warrant. Object types are represented as JSON and conform to a JSON schema specification. Unlike Zanzibar’s namespaces, object types support the ability to restrict the types of objects that can possess each relationship, making it easier for developers to reason about the scope of each object type’s relationships. Warrant also provides various pre-built object types to standardize and simplify the implementation of common authorization use cases like RBAC, feature entitlements, and multi-tenancy within Zanzibar’s ReBAC paradigm. You can learn more about object types and the various built-in models Warrant offers in our documentation.

Looking Forward & Open Source

More than two years after choosing to build Warrant atop Zanzibar’s core principles, we’re extremely happy with our decision. Doing so gave us a solid technical foundation on which to tackle the various complex authorization challenges companies face today. As we continue to encounter new scenarios and use cases, we’ll keep iterating on Warrant to ensure it’s the most capable authorization service. To share what we learn and what we build with the developer community, we recently open-sourced the core authorization engine that powers our fully managed authorization platform, Warrant Cloud. If you’re interested in authorization (or Zanzibar), check it out and give it a star!

Storing Access Policies in Policy Files vs. in a Database

Karan Kajla — Tue, 19 Apr 2022 15:35:19 +0000

Introduction

When tasked with adding authorization & access control to an application, one of the first decisions many developers make is whether to store their application's access control policies in policy files or in a database. This decision is dictated by the business & operational needs of the application and is often made indirectly when choosing to use a library or implement a custom access control system from scratch. In this post, we'll cover the pros and cons of both approaches and discuss ideal use-cases for each.

Storing Access Policies in Policy Files

In the policy file approach, sometimes referred to as policy-as-code, an application's access policies are represented in a standardized notation and stored in a structured file format (yaml, json, a custom format). The application can then read files of this format and make authorization decisions at runtime based on the defined policies. More modern implementations of this approach (like Casbin or OPA) have implemented a custom file format which supports lightweight code blocks that can be executed at runtime to make attribute-based authorization decisions (ex: user has access until 9PM, user with IP address X.X.X.X has access, etc).

Pros

Simple & Lightweight

The policy file approach is simple & lightweight from the developer's perspective. Many authorization libraries take this approach so they're easy to drop into any application. The developer simply needs to define their application's authorization policies in a file and add the appropriate authorization checks to their code. Then they're off to the races.

Fast

Policy files are lightweight, so an application can read these files into memory and make authorization decisions quickly at runtime. No database or network calls are required to perform an authorization check.

Easily Version Controlled

Since access policies are stored as files, like the application's source code, they can be checked into a version control system (like Git), making it easy to version updates to access policies as they change over time.

Cons

Rigid

One-off cases for certain customers/users are a fact of life when operating a live system. While it's possible to define one-off rules in policy files, this can very quickly grow out of control, making policy files harder to manage. Policy files are better suited for applications whose access model can be defined by a finite set of generalized access policies without many one-off cases.

Difficult to Support User-Defined Policies

Many modern applications (Google Docs, Dropbox, Asana, GitHub, etc.) allow users to self-manage access policies on resources they create (ex: john.doe@gmail.com can make edits to my document). By nature, these types of access policies are dynamic at runtime and difficult to support when storing access policies in files.

Policy Updates Require a Developer

With the policy file approach, a developer typically needs to be involved when an application's access policies need to be updated. This is because the policy files are usually maintained using the same process as the application's source code (for simplicity). Additionally, the format & structure of the policy files isn't as accessible to non-technical team members. This can quickly become a drag on engineering teams that don't want to deal with the day-to-day management of an application's access policies.

Storing Access Policies in a Database

In the database approach, sometimes referred to as policy-as-data, the application's access policies for each user, resource, etc. are represented in a standardized format and stored in a database. The application can then query the database at runtime to perform authorization checks or fetch the access policies for a particular user or resource.

The structure of both the access policies and the underlying database tables storing those access policies is dependent on the type of access model required by the application (RBAC, ABAC, etc). For example, in a previous post we detailed how to structure your database for implementing Role Based Access Control. More modern approaches, such as Google Zanzibar, define a way to structure database tables to allow specifying arbitrary rules to enforce fine-grained access control on any resource in an application.

Pros

Flexible

Since individual access policies for each user and resource in the application are stored in the database, handling one-off cases is as simple as adding a new row to the policy database.

Support for User-Defined Policies

Storing access policies in a database is a natural fit for building applications that allow users to self-manage access policies on resources they created. Granting another user access to a resource is simply a new row in the policy database, and each new policy is immediately enforceable in the application.

Accessible to Non-Technical Roles

One of the biggest advantages of storing access policies in a database is that it's easy to build a user interface on top of the data. This allows even non-technical users to easily manage an application's access policies in real time, removing their dependence on engineering teams. This is especially valuable for product managers, customer support, and other non-technical roles that support software products with complex access control models.

Cons

Complicated to Implement & Manage

Effectively storing access policies in a database at scale requires the design, management, and hosting of the underlying policy database. As a result, implementing an access control system that stores access policies in a database is more complicated than storing access policies in files and requires greater effort to maintain over time.

Not Performant by Default

Because access policies are stored in a database, performing authorization checks isn't a fast operation by default. Querying the policy database to check if an access policy exists can take orders of magnitude longer than it takes to check against a policy file loaded into memory. This operation can be made fast by pre-fetching access policies or employing a good caching strategy, neither of which is trivial to implement.

Not Version Controlled by Default

Access policies stored in a database are not easily version controlled like policies stored in a policy file are, so more work is required to ensure policy updates are rolled out carefully. Version control can be added on top of the policy database, but this isn't trivial to implement either.

Conclusion

Because both approaches to access policy management offer a different set of trade-offs, they both tend to be more useful in some use-cases than in others. For example, the policy file approach is often used for managing access to cloud infrastructure (a heavy focus of frameworks like OPA) because the access model in such use-cases tends to be fairly static, well-defined, and uniform, without many one-off cases. On the other hand, the policy database approach is often used for application access control, particularly in Enterprise/B2B SaaS applications because these applications tend to have complex, dynamic access control models with many one-off cases and customizations requested by each customer. Deciding which approach to take for your use-case involves weighing the trade-offs of both approaches and choosing the approach that offers the greatest benefit to your application and team.

Authorization as a Service

Warrant is a fully managed authorization service that helps you add access control to your application and manage its access policies over time. Built from the ground up to solve the challenges of building and maintaining authorization in consumer & enterprise SaaS products, Warrant makes it dead simple to implement role based access control, fine grained access control, and other authorization schemes. Add enterprise grade access control to your application in minutes — try Warrant for free.

Insecure Direct Object Reference & How to Protect Against it

Karan Kajla — Thu, 18 Nov 2021 17:57:20 +0000

Insecure Direct Object Reference (IDOR) is one of the most common forms of broken access control which OWASP recently listed as the number one application security issue in 2021. A quick search for "IDOR" on Hacker One's Hacktivity feed shows that many top tech companies (and even the U.S. Department of Defense) have fallen victim to IDOR, in some cases paying out well over $10,000 per bug bounty. In this post, I'll explain what IDOR is, what causes it, and ways to protect your application against it.

What is Insecure Direct Object Reference?

IDOR is an access control vulnerability that occurs when an application uses an identifier for direct access to an object in a database but doesn't perform proper access control or authorization checks before querying or modifying the database. This often results in vulnerabilities that allow malicious users to access or modify other objects in the application, including those belonging to other users.

To better understand what IDOR is, let's walk through an example. A common case of IDOR occurs when developers implement the ability to update objects in their application. Typically, an update operation exposes the internal identifier of the object to the user (in the URL or API endpoint, for example), and that identifier is used by the system to update the appropriate object.

Consider an API for managing objects in a SQL database with the following table structure:

# NOTE: each object belongs to a single user
CREATE TABLE objects(
    id INT NOT NULL AUTO_INCREMENT,
    userId INT NOT NULL,
    name VARCHAR(255),
    description VARCHAR(255),
    PRIMARY KEY (id)
);

We have a GET /objects/:objectId endpoint for retrieving individual objects:

GET https://api.my-app.com/v1/objects/2408

Which returns:

{
    "id": 2408,
    "name": "My Object",
    "userId": 2,
    "description": "This is my object."
}

We also have a PUT /objects/:objectId endpoint for updating individual objects:

PUT https://api.my-app.com/v1/objects/2408

Which takes a request body:

{
    "id": 2408,
    "name": "My Object",
    "description": "My object's updated description."
}

In our API, the code for our PUT endpoint simply parses the request body and uses it to generate and execute a SQL UPDATE query for the object specified in the request body:

UPDATE objects
SET
    name = "My Object"
    description = "My object's updated description."
WHERE id = 2408;

The key thing to note is our code doesn't explicitly check that the object being updated belongs to the user making the request. The query above also doesn't have a condition checking for ownership (i.e. WHERE userId = <logged_in_user_id>).

As a result, a malicious user (userId 81 for example) could make a request to our PUT endpoint and update any user's objects (provided they specify a valid id).

PUT https://api.my-app.com/v1/objects/2408

{
    "id": 2408,
    "name": "User 81's Object",
    "description": "This object has been modified by user 81."
}

This issue seems fairly benign when dealing with example objects, but can become a major concern when malicious users can modify someone else's banking details or fetch another user's billing information.

Mitigation Techniques

Preventing IDOR in an application requires consistent attention to detail, and there isn't really one silver bullet solution to fix it once-and-for-all (especially in a growing application). However, there are many ways to mitigate it, and I'll cover a few of them below. The best way to keep an application free from vulnerabilities related to IDOR is to employ a combination of the methods described, especially the last one.

Use Non-Contiguous Identifiers

Even in a system with IDOR issues, a malicious user still needs to be able to enumerate or guess valid identifiers for other objects in order to access or modify them. In the example IDOR scenario from above, if the malicious user 81 didn't know the id of user 2's object (2408), they wouldn't be able to modify it. However, since we use a standard SQL integer identifier that increments by 1 each time a new record is created, it's pretty easy to guess valid identifiers. One way to prevent this is to use non-contiguous identifiers for database objects (like a UUID). However, this strategy does come with its downsides (UUIDs take more space to store, database index performance can suffer due to non-contiguous identifiers, etc.) and isn't guaranteed to prevent exploits as a result of IDOR.

Require Ownership Conditions in Database Queries

There are multiple layers in an application at which ownership or access control checks can be added to prevent IDOR. At the very least, requiring these checks at the database layer (the lowest layer in most web apps/services) can significantly reduce IDOR issues. Whether you're using an ORM or writing your own queries, a good way to enforce that all database queries include ownership checks is to abstract out all database interactions into separate "Service" and "Repository" classes (learn more about this pattern here).

The repository class is responsible for taking inputs and executing database queries (always written with an ownership check) based on those inputs, while the service class acts as a higher level interface to the repository you can use throughout your code. Following this pattern, all database queries for a particular database table are isolated to a single class/file which makes it easier to monitor and enforce ownership checks in queries. More importantly, any code using the service class to interact with the data is required to provide an owner id. Here's a basic example in JavaScript:

class ObjectRepository {
    get(userId, objectId) {
        /*
         * Execute the following SQL statement via ORM, etc.
         *
         * SELECT *
         * FROM objects
         * WHERE
         *     userId = <userId> AND
         *     id = <objectId>;
         */
    }

    update(userId, object) {
        /*
         * Execute the following SQL statement via ORM, etc.
         *
         * UPDATE objects
         * SET
         *     name = <object.name>
         *     description = <object.description>
         * WHERE
         *     userId = <userId> AND
         *     id = <object.id>;
         */
    }
}

class ObjectService {
    constructor(userId) {
        if (!userId) {
            throw new Error("Missing required parameter: userId");
        }

        this.userId = userId;
        this.repository = new ObjectRepository();
    }

    getById(objectId) {
        const object = this.repository.get(this.userId, objectId);
        if (!object) {
            throw new Error("Not Found");
        }

        return object;
    }

    update(object) {
        const updatedObject = this.repository.update(this.userId, object);
        if (!object) {
            throw new Error("Not Found");
        }

        return updatedObject;
    }
}

//
// Example Usage of ObjectService
//
const objectService = new ObjectService(UserSession.getUserId());

try {
    const updatedObject = objectService.updateObject(request.body);
    response.json(updatedObject);
} catch (e) {
    response.sendStatus(404);
}

Using patterns like the one above to enforce that database queries include ownership conditions will go a long way in preventing major IDOR vulnerabilities. However, not all ownership schemes map directly to a simple query condition like in our example. Take a collaborative text editing application like Google Docs, a file sharing service like Dropbox, or even an enterprise software service where users can grant other users the ability to view and edit documents on a per object basis. Applications like these typically maintain a set of ownership rules to help determine who has access to objects and require much more in order to prevent IDOR.

Implement Proper Authorization & Access Control

The most effective way to prevent IDOR in applications is to implement a proper authorization & access control system. One that can be queried anywhere in an application to determine if a user has the appropriate access to an object or resource before allowing them access to it. You can then add access control checks to your application wherever privileged data is accessed or modified, much like we did in our example above. To learn how to implement a basic Role Based Access Control system, check out our previous write-up on Implementing Role Based Access Control in a Web Application.

A good access control system should be able to model your application's database schema & how all your data is related, allow you to implement common access control schemes (like Role Based Access Control, Fine Grained Access Control, etc.), and provide an easy way to check against dynamic access control rules in your code to prevent vulnerabilities like IDOR. It should also be flexible, allowing you to implement whatever access control model your application requires, from basic RBAC to more complex models used for services like Google Docs or Dropbox. Finally, in a good access control system, the ability to modify your access model without having to push code changes should be a requirement.

Building secure, flexible, and consistent access control for an application is difficult and often not the focus of most developers building software. Warrant is an API-first access control service that makes it easy for any developer to drop a few lines of code into their application and instantly have secure access control. We have a generous free tier so you can test it out in your next application. Get started today!

Join the discussion on Discord, Twitter, and Reddit to hear more about IDOR, access control, and everything security related.

Authorization in 2021

Aditya Kajla — Fri, 05 Nov 2021 19:27:03 +0000

The topic of authorization has seen a recent resurgence in interest from developers and security folks alike. The OWASP Foundation, a trusted voice on web application security, just updated its Top 10 Web Application Security Risks and for the first time rated 'Broken Access Control' as the top vulnerability facing developers. Also this year, Airbnb, Carta, and Intuit each separately published deep-dives detailing their newly built internal authorization services.

Authorization is by no means a new security concept. So why this renewed attention to it? In this post, we’ll look at authorization as it stands today, what's changed in the landscape, and go over some best practices developers should follow.

The Authorization Spectrum

As previously mentioned, authorization is not a new concept. NIST defines it as “the process of verifying that a requested action or service is approved for a specific entity.” One addition we'd make to this definition is that good authorization also ensures proper gating and access controls on data.

Still, this is a very broad definition of authorization. There are no standards defining exactly how access checks should be implemented or what should be used to check permissions. But if you've read up on authorization, you've probably come across a couple of specific ‘types’ of authorization: ‘coarse-grained’ and ‘fine-grained’ authorization. Again, there isn’t an official definition or standards governing these two types but it’s generally accepted that coarse-grained authorization is more straightforward and simplistic (ex. Any user can access any report if they are an ‘admin’) while fine-grained authorization takes in many more inputs to determine access (ex. User [A] can edit report [X] if they have the [edit report X] permission).

Even though both are often described as two exclusive types, in practice it's more helpful to think of authorization as a spectrum with coarse-grained and fine-grained authorization serving as the two ends. Depending on the product and use-case, a system can be closer to coarse-grained, closer to fine-grained or even somewhere in between. It's also likely for systems to shift along this spectrum over time as usage and functionality change.

What's Changed?

Going back to our original question, if authorization is nothing new, why is there a renewed interest in it as a security concern? For one, the market for B2B software (particularly SaaS) has exploded over the past decade. Enterprises large and small are more comfortable than ever before in adopting new software products for their internal and customer-facing needs. It used to be that implementing proper authorization, especially fine-grained authorization, was a topic of concern for internal software development teams at Fortune 500s or enterprise software companies selling multi-million dollar contracts to large companies. These days, even smaller startups are competing for large enterprise deals where fine-grained authorization is considered table stakes. I'd argue that this market shift is being driven by a few key product themes. In no particular order, here are a few that stick out to me the most in B2B software.

Data, Data Everywhere

Modern B2B and enterprise software applications are collecting and processing more data than ever before. Whether it’s user-generated (documents, notes, messages, comments) or machine-generated (ML training data, logs, analytics data), modern apps are data-hungry. And the more data applications collect, the better the authorization schemes need to be in order to safeguard against costly data leaks and exploits.

Built for Collaboration

After working for years with tools like Google Docs and Dropbox, enterprise users expect to be able to share and collaborate on their content in whatever application they’re using. This expectation has pushed B2B apps to offer collaboration out of the box as a first-class feature. Implementing collaboration functionality is non-trivial and requires fine-grained authorization to ensure users can share and restrict access to specific content in real time.

Integrations

The rise of API-driven platforms and more recently ‘no/low-code’ tools has led to a plethora of integration opportunities between applications. But again, exposing programmatic data exports and uploads requires robust authorization in order to safeguard against unintended data leakage or access.

Best Practices

Whether you're a solo developer building an indie SaaS product or a developer at a big software company, hopefully this overview shows you the importance of implementing proper authorization in your system. While we won't get into specifics, there are some best practices (some borrowed from OWASP) you should consider:

As fine-grained as possible. Going back to the authorization spectrum, you want your authorization checks to be as specific as possible. Ideally, this means your system has the ability to check access based on specific records and resources (ex. User [A] can edit report [B]) instead of generic behaviors (ex. Any admin user can edit any report).
Deny by default. Application behavior and data should not be accessible by default. This makes it easier to enforce that only the right users have access to the right data and actions.
Implement once and reuse. Authz logic will get more complex the longer your application exists. Don’t spread out multiple implementations across the codebase because it will lead to missed cases and potential holes in your system.
Maintain an audit log. Keep an authorization log in your system (all allow/deny responses) so you can track access checks and conduct audits where necessary.

These are just some high-level starting points but should at least help you think of and protect against common authorization and access control related exploits.

If you’d like to chat more about authorization and access control, join us on Discord or on Twitter.

Implementing Role Based Access Control in a Web Application

Karan Kajla — Sat, 25 Sep 2021 00:00:53 +0000

Access Control is the process of allowing (or disallowing) user access to specific resources or actions in a software system. For example, only allowing certain users access to internal admin pages on a website or only allowing paying users access to a premium feature. There are many approaches to implementing Access Control, but Role Based Access Control (RBAC) is one of the most popular and widely used. In this guide, we'll cover a standard way to implement RBAC and discuss some best practices for implementing Access Control in APIs and web applications.

Overview

RBAC is an Access Control model in which the ability to access a resource or action in a system is tied to a permission (or policy), and each of those permissions is associated with one or more roles. Every user in the system has one or more roles and thus has all the permissions associated with those roles. This hierarchical structure is fairly intuitive and works really well for managing user access in a wide range of applications such as SaaS & enterprise software, e-commerce websites, company internal apps, and more.

Since Access Control (especially RBAC) is fundamentally a relational problem, it makes sense to use a relational database like PostgreSQL or MySQL to implement it. We'll break down the data model in this guide using SQL.

Users

Before doing anything else, we need to keep track of users in our application. For the purpose of this guide, we just need a unique id for each user in our system. This id will be used later to associate users with roles. Most applications will also store extra user information like an email, a password, and first & last name.

CREATE TABLE users(
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR(255),
    PRIMARY KEY (id)
);

Permissions

Once we have users, the first step in implementing RBAC is to define a set of permissions (or policies) and associate each permission with a privileged action in your application. For example, you might define a user:create permission associated with the ability to create a new user in your application. Only users that have the user:create permission will be able create a new user.

To manage permissions, we really only need each permission to have a unique id like users have. This is enough to associate permissions to roles. To make working with permissions more human-friendly, we'll make this id a unique string identifier (i.e. something like user:create) instead of an integer. This will make it easy to understand what each permission represents just by looking at its id.

CREATE TABLE permissions(
    id VARCHAR(255) NOT NULL,
    PRIMARY KEY (id)
);

Roles

Once we have our permissions defined, it's time to group them together in the form of roles. Roles are like personas for the different types of users that access our application. These personas will dictate which permissions should be grouped together for each role. For example, if your application has a free tier with basic features that are available to all users and a premium tier with more powerful features available only to paying users, you might define two different roles: One role called free_tier_user that grants access to all of the basic features and another role called premium_user that grants access to both the basic and premium features.

The data model for roles will look exactly like the model for permissions.

CREATE TABLE roles(
    id VARCHAR(255) NOT NULL,
    PRIMARY KEY (id)
);

Role Permissions

Since every role will have permissions, we need a way to associate permissions to roles. We'll call this relationship a role permission. To represent a role permission, we need to track the id of the role and the id of the permission we're associating together. Note that permissions can belong to multiple roles.

CREATE TABLE role_permissions(
    role_id VARCHAR(255) NOT NULL,
    permission_id VARCHAR(255) NOT NULL,
    PRIMARY KEY (role_id, permission_id)
);

User Roles

Since users will have roles, we also need a way to associate users to roles. We'll call this relationship a user role. To represent a user role, we need to track the id of the role and the id of the user we're associating together. Note that users can have multiple roles.

CREATE TABLE user_roles(
    role_id VARCHAR(255) NOT NULL,
    user_id INT NOT NULL,
    PRIMARY KEY (role_id, user_id)
);

Authorization

Now that we have a data model to store and associate users, roles, and permissions, we can use permissions to protect access to resources and actions in our system. We need (1) a way to check the data model to figure out if a user has a permission and (2) an easy way to perform these checks anywhere in our application code. This process of validating user access is known as authorization.

Querying Permissions

We can figure out if a user has a particular permission by querying our data for a relation between the user attempting to gain access and the permission required to gain access.

# Given a user id 15 and a permission id users:create,
# we can determine if the user has the required permission by:
# (1) Getting the user's role(s)
# (2) Checking if any of the user's roles grant them the required permission
SELECT *
FROM permissions
INNER JOIN role_permissions
    ON permissions.id = role_permissions.permission_id
WHERE
    permissions.id = "users:create" AND
    role_permissions.role_id IN (
        SELECT role_id
        FROM roles
        WHERE user_id = 15
    );

The query above will only return a result if the user with id 15 has the users:create permission through one of their roles. If not, it will return an empty result, meaning the user does not have the required permission through any of their roles.

Access Checks in Code

To make it easy to check for a permission anywhere in your application, you might abstract the query above into a helper class or method that can be called anywhere in your code. In JavaScript, this might look like:

class Authorization {
    // Returns true if the user has the
    // permission with the given permissionId
    static function hasPermission(userId, permissionId) {
        // NOTE: Assume getPermissionsForUser runs the SQL query from above
        const permissions = getPermissionsForUser(userId);

        return permissions.length > 0;
    }
}

You can then call this helper method to protect actions in your application:

function createUser(newUser) {
    const currentUserId = UserSession.getCurrentUserId();

    if (!Authorization.hasPermission(currentUserId, "users:create")) {
        throw new Error("Unauthorized attempt to create a new user!");
    }

    //
    // logic to create a new user
    //
}

Best Practices

Well-implemented Access Control is one of the most effective ways to provide data privacy for users and prevent potential data loss or theft. When implementing an Access Control model like RBAC, it's important to keep a few things in mind:

Define permissions based on resources and actions (i.e. users:create). This leads to well-defined permissions that never need to change even if your roles and application logic do.
Do not perform access checks based on role. This can be a very rigid approach that makes it hard to change your access model without updating code. Instead, it's better to check for access to permissions since these map directly to the resources and actions in your application.
Have a centralized access control service. Since access control is independent of your application's business logic, it's a good idea to separate authorization logic into it's own service. We did this with the Authorization class we implemented in JavaScript above.

Access Control isn't a core focus for most applications, but it's critical to get right. The margin for error is very low, and even a minor issue in authorization logic could expose privileged data and actions to users who shouldn't have access to them. If you don't want to worry about authorization best practices and implementing secure access control, use Warrant to add access control to your application using RBAC or other access models in under 20 lines of code.