Recently, because I needed to design and implement a permission management module for a project, I specifically organized and summarized some knowledge about RBAC.
Currently, the most widely used permission management model is the RBAC (Role-Based Access Control) model. This article mainly introduces a permission management system based on RBAC. I will explain it from two parts: what RBAC is and how to design RBAC.
1. What is RBAC?
1.1 Overview of RBAC Model
The RBAC model (Role-Based Access Control) is a new model developed in the 1990s. However, this idea was actually proposed as early as the multi-user computing era in the 1970s. It wasn't until the mid-to-late 1990s that RBAC gained some attention in research communities, and various types of RBAC models were proposed. Among them, the RBAC96 model proposed by the Laboratory for Information Security Technology (LIST) at George Mason University is the most representative and widely recognized.
RBAC considers that the process of permission authorization can be abstractly summarized as: whether "Who" can perform "How" operations on "What", and the process of determining whether this logical expression is true. In other words, it transforms the permission issue into a "What" and "How" problem, where "Who", "What", and "How" form the access control triple. For specific theories, you can refer to the RBAC96 paper; we will not go into detail here, just keep it in mind.
1.2 Components of RBAC
In the RBAC model, there are three basic components: users, roles, and permissions.
RBAC controls user permissions by defining the permissions of roles and assigning roles to users, thus achieving a logical separation between users and permissions (different from the ACL model), greatly facilitating permission management.
Before explaining further, let's introduce some terms:
- User: Each user has a unique UID and is assigned different roles.
- Role: Different roles have different permissions.
- Permission: Access permissions.
- User-Role Mapping: The mapping relationship between users and roles.
- Role-Permission Mapping: The mapping between roles and permissions.
The relationship between them is shown in the following figure (User, Role, Permission relationship):
For example, in the figure below, administrators and ordinary users are granted different permissions. Ordinary users can only modify and view personal information, but cannot create users or freeze users. Administrators, being granted all permissions, can perform all operations.
For example, in the figure below (Example of Role Operations), administrators and ordinary users are granted different permissions. Ordinary users can only modify and view personal information, but cannot create users or freeze users. Administrators, being granted all permissions, can perform all operations.
1.3 Security Principles Supported by RBAC
RBAC supports three well-known security principles: the principle of least privilege, separation of duties, and data abstraction.
- Principle of Least Privilege: RBAC can configure roles to have the minimum set of permissions required to complete their tasks.
- Separation of Duties: Sensitive tasks can be accomplished by invoking mutually independent and mutually exclusive roles, such as requiring an accountant and a financial manager to jointly participate in a unified posting operation.
- Data Abstraction: This can be reflected through the abstraction of permissions, for example, using abstract permissions like "borrow" and "deposit" for financial operations instead of typical read, write, and execute permissions.
1.4 Advantages and Disadvantages of RBAC
(1) Advantages:
- Simplifies the relationship between users and permissions.
- Easy to extend and maintain.
(2) Disadvantages:
The RBAC model does not provide a control mechanism for the order of operations. This deficiency makes the RBAC model difficult to adapt to systems that have strict requirements on the sequence of operations.
1.5 Three Models of RBAC
(1) RBAC0
RBAC0 is the simplest and most primitive implementation method and is also the foundation for other RBAC models.
In this model, the relationship between users and roles can be many-to-many, meaning a user can have different roles in different scenarios. For example, a project manager could also be a team leader or an architect. At the same time, each role has at least one permission. In this model, users and permissions are separated independently, making permission authorization more flexible.
(2) RBAC1
Based on the RBAC0 model, RBAC1 introduces inheritance relationships between roles, meaning roles have a hierarchical distinction.
The inheritance relationships between roles can be divided into general inheritance and restricted inheritance. General inheritance only requires that the role inheritance relationship be a strict partial order, allowing multiple inheritance between roles. Restricted inheritance further requires that the role inheritance relationship be a tree structure, enabling single inheritance between roles.
This model is suitable for scenarios where roles have clear hierarchies and can be grouped and layered.
(3) RBAC2
Based on the RBAC0 model, RBAC2 adds access control for roles.
A basic constraint in RBAC2 is the restriction of mutually exclusive roles. Mutually exclusive roles refer to two roles whose permissions can constrain each other. For such roles, a user can only be assigned one of the roles in a given activity and cannot simultaneously have the usage rights of both roles.
This model includes the following constraints:
- Mutually Exclusive Roles: A user can only be assigned at most one role from a set of mutually exclusive roles, supporting the principle of separation of duties. Mutually exclusive roles refer to two roles whose permissions constrain each other. For such roles, a user can only be assigned one of the roles in a given activity and cannot simultaneously have the usage rights of both roles. A common example: in auditing activities, a role cannot be simultaneously assigned to an accountant role and an auditor role.
- Cardinality Constraints: The number of users assigned to a role is limited; the number of roles a user can have is limited; similarly, the number of access permissions corresponding to a role should also be limited to control the distribution of high-level permissions in the system. For example, the number of leaders in a company is limited.
- Prerequisite Roles: A role can be assigned to a user only if the user is already a member of another role; similarly, access permissions can be assigned to a role only if the role already possesses another access permission. This means that to obtain higher permissions, one must first have lower-level permissions. For example, in real life, the President is elected from the Vice Presidents.
- Runtime Mutually Exclusive: For example, a user may have membership in two roles, but these two roles cannot be activated simultaneously during runtime.
2. How to Design RBAC
In this section, I will introduce the functional module composition, workflow, and database design of a permission system based on the RBAC model.
2.1 Functional Modules of RBAC
2.2 RBAC Execution Flow
2.3 RBAC Database Design
