How to Manage Authorizations with Role-Based Access Control

Role-based access control (RBAC) is a method for restricting system access by assigning users roles that grant one or more permissions. Each permission unlocks a specific function within the system.

RBAC is popular because it results in granular but scalable authorization structures. You can reliably assign each user the bare minimum set of functionality that their position requires. This avoids the security threats of over-privileged user accounts.

In this article, you'll learn how RBAC works, what security use cases it enables, and how you can implement it to effectively authorize your users.

What Is RBAC?

The following three main entities are involved in RBAC:

• Permissions map to functions in your system. They're discrete tasks, such as raise invoice, issue quote, and ship order.
• Role groups one or more permissions. You could have a sales role with just the issue quote permission, a cashier role with raise invoice and ship order, and an administrator role that includes all three permissions. Roles allow commonly combined permissions to be assigned collectively, and they're a bridge between your organization's structure and the system's functions.
• Subjects are assigned one or more roles. They're able to use the functions referenced by the permissions in each role. Subjects can be human users or service accounts, such as API keys.

These fundamental concepts provide a powerful set of benefits:

Define User Access by Feature

Users can be assigned the specific features they require instead of all-or-nothing access to the entire application. This reduces risk by preventing users from encountering features they have no reason to interact with.

Limit Internal Access Threats

Many security threats come from within organizations. Phishing campaigns, lost credentials, and disgruntled employees can all result in privileged user accounts being weaponized and used against you. Restricting accounts to specific features helps to limit the extent of these threats.

Create an Audit Trail

Good RBAC systems create extensive audit trails. You can log when roles were created, which users were assigned to them, and who failed an authorization challenge while accessing an off-limits resource. This increases visibility into security operations and can be a vital compliance tool.

Manage Authorization at Scale

Even the largest organizations are able to maintain RBAC-based security at scale. Admins can centrally define roles and then reuse them across hundreds of users, groups, and departments. This promotes automation, too: you could script your RBAC provider's APIs to clean up redundant roles, identify users who aren't using assigned permissions, and detect abnormal authorization patterns.

Managing Authorizations with RBAC

Real-world RBAC implementations usually go beyond simple permissions, roles, and users. The most powerful platforms provide tools for achieving fine-grained authorization that's robust, scalable, and versatile. Here's how to use RBAC to manage authorizations at the enterprise scale:

Create Precise Roles

Roles and permissions are additive. If a user is assigned two roles, they inherit the permissions from both of them. This characteristic means it's beneficial to use multiple smaller roles instead of one larger one.

The principle of least privilege states users should receive the bare minimum set of roles that support their responsibilities. In the previous cashier and sales examples, cashiers don't need to issue quotes, as that task's handled independently by sales. However, cashiers will need to retrieve an existing quote before they can raise an invoice.

Using a single role that can interact with quotes would prevent you from enforcing constraints. By splitting the role into individual actions (issue quote and retrieve quote), you can accurately model your organization's structure within the authorization system. Cashiers get assigned one role, while sales staff are granted both. The additive nature of roles means the sales employees receive the entire set of quote-related permissions.

Defining Roles with ZITADEL

ZITADEL is an open source identity management platform. It's available as a software-as-a-service (SaaS) cloud solution and a self-hosted option, which you can deploy on your own servers.

ZITADEL groups users and projects into organizations. Projects represent a collection of related services that users in your organization authenticate to, such as a web app and its accompanying API. Resources in different organizations are separated from each other, but you can delegate access to other organizations by creating an explicit grant.

After you've created an organization and project, you can define your roles by heading to the Roles page from the Projects details screen. Click the blue New button to create a role:

Use the next screen to enter the data about your role. The Key is the role's unique identifier to reference in your application. The Display Name is what you'll see in the ZITADEL console when you're allocating the role to users:

Click the Save button to add the role to your ZITADEL project. It will appear in your project's list of roles:

Next, use the sidebar on the left to switch to the Authorizations page. This is where you assign your roles to users. Click the New button to add authorization for the role you've just created:

You'll be prompted to select the users who'll be granted the role. Use the drop-down to add one or more users to the authorization, then press Continue:

The next screen will display the roles available in your project. You can assign multiple roles in a single authorization—they'll be applied additively, so all the selected users receive every selected role. Click the blue Save button to confirm your authorization:

Return to your ZITADEL Projects settings and enable the Assert Roles on Authentication option on the General page:

Now you can retrieve the user's authorizations in your application by calling the OIDC userinfo API endpoint:

Attribute-Based Access Control for Fine-Grained Authorization

Attribute-based access control (ABAC) is an adjacent authorization approach that looks at user attributes instead of roles. Users are annotated with metadata that you can look up in your app. Metadata is simple key-value pairs of characteristics, such as the user's role, the team they work in, and any security clearances they hold.

Attributes are also applied to the resources in your system, such as invoices and quotes. You might tag the user who created the resource, the department it belongs to, and any special attributes that users require before they can interact with it. The authorization platform compares the attributes of the resource and user when a challenge occurs.

ABAC is more powerful than RBAC. ABAC is a fine-grained approach to authorization that supports richer access control conditions. Systems that use ABAC are able to closely model your business rules and processes more.

RBAC falls short when it comes to protecting individual resources. Splitting roles up (such as the previous issue quote and retrieve quote examples) defends against unauthorized actions, but this mechanism alone can't accommodate the role to retrieve quotes relating to the user's department. Implementing this policy requires the authorization platform to know what the user's department is, and ABAC metadata provides this information.

Using ABAC in ZITADEL

ZITADEL supports ABAC through its user metadata system. You can configure metadata on your users and then retrieve it in your application using the ZITADEL API. Authorization checks can refer to the metadata when evaluating whether a user should be granted access.

To set metadata fields on a user, head to their details screen within the ZITADEL console. Switch to the Metadata page using the sidebar on the left. Click the blue Edit button to open the editor:

Use the dialog to define your key-value metadata pairs:

Your application can retrieve the metadata by including the urn:zitadel:iam:user:metadata reserved scope when you request authorization. The userinfo API will include the metadata object when you send an ID token that's been generated with this scope. The metadata values are encoded as Base64:

The Future of RBAC and ABAC

RBAC, ABAC, and the broader concept of fine-grained authorization have become standard ways to manage access control at scale. These approaches still form the foundations of advanced patterns for implementing globally consistent distributed authorization, of which Google Zanzibar is a prominent example.

Zanzibar goes beyond permissions, roles, and subjects to support namespaced configurations, per-resource authorization checks, concentric relationships, and nested resource hierarchies. This creates a graph-like structure that's traversed to check whether users can perform an action against an object within a particular context. Contexts could be a web app, API, or an external link to a file shared from another organization.

RBAC, Audits, and Automation

One of RBAC's advantages is the ease with which you can audit your authorization policies and apply any changes you require. For example, you might find that a role unintentionally includes extra permission. There's a risk that users will perform an action that's supposed to be forbidden. To fix the situation, you can simply remove the permission from the role. This immediately prevents users from continuing to carry out the action.

Authorization platforms like ZITADEL provide a comprehensive audit trail that lets you step back in time. You can use this data to address any doubts about a user's past activity. Role assignations, revocations, login attempts, and metadata changes will all be recorded, creating a historical record of changes to your authorization structure.

RBAC is also easy to automate, which aids integration with your existing systems. You can use APIs to bulk update roles, validate access tokens, query for users who can perform an action, and revoke access after your tools detect a compromised account. This makes it easier to set up and maintain large-scale authorization structures without depending on repetitive manual actions.

Conclusion

Role-based access control is an approach to fine-grained authorization that helps reduce the risks of over-privileged accounts. It is scalable to large teams, creates an audit trail that helps with compliance, and is capable of advanced policy-based authorization decisions when you set attributes on your users and objects.

You can quickly add RBAC to your own system using ZITADEL's open source identity management platform. Users sign in to your app with their OpenID Connect, OAuth 2, or FIDO2 provider. You can retrieve the user's roles by calling the ZITADEL API or choosing to include role data in access tokens. ZITADEL solves all your authentication and

This article was contributed by James Walker.