Design and Implementation of the role-function-resource-based permission control model-Introduction

Summary

Based on the basic concept of RBAC, this article introduces the concept of resource permissions and designs a simple implementation method for user permission control in enterprise application systems.

Keyword user permission Control

Glossary

Resource permission: resources refer to all information entities that need to be managed for enterprise applications, such as purchase orders in the inventory system; resource permissions are the access and use permissions that the system will control based on these resources;

Introduction

Enterprise Application Systems have high security requirements. The traditional access control method DAC (discretionary access control, autonomous access control model), MAC (mandatory access control, Mandatory Access Control Model) it is difficult to meet complex enterprise environmental requirements. Therefore, the NIST (National Institute of Standards and Technology, national standardization and Technology Commission) proposed a role-based access control method in the early 1990s S, the logical separation between users and access permissions is achieved, which is more in line with the enterprise's user, organization, data, and application features.

This paper first introduces the basic idea of RBAC (Role Based Access Control), on this basis, gives the implementation of R-F-RBAC (Role-function-Resource Based Access Control) in the enterprise application system, A specific method based on role-function-resource permission control.

The basic concept of RBAC can be simply expressed in Figure 1, that is, the entire access control process is divided into two steps: access permissions are associated with roles, and roles are associated with users, this logically separates users from access permissions.

 

RBAC achieves logical separation between users and access permissions, which greatly facilitates permission management. For example, if a user's position changes, you only need to remove the current role of the user and add the role representing the new position or new task, changes Between roles and permissions are much slower than changes between roles and user relationships. Assigning a user to a role does not require many techniques and can be performed by administrative staff, however, configuring permissions to roles is complicated and requires some technical skills, which can be undertaken by dedicated technical personnel, but users are not assigned permissions, this is exactly the same as in reality.

The design idea of R-F-RBAC is a development based on RBAC and introduces the concept of resource. What are the so-called resources? In general, they can be information that is incorporated into system management. At the technical implementation level, they can be a table, one or one column of records, or even a table cell. In practice, it is not enough for enterprise applications with high security level to only control permissions to the function. It is required that some users can only operate on the specified system content.

Case Analysis

Here we use a simple application model instance for in-depth analysis of the R-F-RBAC, that is, for an enterprise application assuming a high security level contract management sub-module, this module involves the following elements:

· Contract Documents: There are three levels (project level, department level, and company level) based on business requirements );

· Specific functions: Draft, report, sign, and approve functions based on actual functional requirements;

· Operation role: Project Manager, Department Manager, and general manager are set based on the company's administrative position;

· OPERATOR: company's internal personnel a Project Manager Zhang San, department a Manager Li Si, General Manager Wang Er;

System Security Requirements:AProject Manager Zhang SanOnly project-level contract documents limited to project a can be drafted and reported,Department a Manager Li SiOnly project-level or department-level contract documents under Department A can be drafted, reported, and signed.Wang 'er, General ManagerYou have the right to operate the three levels of contract documents of the entire company at will. This model can be summarized into the following table:

personnel	role	function	resource
Wang 'er	General Manager	draft, report, sign, and approve	three levels of contract documents
Li Si	department manager	drafting, reporting, and signing	project-level or department-level contract documents under Department A
Zhang San	Project Manager	Drafting and reporting	Only project-level contract documents of Project

Solution

For this reason, we need to design the following key data tables:

· User table: records user-related information. userid is the unique user ID;

· Role table: record the role information. roleid is the unique role ID;

· Module and function list: records information about the module and related functions of the module, which are divided into the master-child relationship table;

· Resource table: records all resource information in the system that requires high security control. restable indicates the name of the data table corresponding to the resource (such as the contract information table ), resterm is the condition for the given resource (for example, a project-level or department-level contract file under Department A) to limit the scope of data extraction;

Because the design idea of the R-F-RBAC mentioned in this article considers that the user can grant multiple roles, so we need to create a user-role table to record a user may correspond to a number of role information, you also need to create a role-function table and a role-resource table to thoroughly strip the relationship between users and access permissions;

The database relationship diagram (only involving key fields) is as follows:

 

ProgramImplementation

CodeThe implementation should be divided into three parts:

· Permission Data Maintenance: This part mainly maintains basic information such as users, roles, functions, and resources and provides a convenient operation interface for the system administrator;

· Permission data processing: it refers to implementing the permission calling interface within the program. For example, providing operable data and functions based on the modules and user information provided by the caller;

· Permission Data Reference: In the UI Layer, You can process the combined permissions of users. For example, you can control the explicit and hidden active availability of buttons, menus, and other functional elements on the UI Based on the obtained functional permission information, or, based on the obtained combination of resource permission conditions, a certain number of users can only operate on the control level of the specified system content;

The description of RBAC comes from http://www.infosecurity.org.cn/article/pki/accessctrl/23637.html. I would like to thank the author!