Role-Based Access Control

Role-Based Access Control (RBAC) enforces security by assigning permissions to users based on their defined roles, ensuring that only authorized individuals can access specific information system resources.

Organizations can create specific roles based on job functions and the authorizations (i.e., privileges) to perform needed operations on organizational information systems associated with the organizationdefined roles.

RBAC can be implemented to varying degrees to meet an organization's needs, as depicted in the three figures that follow. In the first figure, the top portion shows an organization that is not using any form of RBAC.

Access can be granted by the owner as with Discretionary Access Control (DAC) and applied with the policy according to Mandatory Access Control (MAC).

Individual users are granted permissions to run (load and execute) sets of application programs.

For example, the organization may not want its accounts payable staff developing software, so on a per-user ID basis, they block them from running integrated development tools such as Visual Studio.

The lower portion of the first figure shows limited use of roles, where applications are associated with specific roles. In this case, the accounts payable role has permission to run QuickBooks (Application 1, Role A), while developers (Role B) can run and test software development applications.

Non-RBAC

Management Application 1

Application 2

Limited RBAC Management Application 1

Application 2

Application 3

Figure: RBAC use cases: none and limited

Each user ID is associated with one or more roles, but some applications remain available to all users regardless of role.

For example, everyone may be able to run Firefox or Chrome.

Users are mapped to applications

Role A

Role B Users are mapped to application roles

Users ALSO mapped to applications that have not developed Role Based Access

The second figure depicts more extensive use of RBAC. The top portion shows a hybrid approach, where individuals may have one or more roles, and each role is permitted to use specific applications. The rights and privileges associated with Role A, for instance, would differ from those of Role B, even if both use the same application.

Hybrid RBAC Management Role A

Application 3 A point-of-sale system may define separate roles for a sales clerk and a sales supervisor, but only the supervisor role would allow use of override or transaction void features.

The lower portion of the second figure shows a full implementation of RBAC, where all user IDs are mapped to roles, and those roles are then mapped to applications.

Application 1

Application 2

Role B Users are mapped to multi-application roles

Only select application access rights are moved to the multi-application role

Role A

Full RBAC Management

Figure: RBAC use cases: hybrid and full

Application 1

Users are mapped to enterprise roles Application 2

Application 3

The third figure illustrates the wide variety of ways RBAC can be applied in organizations:

• None. Access to specific apps and their data is not protected by anything role based. Individual privileges must be defined and managed.
• Limited. Some apps and their data are RBAC-protected, restricted to specific, defined roles. Others are not. In this case, office productivity apps and browsers are not empowered with RBAC.
• Full. Every app, including the office apps and browsers, require role-based permission to be accessed. A human resources (HR) manager signs on in their HR role to access personnel files. To do office correspondence, they sign out of that role and sign in again with their office role.
• Hybrid. Hybrid can be any combination of features.