Role-based Access Control (RBAC)

In RBAC, a user can play one or more roles, defined based on organizational policies. A role can have multiple privileges (permissions). Each permission can impact multiple capabilities. Let us understand this with an example.

Consider a customer service representative (User) gets a call from a customer to check if a new service on his SIM is activated or not. The user needs to access all the customer data, including his phone details, personal details, etc.

However, he just wants to view the information, so his “role” could be that of a “viewer.”

A viewer need not have privileges to modify information in the database, hence his permissions could be “read-only” as per the policy.

Finally, let’s say that the customer’s phone details are stored in one database and personal details are on a different database—in which case, he needs permissions for both databases. This defines the role’s capabilities, i.e., which part of the database can or cannot be accessed.

RBAC models

There are several RBAC models developed based on the core model, which is the foundational model of a RBAC system. As per the core model, users can be assigned multiple roles, and each role can have a specific set of privileges or permissions, to access certain capabilities.

Roles and privileges (permissions)

Privileges are a set of actions that are allowed on a capability. For example, if the capability is to “inform the customer about their bill cycle details,” then the user privileges (let’s say the customer care representative) could be read-only. If the capability is to update the phone number, the privileges could be read and write.

A role is a set of privileges assigned to the user. For example, a “viewer” role could have read-only privileges, while an “editor” role could have read and write privileges, while the “owner” role can have read, write, and delete privileges to a particular item (a database, a document, etc). An “admin” role who has to manage access rights will have all the privileges.

The privileges of a particular role are governed by a set of rules, known as policy.

Applying policies

Policies are a set of rules defined to manage roles and privileges (permissions). Policy ensures security as well as operational efficiency, as a user can perform only those actions assigned to the particular role as per the policy.

Role-based access control is a “policy-neutral” mechanism, as an organization can enforce the set of rules as per their requirements, and there are no rigid, pre-defined rules or access control policies.

How to grant access

To grant or revoke access, a user should have the necessary role that allows for the grant privilege. This would most probably be a database admin or database owner.

Other RBAC models

There are several role-based access control models that have added new features or capabilities to the core model, such as:

Role hierarchy

In this model, a higher role automatically inherits the permissions of the roles below it, along with its own permissions. For example, a manager will have permissions that his team members have, plus additional permissions that a manager needs to have.

Constrained RBAC

In addition to being role-based, constrained-based access control RBAC is also based on other factors, like time, location, and specific jobs, enhancing the security. For example, a contractor or a temporary staff can have access to certain resources for a limited period of time.

Symmetric RBAC

In this model, two different designations or positions can have similar or equal roles. For example, a manager and team lead can have access to the data of all the members in their team.

Why is RBAC popular?

Role-based access control is often favored by large organizations because it's straightforward and scalable. You can assign roles with specific permissions and then assign users to these roles, making it easy to manage access as your organization grows. While ABAC is powerful but complex, ACL is simple but not suitable for large organizations. MAC is centralized and more rigid, and RBAC is powerful and user-friendly for admins, striking a balance between security, granularity, and usability.

In RBAC, a user will only have access to the resources that he absolutely needs, making RBAC a scalable model for large organizations. Further, there is no direct link between a user and his permissions. If a user’s role is changed, there are no changes to the policies—only the user will be assigned a different role and his previous role access will be revoked.

Why is RBAC important?

Role-based access control limits user access to only those who are authorized, which restricts system access, thus preventing potential attacks and threats, particularly to sensitive data. Let’s understand how role-based access control helps in securing the resources through an example from the time a user joins an organization to the point where he leaves the organization.

User onboarding

When a new user joins an organization or institution, based on his designation, one or more roles are assigned.

Consider an example of a corporate office, where a new employee joins as a team leader managing a team of five members. He reports to his senior manager, who handles three teams—A, B, and C—comprising four, five, and three members respectively.

• The senior manager has the role “manager” which allows him to access the data of all the teams and their team leads. Additionally, he can access project data of all the three teams that he is handling.
• The team leader has the role “team lead” which allows him to access the data of his team members and the project data of the project he is leading.
• Each team member has the role “member” which allows them to access their own details and the project data of their project.

Security

For daily operations, each user can only access their resources as per their role assignments. If they need more privileges, they will be assigned additional roles. Each role has only specific privileges. RBAC allows roles and privileges to be customized as per an organization’s policies. Let’s say Team A needs to access specific resources from Team B’s project. Since they do not have access by default, one of the team members or the team lead can be given the specific role for a particular time limit to access the required files. This makes access control and security simple and effective.

Regulatory compliance and audit

A user has no direct link with privileges, ensuring compliance with laws and policies. The policy remains the same, irrespective of the user’s roles. For example, if the team lead is promoted to a manager post, his roles will change. Thus, the role that was previously given to the senior manager will now be assigned to the team lead, without any changes to the policies.

Further, if a user tries to knowingly or unknowingly access resources that he is not authorized for, it also becomes easy to track and audit, as each user’s roles can be easily monitored. For example, if a member from Team A tries to access the project details of Team B, this activity will be logged and any suspicious activities can be tracked. This ensures that security is maintained at all times.

User offboarding

It is a cakewalk to revoke access when employees leave the organization in a role-based access control system. The roles and policies still remain the same, with only the user being deleted from the system.

Role-based access control in MongoDB

MongoDB provides role-based access control to manage MongoDB databases and services. A user can access all of MongoDB’s systems only using the assigned roles. MongoDB does not enable access control by default for self-managed deployments. View our documentation to know how to enable access control on various MongoDB deployments.

In MongoDB Atlas, access controls are enabled by default and cannot be disabled.

If access control is enabled (self-managed deployments), users need to mandatorily authenticate themselves to perform actions that they are authorized to.

MongoDB provides built-in roles for the most commonly used privileges and also gives an option to create custom (user-defined) roles if the built-in roles are not sufficient.

Built-in roles

MongoDB provides built-in roles and privileges for self deployments as well as MongoDB Atlas. Some common built-in roles are read, readWrite, and dbAdmin/atlasAdmin roles. Database admin roles have higher privileges compared to any other database user roles, including the privilege to control the privilege of other roles.

The database user and database administration roles are applicable for all databases. However, other access control roles are available only for admin databases. For example, read, readWrite, dbAdmin are available for all databases. However, cluster administration roles like clusterAdmin, clusterMonitor, and backup roles like backup or restore are available only for admin databases.

The internal databases like local and config are read only for all users, except the clusterAdmin, who has the highest privileges to monitor access control on clusters.

MongoDB Atlas additionally supports the atlasAdmin, readWriteAnyDatabase, and readAnyDatabase roles, each having a subset of privileges from the roles specified for self-managed deployments. Atlas also provides the organizational and project roles for user access control.

For details on role permissions, refer to our documentation for self-managed deployments and MongoDB Atlas built-in roles.

User-defined roles

MongoDB also supports creating custom roles to grant access to users, when the pre-defined roles do not provide the necessary access. You can create custom roles on both MongoDB Atlas and other self-hosted deployments.

Modifying access for existing users

To update the role assignments of any user, you need to have the userAdmin role. This role gives you privileges to grant a role (grantRole) or revoke a role access (revokeRole) on the database. You should also have the viewRole privilege to know the role information.