How to implement RBAC with Permit.io

Before we dive into the step-by-step tutorial, let’s start with a short introduction - 

What is RBAC?

Role-based access control (RBAC), is an authorization model used to determine access control based on predefined roles. Permissions are assigned to roles (Like “Admin or “User”), and roles are assigned to users by the administrator. This structure allows you to easily understand who has access to what. 

The combination of who (Which Identity, and what role are they assigned?) can do what (What actions are they allowed to perform) with a resource (On which aspects of the software) is called a policy.

For example, a user with the role of "System Administrator" might be granted access to perform every available action on all the resources in the system, while a user with the role of "Guest" might only be granted access to perform very limited actions on a few specific resources. 

Having predefined roles makes it easier to manage access to resources since the administrator only needs to manage the roles rather than the individual permissions for each user.

Who needs RBAC?

RBAC provides a rather simple solution for controlling access to resources based on a predefined set of roles (Which can, for example, correlate with an individual's job function or responsibilities). 

RBAC is a perfectly balanced policy model (not too complex [like ABAC or ReBAC] and not too simple [like Admin/Non-Admin]), as a result, it has grown to be very popular and is the default model your customers are probably familiar with.

Implementing RBAC can help ensure that only authorized users have access to sensitive resources and also make it easier to manage and revoke access as one's role and responsibilities within the organization change.

Using RBAC can help to improve security by making it more difficult for unauthorized users to gain access to resources and improve efficiency by reducing the need for manual assignment of access per individual user.

Example RBAC policy -

Say we are managing a Blog. In our blog, we have three different users, each requiring a different set of permissions - 

1. The system administrator, who manages the entire system

2. A person writing an article needs to be able to create new entries

3. A person who can edit existing content but shouldn’t be able to create new entries

In this example, we can divide these three users into three roles: 

An Admin, a Writer, and an Editor. 

These roles will be able to perform actions on the different resources within our blog. 

A resource, in this case, will be a blog post. 

The next question we have to ask ourselves is, “Which action can each of these users perform on the blog-post resource?” 

In this example, we can define actions such as Create, Edit, Delete, and View. 

If we try and define this policy in simple English, it would look something like this:

• The Admin can Create, Edit, Delete and View the Blog Post

• The Writer can Create, Edit, and View the Blog Post

• The Editor can Edit and View the Blog Post 

Why use Permit?

Permit allows setting up and managing all of our application-level RBAC roles in a unified user interface, saving you the time of having to develop such a system from scratch, so you can focus on the actual cool and unique features of our application.

Permit also allows you to embed parts of its UI as components within your application using Permit Elements, thus propagating permission management (User management, Audit logs, etc.) functionality to other stakeholders - tackling the complex challenge of Authorization-for-Authorization. 

⁠Learn more about the benefits of setting up RBAC with Permit.io here

Let’s get down to it!

Step 1: Onboarding

• Go to https://app.permit.io/

• Register and log in. Permit is free to use up to 1K MAU . 

• Follow the onboarding process step by step (The purpose of the onboarding is to help you set up basic RBAC - in this article, we aim to give you a more detailed dive into this setup). 

The first screen of the onboarding process

• Once you reach the last screen of the onboarding process, you will be asked to connect your application to Permit. Let’s quickly go over how that’s done - 

Step 2: Connecting your application 

• In the last screen of the onboarding process, you will be asked to connect your application to Permit. To achieve that, follow the instructions on the screen. You will need to perform three actions:

  1. Select the programming language which is relevant to your application. 

  2. Deploy a PDP (Policy Decision Point) image to your application via ‘docker pull’. 
     The PDP stores information about all the rules and permissions, and it resides on the client's server (You can learn more about the PDP here).

  3. Add the SDK to your code (In your relevant coding language). 

A detailed explanation of this process can be found here. 

Connecting a Node.js app instruction screen

Once our application is connected, we can continue to the setup step. 

Creating and Mapping Roles, Actions, and Resources

Let’s do a quick recap of the three terms we will be dealing with here. Going back to our example, we are going to -

• Setup three roles - Admin, Writer, and Editor

• Set up a Blog Post resource.

• Add four possible actions these roles can perform - Create, Edit, Delete, and View.

⁠Let’s dive right in.

Step 3: Creating a resource, defining actions 

Resources, roles, and actions are managed on the policy page. 

• Go to the ‘Policy’ page in the menu bar on your left.

• Click ‘Create’ and select ‘Resource’
  

  

• Name your resource - in this example, let’s name it Blog Post.

• In the ‘Actions’ panel, define the actions that can be performed on the resource - in this example: Create, Edit, Delete, and View.
  
  
• Finalize by clicking ‘Save Resource.’ 

• We now have our first resource and the actions which can be performed on it! Nice!

  

Note: You can remove the sample ‘document’ resource which was created during the onboarding - we won’t be needing it. 

⁠Step 4: Creating roles 

Now that we have our resources and actions set up, we can add new roles. 

• Click ‘Create’ and select ‘Role’

• Give the role a name - In the case of this example, ‘Writer’ (As we already have an Admin from the onboarding). 

• Repeat the process to create an ‘Editor’ role as well. 

• We now have our roles set up! 
  Notice resources and actions are automatically propagated between the different roles.

  

• Note: You can provide a short description for each role to give other users a better understanding of the definition of each role. 
  

Step 5: Add actual users to the roles you set up

Now that you have RBAC, it's time to assign these roles to actual users. This is done through the ‘User Management screen. 

• Go to the ‘Users’ page in the menu bar on your left.

• Click ‘New User’ and fill in the user details: email, first name, last name, and pick the roles you want to assign to the new user. 

• Assign the required roles to the newly created user. Note that each user can be assigned several roles. 

• Click ‘Create User, and you’re done!
  

  

Note: The email field you fill in will serve as the unique user key. It doesn’t have to be a real operational email address as long as it's unique. 

Step 6: Adding enforcement points - Permit.check()

Once your Roles, resources, and actions are defined, Permit has created the policies that correspond to them. Now that we have our policies, you can set up enforcement points within your app at the points where permissions need to be checked. To do that - 

• Go to a point within your app’s code that requires a permission check.

• Add this code snippet: 

  const permitted = await permit.check("john@permit.io", "create", "document");

• The permit.check function requires three parameters to be passed - a unique user key that exists within Permit, the action that’s being performed, and the resource that action is being performed on. The result of the permit.check will be a boolean that you can reference in your code logic to perform functions based on the outcome of the permission check. 

  if (permitted) {
      console.log("User is PERMITTED to create a document");
  } else {
      console.log("User is NOT PERMITTED to create a document");
  }

Step 7: Set the permissions for each role 

Now that everything is set up, it's as easy as checking a box. 

• Select the relevant actions for each role 

• Click ‘Save Changes’ 

  

• Once the changes have been saved, they should come into effect in your application instantaneously. 

• That’s it! You have an active RBAC system set up in your application. 

FYI: The policies generated via the Permit UI are all generated as Rego code, which you can manage via your own Git Repository. If you want us to set that up for you - let us know!

Step 8 (Optional): Adding users through the SDK / API

While you can create users with the UI dashboard, Permit also allows you to perform any action through the API. On top of that, you can use any of the multiple SDKs that abstract from the complexity of the API. 

• A detailed explanation of creating users with the API can be found here.

• An explanation about creating users with the Node.JS SDK is available here. 

• You can find the rest of the SDKs here. 
  

Summary

In this tutorial, we learned what role-based access control (RBAC) is, why someone would want to use it, and how it can be implemented by using Permit.io - Including creating Roles, Actions, and Resources and mapping permissions to them accordingly. 

Having trouble setting this up? Have any additional questions? Want to share a cool project you’ve built using this? Let us know in our Slack community.