What are Role-Based Access Control (RBAC) and ACL (Access Control Lists) and how are they used?

Photo by Paula from Pexels

RBAC (Role-based Access Control)

How is this analogous to RBAC?


But if there is some way to manage authorization, then the options of what can be done to a resource is limited. I.e., a person who is roleA can view and edit all documents in a database, but cannot delete. Another roleB will be able to view all and edit all and delete all.

This is important from a security perspective since if a bad actor gets into a resource, we can limit the damage she can do. In our basketball analogy, it’s like locking the jerseys up with an additional key that only players have. Role B— players- can access and put on the jerseys. This limits the damage done by a bad actor who uses a trainer’s pass to get into the locker room — at least the bad actor cannot touch the jerseys, since the bad actor does not have the key to where they are locked up inside the locker room. This is what RBAC lets you do; control the access of a resource based on the role of the person or application accessing that resource.

Error prevention

Data privacy and compliance

How can RBAC work?

Roles — who will have access?

Access per role- Probably a super/system admin needs full access to all. Other roles may need more restrictive permissions. The resolution of the access here can differ. It can be for entire resources, or it can be for specific parts of the resource, or even particular actions on specific parts of the resource. As on the entire resource:

By author

In this example, Roles A and C have access to resource A, but role B does not.

Greater granularity is possible:

In this example, maybe roleB is a human user, and you don’t want her to mistakenly delete the entire resource (like a database). So you can grant her access to READ resource A, but limit her access so she can’t modify resource A. This is already one step into access control lists, but let’s wait for it.

Users to roles — Now that we have Roles and access control per role, we need someone to use them. So, for each user we assign at least one role. MongoDb supports multiple roles per user:

MongoDb documentation screenshot

Others like Redis Enterprise does not offer this functionality of multiple roles per user (at least as of writing this post).


ACL — Access Control Lists

Here we have three different ACLs: (1) read-only for specific keys has been applied to roleA on resourceA, (2) no access has been applied to roleB for resourceA, and (2) read-only on specific keys and write on other keys has been applied to roleC on resourceA.

This is a small example but imagine if the key-command pair lists are longer and even more involved. More sophisticated commands, more specific keys, more complex key-command combinations. You need a way to take this lists of access control logic, and easily apply it elsewhere. Say you want to take these ACLs (1,2,3) and apply them on a different resourceB, say a different database. Do you have to rewrite them all? ACL (access control lists), once defined, act as a group and can easily be applied elsewhere. Like this:

Without having this entity of an ACL, after setting access control logic per role on resource A, the admin would have to manually repeat the access control logic when she applies it on resource B.

Pain points in using RBAC and ACL

Changing needs per Environment

Central control vs. developer freedom

Inconsistency of RBAC + ACL between services

Identifying what should be protected

Thanks for reading.

About the author


This article helped particularly with ACLs.

Francois from redis youtube video is great.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ron A

UX Designer turned Product Manager & Owner with experience in startups, freelance, B2B2C companies & agile. Writing helps me learn faster. @RonChirp on Twitter