What Is Role-Based Access Control?
Role-based access control (RBAC) is a set of rules that govern and restrict user access to operations and objects based on their identity, intent, and session attributes. According to the U.S. National Institute of Standards and Technology (NIST), the concept was formalized in 1992 by information security researchers David F. Ferraiolo and D. Richard Kuhn. Today, role-based access control is among the most popular access control mechanisms due to its cost advantages, versatility, and efficiency.
Key Components of Role-Based Access Control
Role-based access control is based on key components that will determine the interactions between users and the resource or process they are trying to access. While the list of components will vary across organizations, here are the six foundational ones you need to remember:
1. Users
The user is the entity asking for access. The user may or may not proactively request access – for example, an access request may be initiated the moment a user logs in. Also, users aren’t necessarily human individuals. For RBAC, services and computing entities like a virtual machine or an end-device can also be considered as a user. In a scenario where the device tries to rewrite its registry contents as part of an upgrade, the device is considered a user and requires RBAC-approved privileges.
2. Roles
Roles are what determine which privileges and permissions can be assigned to a user. Roles typically exist in hierarchies, where a superior role is associated with more privileges than a lower role in the hierarchical structure. For example, a document owner might be able to do whatever they want with a document (edit, share, save offline, etc.), while a contributor may edit without the right to share the document. In this scenario, the owner role is superior to the contributor role.
In the context of RBAC, roles are an aggregate function of multiple user traits – their job designation, session attributes like the device from which they are logged in, their login credentials, and so on. RBAC solutions can include pre-built roles that you can assign to your users and support custom ones.
3. Operations
Users can request access for two things – operations and objects.
Operations refer to any activity or process carried out in a computing environment. For example, changing system configurations and closing active processes are two of the most common operations we perform in a typical computing environment. Depending on the IT landscape, operations can be highly complex with significant security fallouts, requiring powerful protection.
4. Objects
As mentioned, users can also ask to access an object, a static file, a data set, a website, or any other asset. There is a key difference between operations and objects: while performing an operation changes the system state, object access does not. This makes unauthorized object access more difficult to detect, which is why you need role-based access control. RBAC ensures that the user’s role is relevant to the object in question and that the user is authorized to access it. It also maintains access logs, including the date and time of the last access.
5. Permissions
Permissions are at the heart of role-based access control, without which it would not be able to operate. It is a set of business rules that specify which operations and objects a role can access. For example, if a person with employee ID A12 is the user and is assigned the contributor’s role, permissions refer to the list of actions that the user can perform in that role. As a contributor, they may be able to access the document (an object) and modify the contents (an operation) but not be allowed to open embedded links (objects) or delete the document (an operation).
In other words, permissions define the relationship between a role and the relevant operations and objects.
6. Sessions
Sessions refer to the duration for which a role’s interaction with operations and objects will last. RBAC is triggered right at the beginning of a session and remains functional until the session ends. If a user opens a browser on the company network and tries to access a page on the intranet, the session begins as soon as they open the browser. The RBAC system will check the user’s role, grant access based on permissions, monitor the operations and objects accessed, and maintain a log until the user closes the browser. This entire period of interaction is called a session.
Who we are
The Live Learn Innovate Foundation is a 501(c)3 nonprofit entity that empowers software users to regain control of their personally generated health data, gain intuitive insights about their social data, learn the impact of their environment on health, and build a foundation of data analytics that empowers research, academics, and innovation in economic development.
Use cases for this secure, private method of data aggregation appear everywhere, expanding to family care, community growth, agricultural planning, and many more things still unseen. Help us keep going by getting involved today.