RBAC-based general enterprise permission management system

ArticleDirectory

• 1. Why do we need a general enterprise permission management system based on RBAC model?
• 2. What knowledge points do we need to know?
• 3. How do we design a general enterprise permission management system based on RBAC model?
• 4. Advantages and Disadvantages

1. Why do we need a general enterprise permission management system based on RBAC model?

The management information system is a complex human-computer interaction system, where each specific link may be threatened by security. It is very important to build a robust permission management system to ensure the security of the management information system. The permission management system is used to manage information systems.CodeOne of the most Reusable Modules. Any multi-user system inevitably involves the same permission requirements, all need to solve entity identification, data confidentiality, data integrity, anti-denial and access control and other security services (according to ISO7498-2 ). For example, the access control service requires the system to control the resources that the operator can access based on the Operation permissions set by the operator and determine how to operate the resources.

At present, the permission management system is also one of the modules with the highest repetition rate. In enterprises, different application systems have an independent permission management system. Each permission management system only meets the permission management needs of its own system. This inconsistency may have the following drawbacks:

L The system administrator must maintain multiple permission management systems.

L user management, organization and other data duplication maintenance, data consistency and integrity are not guaranteed.

L different permission management systems are designed with different concepts and different technologies. integration between permission management systems is difficult to implement Single-point logon, it also brings difficulties for enterprises to build enterprise portals.

Adopts unified security management design ideas, standardized design, and advanced technical architecture system, build a general, complete, secure, easy-to-manage, portable, and scalable permission management system that truly becomes the core of permission control, it is necessary to play an important role in maintaining system security.

2. What knowledge points do we need to know? 2.1. RBAC model

The standard RBAC model consists of four component models: the basic model rbac0 (core RBAC) and the role grading model rbac1 (hierarchal RBAC), role restriction model rbac2 (constraint RBAC) and unified model rbac3 (combines RBAC)

A. rbac0 defines the smallest element set that can constitute an RBAC control system. RBAC contains five basic data elements: User Users (users), role roles (roles), target objects (OBS), Operation operations (OPS), and permission permissions (PRMS, permissions are granted to a role rather than a user. When a role is assigned to a user, the user has the permissions contained in the role. Session sessions is the ing between the user and the activated role set. The difference between rbac0 and traditional access control is that adding an indirect layer brings flexibility. rbac1, rbac2, and rbac3 are successively extended on rbac0.

B. rbac1 introduces the inheritance relationships between roles. The Inheritance relationships between roles can be divided into general inheritance relationships and restricted inheritance relationships. Generally, the inheritance relationship only requires that the role inheritance relationship is an absolute partial-order relationship, allowing multi-inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure.

C. The responsibility separation relationship is added to the rbac2 model. Rbac2 constraints specify the mandatory rules to be followed when a role is granted or a role is granted to a user and when a user activates a role at a certain time. Separation of duties includes static and dynamic separation of responsibilities. The relationship between constraints and user-role-Permission determines the access permission of users in the rbac2 model.

D. rbac3 contains rbac1 and rbac2, which provide both the inheritance relationship between roles and the separation of responsibilities.

2.2. Organization

The organizational structure of an enterprise includes three aspects: organization, department, and position. Multiple departments can be set for one organization, which is part of the organization. A department can have multiple positions, which are the same job, job, responsibilities, and permissions of employees. One department can only set one department supervisor position. One position can be held by multiple employees. Employees refer to various employment forms in the Organization.

Related Terms

L a task is an activity carried out to achieve a specific goal or fulfill the work stated by the leadership.

L duties refer to the provisions on the affairs of employees. It is different from the position in that it emphasizes the content of the task undertaken, rather than the location of the task.

L responsibility refers to what should be done within the contract. That is to say, employees should fulfill their tasks with due diligence, quality and quantity within the scope of their duties.

L unified duties and responsibilities. It refers to a work activity composed of tasks undertaken by an employee.

3. How do we design a general enterprise permission management system based on RBAC model?

The core object model of the permission management system is established based on the permission Design Concept of the RBAC model. The object model contains the following basic elements: organization, department, post, user, and role), system functions, and permission ). The main relationships are: assigning role permissions PA (permission assignment) and assigning user role UA (User assignmen). The specific descriptions are as follows:

A. Organization: Use the subject of the system.

B. Department: it is part of the organizational unit.

C. Position: the unity of employee positions, work tasks, responsibilities, and permissions.

D. User: The owner or subject of the permission. Users and permissions are separated and bound through authorization management.

E. Role: the unit and carrier of permission allocation. Roles support hierarchical permissions through inheritance relationships. For example, the section chief role also has the section chief role and different business personnel roles in the Section.

F. system functions: resources to be protected by the system and accessible objects.

G. Permission: access permission for protected resource operations, which is bound to a specific resource instance.

H. Assign role permission PA: ing the association between operations and roles.

I. Assign User Role UA: ing between users and roles.

We impose the following restrictions on the relationship between elements:

A. Multiple departments can be set for one organization

B. Multiple positions can be set for one department

C. Only one department supervisor can be set for one department

D. One position can be held by multiple employees

E. One employee holds multiple positions

F. A user can have multiple roles

G. A role can be owned by multiple users

H. Set access permission between system functions and roles

I. system functions use resources to restrict access

The object model diagram is as follows:

4. Advantages and Disadvantages 4.1. Disadvantages

The specific authorization methods must be controlled by different resource methods, which is relatively less universal.