Manual set of RBAC permission system

Article source: "RBAC authority system analysis, design and implementation" | shuwoom.com

At present, the most commonly used permission management model is the RBAC (Role-Based Access Control) model. This article also mainly introduces the RBAC-based permission management system. I will introduce what RBAC is and how to design RBAC.

1. What is RBAC

1. Overview of RBAC model

The RBAC model (Role-Based Access Control: role-based access control) model is a new model developed in the 1990s, but in fact, this idea has been proposed in the multi-user computing period in the 1970s , until the middle and late 1990s, RBAC did not get some attention in the research community, and many types of RBAC models were proposed successively. 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 has been generally recognized.

RBAC believes that the process of authority authorization can be abstractly summarized as: whether Who can perform How access operations on What, and the solution process of judging whether this logical expression is True, that is, converting the authority problem into What and How Question, Who, What, and How constitute the triplet of access rights. For specific theories, please refer to the paper of RBAC96.

2. The composition of RBAC

In the RBAC model, there are three basic components: users, roles, and permissions.

RBAC controls the user's permission by defining the permission of the role and granting a certain role to the user. It realizes the logical separation of users and permissions (different from the ACL model), which greatly facilitates the management of permissions.

Before explaining, let me introduce some nouns:

• User (user): Each user has a unique UID identification and is granted different roles

• Role: Different roles have different permissions

• Permission: access rights

• User-role mapping: the mapping relationship between users and roles

• Role-permission mapping: mapping between roles and permissions

The relationship between them is shown in the figure below:

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 and freeze users. Administrators can do all operations because they are granted all permissions.

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 and freeze users. Administrators can do all operations because they are granted all permissions.

3. Security principles supported by RBAC

RBAC supports three well-known security principles: the principle of least privilege, the principle of separation of duties and the principle of data abstraction

• Principle of Least Privilege: RBAC can configure a role as the minimum set of privileges it needs to complete a task

• Principle of separation of responsibilities: Sensitive tasks can be accomplished together by invoking mutually independent and mutually exclusive roles, such as requiring a bookkeeper and a financial administrator to jointly participate in unified posting operations

• The principle of data abstraction: it can be reflected by the abstraction of permissions, such as abstract permissions such as borrowing and deposits for financial operations, instead of using typical read, write, and execute permissions

4. Advantages and disadvantages of RBAC

(1) Advantages:

• Simplifies 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 on the order of operations

5. Three models of RBAC

(1) RBAC0

RBAC0 is the simplest and most primitive implementation and the basis of other RBAC models.

In this model, there can be a many-to-many relationship between users and roles, that is, a user can have different roles in different scenarios, for example: a project manager may also be a team leader or an architect. At the same time, each role has at least one permission. Under this model, users and permissions are separated and independent, making authorization and authentication of permissions more flexible.

（2）RBAC1

Based on the RBAC0 model, the inheritance relationship between roles is introduced, that is, there is a distinction between upper and lower roles on roles.

The inheritance relationship between roles can be divided into general inheritance relationship and restricted inheritance relationship. The general inheritance relationship only requires that the role inheritance relationship is an absolute partial order relationship, allowing multiple inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure to achieve single inheritance between roles.

This model is suitable for a clear hierarchy between roles, and can group and stratify roles.

（3）RBAC2

RBAC2, based on the RBAC0 model, performs role access control.

A basic limitation in RBAC2 is the limitation of mutually exclusive roles. Mutually exclusive roles refer to two roles whose respective permissions can restrict each other. For this type of role, a user can only be assigned one of the roles 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, which supports the principle of separation of responsibilities. Mutually exclusive roles refer to two roles whose respective permissions restrict each other. For this type of role, a user can only be assigned one of the roles in a certain activity, and cannot obtain the right to use both roles at the same time. A common example: In auditing activities, a role cannot be assigned to both the accountant role and the auditor role at the same time.

• Cardinality constraints: the number of users assigned to a role is limited; the number of roles that a user can have is limited; the number of access rights corresponding to a role should also be limited to control the distribution of advanced rights in the system. For example, the company's leaders are limited;

• Prerequisite roles: A role can be assigned to a user only if that user is already a member of another role; correspondingly, an access right can be assigned to a role only if that role already has another kind of access right. It means that in order to obtain a higher authority, one 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.

• Runtime mutual exclusion: For example, a user is allowed to have membership in two roles, but both roles cannot be active at runtime.

2. How to design RBAC

In this section, I will introduce the functional module composition, process and database design of the permission system based on the RBAC model.

1. Functional modules of RBAC

2. RBAC execution process

3. RBAC database design