The term Role-Based Access Control (RBAC) refers to an authorization strategy that organizes privileges based on a role (hence the 'role-based' prefix). The RBAC authorization strategy is commonly used by medium-sized to large organizations that need to categorize their personnel using role assignment. Roles are then associated with access rights and permissions to use resources. Assigning a role to individual users ensures they have only those permissions required to perform their jobs. This is an important part of an overall cybersecurity strategy.

These roles may reflect the organizational structure and often also different departments. In other words, an employee in a given department may be assigned system access rights based on the role requirements, allowing them access to the relevant information to execute work tasks. For example:

• An employee in the HR department may have access rights to payroll information, which is deemed sensitive data. The company would probably restrict this access to people within this department only, and block other employees from accessing this data.

• However, a Sales department manager may have access rights to sales reports that are not accessible by HR personnel.

However, RBAC is not specifically department-led. It is much more about roles and permissions associated with those roles. For example, the role power of attorney could be assigned privileges associated with representing a company on legal grounds. The users from the legal department will all be in the power of attorney role; however, others (e.g., the CEO and the board) could also have that role.

Role-Based Access Control is part of a wider Identity and Access Management (IAM) strategy. Below, we discuss role-based access management (RBAC) and how it can be used to apply levels of permission control over corporate resources and sensitive information.

Here we describe how you would use RBAC to control privileges in a system that supports expenses management. This fictitious system enables personnel to perform the following actions:

• Read Expenses
• Create Expenses
• Approve Expenses
• Pay Expenses

These actions represent the permissions available for the system users.

We can group these permissions in the following roles:

• Expenses Submitter (it can read and create expenses)
• Expenses Approver, and (it can read and approve expenses)
• Expenses Payer (it can read and pay expenses)

An RBAC system allows us to create those roles that have associated access permissions to corporate resources. Once configured, system managers can assign users to these roles with this associated set of permissions.

The most significant advantage of the RBAC strategy is the ability to group different permissions so that they can be assigned and revoked collectively. Also, by changing the set of permissions in a role, it allows us to change permissions to a group of users in one step. This decreases the effort related to handling permissions in your system.

For example, imagine that your company decides that it won't accept new expenses (perhaps the personnel that used to submit them now have corporate cards). In this situation, to block users sending new expense claims in, a system manager would simply remove the "Create Expense" permission from the "Expense Submitter". The users of the application would still be able to check the expenses they submitted previously, but wouldn't be able to create new ones.

Another advantage of using Role-Based Access Control is that auditing user privileges becomes more manageable. If you find issues with the permissions assigned to users, correcting them requires a single role edit. Alternatively, if you were controlling permissions on a per-user basis, you would have to audit hundreds or even thousands of users. Of course, this is the result of a well-designed role definition.

Auth0, an identity platform chosen by customers in every market sector, ships RBAC as part of its core. Auth0 helps to simplify the implementation of RBAC to manage role-based permissions.

For example, to secure your application API with RBAC and Auth0, so that, users with a given role can access the API but others cannot, you will need to follow a simple recipe that contains only four steps:

1. First, you will need to register the API in your Auth0 dashboard.

2. After registering it, you will need to define the permissions that this API will use.

3. With the permissions mapped, your next task will be creating the roles that will organize these permissions.

4. Lastly, you will need to assign users to these roles.

Computer scientists have developed many authorization strategies to secure their access control systems. RBAC is just one of these strategies. Among the alternatives, there would be Attribute-Based Access Control (ABAC). This strategy uses a user attribute (e.g., qualification) rather than a user role to grant user permissions to access resources. An example use case: a contractor is required to prove they have a specific license to perform the work in an organization. Holding the license would be the attribute that allowed user access permissions to be granted.

If you want to learn more about authentication or authorization, check the following articles:

• What is Authentication?
• What is Authorization?

Keep reading at our Intro to IAM page to explore more topics around Identity and Access Management.