The central idea in RBAC is
- Permissions (or Permission sets) are associated with Roles.
- Users (or User Groups) are associated with Roles.
- A permission is basically an approval of an operation on one or more objects.
A role can be modeled in multiple ways. For example,
- Role could be based on competency. Ex: Physician Role, Pharmacist Role.
- Role could be based on authority. Ex: Operator Role, Supervisor Role
- Could be based on responsibility. Ex: Duty Physician Role, Shift Manager Role etc.
Contrast the above to DAC (discretionary access control) model which is often captured as a set of ACL (access-control list).
Although RBAC is policy neutral, it supports 3 key security principles -
- Principle of least privilege
- Separation of duties
- Data abstraction.
- Ease of determining role membership and permissions
- Ease of control on role memberships and permissions assignments.
- Ease in doing audits.
So far we talked about base RBAC model. Two important tangential notions of Roles are -
- Role Hierarchies and
- Role Constraints
Role hierarchies are basically a means to model the hierarchies or lines of authority present in the real world. For example. say want want to model a supervisor role to inherit all the permissions of an operator role. Role hierarchies will be useful here.
Role constraints are another key aspect of RBAC model. For example, say we want to define two mutually exclusive roles ("Accounts" and "Purchasing") such that same user cannot be part of both roles. Role constraints on user assignment to roles would help here.
Some challenges with RBAC model are -
- Requires advance knowledge of Resources and Users.
- Can result in too many roles to accomplish fine grained authorization.
- The resource owners need to know about all roles.
- The roles and resources need to be modeled as hierarchies for delegation.
RBAC is role centric. Another popular model especially in recent years is ABAC (attribute-based access control). With ABAC, there is no need to engineer roles before hand. This characteristic is especially appealing in large distributed systems.
ABAC uses labeled objects and user attributes to determine if access control should be provided. Attributes could be like time of the day, user location etc. In ABAC, if a user has attributes that are reflected in the objects they want to access, then access is granted. On other hand, in RBAC, the user is pre-assigned a set of roles (and thus permissions). Also in ABAC permissions are acquired dynamically because of attributes.
One common mistake people do when leveraging ABAC concepts within RBAC framework is using the role names as attributes. Once you use roles as attributes of object, the primary benefit of RBAC (i.e., roles as collection of permissions) is gone. For example, in RBAC, given a user, we can easily find all the permissions that user has. Similarly a limited number of roles can represent many users or user types. You no longer have these benefits when roles are treated as attributes.
One approach to leverage the benefits of ABAC model without loosing RBAC model benefits is to model attributes as role constraints in RBAC model. Following is a summary diagram of this model. More details can be found in the references (2).
On implementation front, Apache Shiro is a good library to leverage for incorporating RBAC functionality. There is ample documentation available on the net on how to use Apache Shiro. Note: The role based implementation in Apache Shiro is not same as RBAC model described here. To achieve the equivalent of RBAC described here one need to write a custom authorization realm.
References:
- Role-Based Access Control Models, Ravi Sandhu, E J Coyne, H Feinstein, C Youman.
- ABAC and RBAC: Scalable, Flexible and Auditable Access Management, E J Coyne, T R Weil.
- Best practices in Enterprise Authorization: The RBAC/ABAC Hybrid approach, Whitepaper - EmpowerID.
- Apache Shiro - http://shiro.apache.org/documentation.html
