Recently, because the project needs to design and implement a rights management module, we have specially compiled and summarized some knowledge of RBAC.
At present, the most commonly used rights management model is the RBAC (Role-Based Access Control) model. This article also mainly introduces a rights management system based on RBAC. I will introduce it from two parts: what RBAC is and how to design RBAC.
1. What is RBAC
1. Overview of the RBAC model
The RBAC (Role-Based Access Control) model is a new model developed in the 1990s, but in fact, this idea was proposed during the multi-user computing period in the 1970s. It was not until the mid-to-late 1990s that RBAC received some attention among the research community, and many types of RBAC models were proposed one after another. Among them, the RBAC96 model proposed by the Information Security Technology Laboratory (LIST) of George Mason University in the United States is the most representative and is generally recognized.
RBAC believes that the process of permission authorization can be abstractly summarized as: whether Who can access what, and determine whether this logical expression is True. That is, it is the process of transforming the permission issue into What and How. Who, What and How constitute the triple of access rights. For the specific theory, you can refer to the paper of RBAC96. We will not give a detailed introduction here, so everyone can have an impression.
2. Composition of RBAC
In the RBAC model, there are three basic components: users, roles and permissions.
RBAC controls the user's privileges by defining the privileges of roles and granting a certain role to the user. It realizes the logical separation of users and privileges (different from the ACL model) and greatly facilitates the management of privileges.
Before explaining, let's introduce some terms:
- User: Each user has a unique UID identification and is assigned a different role
- Role: Different roles have different permissions
- Permission: Access permission
- User-role mapping: The mapping relationship between users and roles
- Role-permission mapping: Mapping between roles and permissions
The relationship between them is as 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, create and freeze users. However, since administrators are granted all permissions, they can do all operations.
For example, in the figure below (role operation example), administrators and ordinary users are granted different permissions. Ordinary users can only modify and view personal information, but cannot create users or freeze users. Since administrators are granted all permissions, they can do everything.
3. Security principles supported by RBAC
RBAC supports three well-known security principles: minimum authority principle, separation of responsibilities principle, and data abstraction principle
- Minimum privilege principle: RBAC can configure roles to the minimum set of privileges they need to complete tasks
- Principle of separation of responsibilities: You can jointly complete sensitive tasks by calling independent and mutually exclusive roles, such as requiring an accountant and a financial manager to participate in a unified posting operation
- Data abstraction principle: It can be reflected through the abstraction of permissions. For example, financial operations use abstract permissions such as borrowing and deposits, rather than using typical read, write, and execute permissions.
4. Advantages and disadvantages of RBAC
- *(1) Advantages: **
- Simplified the relationship between users and permissions
- Easy to expand and maintain
- *(2) Disadvantages: **
The RBAC model does not provide a control mechanism for the order of operations, which makes it difficult for the RBAC model to adapt to systems that have strict requirements for the order of operations
5. Three models of RBAC
（1）RBAC0
RBAC0 is the simplest and most primitive implementation method and the basis of other RBAC models.
In this model, the relationship between users and roles can be many-to-many, that is, a user can have different roles in different scenarios. For example, the project manager may also be the team leader or the architect. At the same time, each role has at least one authority. Under this model, users and permissions are separated and independent, making the authorization and authentication of permissions more flexible.
（2）RBAC1
Based on the RBAC0 model, the inheritance relationship between roles is introduced, that is, there are differences between superiors and subordinates in roles.
Inheritance relationships between roles can be divided into general inheritance relationships and restricted inheritance relationships. The general inheritance relationship only requires that the role inheritance relationship be an absolute partial order relationship, allowing multiple inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship be a tree structure to achieve single inheritance between roles.
This model is suitable for clear hierarchies between roles, and roles can be grouped into layers.
（3）RBAC2
RBAC2, based on the RBAC0 model, carries out role access control.
A basic limitation in RBAC2 is the limitation of mutually exclusive roles, which refer to two roles whose respective permissions can restrict each other. For such roles, a user can only be assigned one role in a certain activity, and cannot obtain the right to use both roles at the same time.
The model has the following constraints:
- Mutually exclusive roles: The same user can only be assigned to at most one role in a set of mutually exclusive roles, supporting the principle of separation of responsibilities. Mutually exclusive roles refer to two roles whose respective permissions restrict each other. For such roles, a user can only be assigned one role in a certain activity, and cannot obtain the right to use both roles at the same time. Common example: In an audit activity, a role cannot be assigned to both the accounting role and the auditor role.
- Cardinality constraint: The number of users assigned to a role is limited; the number of roles a user can have is limited; the number of access rights corresponding to a role should also be limited to control the allocation of advanced rights in the system. For example, the company has limited leaders;
- Prerequisite role: A role can be assigned to a user only if the user is already a member of another role; corresponding access rights can be assigned to a role only if the role already has another access rights. It means that if you want to obtain a higher authority, you must first have a lower level of authority. Just like in our lives, the president of the country is elected from among the vice-presidents.
- Run-time mutual exclusion: For example, a user is allowed to have membership in two roles, but both roles cannot be activated at the same time during runtime.
2. How to design RBAC
In this section, I will introduce the functional module composition, process and database design of designing an authorization system based on the RBAC model.
1. Functional modules of RBAC
2. RBAC execution process
3. RBAC database design
