by Supertokens Team Roles-based access control (RBAC) is a security approach that uses roles to define what a user is and isn’t allowed to do. In a RBAC system, users are assigned roles with varying permissions for different resources, including files, databases, and applications. So, when a user tries to access a resource, the system will first find the roles associated with the user and then check if any of the roles have the appropriate permission. If so, the user is allowed to access the resource. If not, the user is denied access. For our example, we’ll be building a sample blogging app. First, we have a role. We’ll want to allow s to read all blog posts, but only edit or delete posts created by them. regular-user regular-user On the other hand, we create an role that allows s to create, edit, and delete all blog posts. admin admin So if a user with only the role tried to edit a blog post by another user, our system would see that the role doesn’t have the permission to edit that blog post and deny the request. regular-user regular-user RBAC vs. ABAC? Attribute-based access control (ABAC) is another approach that assigns permissions based on user attributes, resource attributes, and environment attributes. For example, a design file can be restricted to only users that have designer in their title and accessed on weekdays. While ABAC gives finer granularity over access to different resources, RBAC wins out on the ease of implementation. The initial setup cost of RBAC is magnitudes lower than ABAC. With RBAC, companies have a straightforward method for grouping users with similar access needs and then assigning permissions to those groups. With ABAC, companies must first define variables and configure different attribute-based rules, which can be a cumbersome process. Advantages of RBAC Easy to understand: Because of its intuitive structure, the underlying business logic with RBAC is simple to communicate and understand – even with dozens of different roles. : As you ship new features or change the application structure, adding or modifying roles can easily extend access to new resources for users that need them. Extendibility : Using RBAC forces developers to think about and organize application permissions and access control. This information can then be used by compliance officers during audits. Improving compliance : It becomes easy for developers to implement application security best practices around access control for their APIs, greatly reducing the chances of breaches. Decreased risk of data breaches / leakage Disadvantages of RBAC : It can be complex to make exceptions to how a role works. In our example above, if we want to add a rule that users with role cannot edit their own post if they have already made ten edits, it will have to be added in the API logic as an exception. There is no way for the roles / permissions system to express it easily. This causes issues since we have to encode this rule in all places where we are checking for the permission. Difficult to make exceptions regular-user edit:self Because the only way to add granularity to a RBAC system is by creating a new role, we can end up with hundreds of different roles that are impossible to manage. Role explosion: : There could be situations in which a user is assigned two roles that have conflicting information. In our example above, if a user is assigned the role and the role, they have and permission. Which one should take precedence? The precedence logic can be coded in the APIs, but this opens the possibility for errors. Can cause conflicts in permissions admin regular-user edit:self edit:all // only allow editing if the blog post belongs to the current user 
} 
else if (permissions.contains("edit:all")) {
	// allow editing 
} This may cause issues if a user has both the and roles – despite having the role, they will not be able to edit all the blogs because the statement is executed first while the rules get skipped in the following else-if statement. admin regular-user admin edit:self edit:all Implementing RBAC At Supertokens, we’ve been thinking a lot about user authentication and authorization. In fact, it’s all that we do. We recently launched our user roles feature based on RBAC principles. Our open-source user authentication can be set up in as little as 45 minutes! You can learn more about how to use user roles and permissions features using SuperTokens via the . recipe guides docs Written by the Folks at — hope you enjoyed! We are always available on our server. Join us if you have any questions or need any help. SuperTokens Discord Also published . here

Too Long; Didn't Read

Questions about cloud security? Get answers here.

Understanding Roles-Based Access Control (RBAC)

Too Long; Didn't Read

SuperTokens

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Understanding Roles-Based Access Control (RBAC)

Too Long; Didn't Read

SuperTokens

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES