General software access control model and method based on RBAC

Abstract

The invention discloses a general software access control model based on RBAC (Role Based Access Control), relates to the field of general software access control, and forms a set of complete application permission basic framework design by combining front-end interface design and back-end strategy, so that permission management is more intuitive and efficient. Differential authorization is optimized by introducing the concept of internal roles, the requirement for creating multiple roles for a single user is avoided, and the maintenance cost and management difficulty of the system are further reduced.

Description

Technical Field

[0001] The present invention relates to the field of access permission models, and in particular to a universal software access control model based on RBAC.

[0002] The invention also relates to a general software access control method based on RBAC. Background Art

[0003] In the software industry, most of the application software developed will be based on the existing RBAC permission control strategy when designing permission control. However, with the development of time, the business scenarios involved in application software are becoming more and more complex. The existing permission model is as follows:

[0004] DAC (Discretionary Access Control): Users have autonomy over resources, and resource owners can freely grant or revoke access rights to other users.

[0005] MAC (Mandatory Access Control): A set of mandatory rules defined by the system administrator to control user access to resources. Users cannot change these rules. This is usually used in some environments that require high security.

[0006] RBAC (Role-Based Access Control): Assign permissions based on the user's role. Users are grouped into roles, and each role is given certain permissions. This simplifies permission management and is particularly suitable for large organizations.

[0007] ABAC (Attribute-Based Access Control): Control access rights based on user attributes. This can include user attributes, environment information, etc., providing more fine-grained control.

[0008] PBAC (Policy-Based Access Control): Control access rights based on predefined policies. Policies can include multiple rules and conditions to flexibly adapt to various access control requirements.

[0009] In the scope of general application software, the RBAC-based access control permission model is the most suitable and the most widely used in terms of usage cost and matching degree; but it will have the above-mentioned defects. The existing RBAC-based permission control model has the following problems: the RBAC-based permission control strategy can no longer meet the following needs: data scope constraints; permission validity period; temporary identity agency; the disadvantage of having to create many roles to achieve differentiated authorization; the conversion rules between the intuitive menu authorization on the interface and the underlying numerous operation permission authorizations; that is, it cannot directly respond to scenario requirements, is complex to implement, and has high costs. Therefore, a new access control model is urgently needed to solve the above problems. Summary of the invention

[0010] The purpose of the present invention is: to address the above-mentioned problems, the present invention provides a general software access control model based on RBAC, which forms a complete application permission basic framework design by combining the front-end interface design and the back-end strategy, making permission management more intuitive and efficient. In addition, by introducing the concept of internal roles to optimize differentiated authorization, the need to create multiple roles for a single user is avoided, further reducing the system maintenance cost and management difficulty.

[0011] The technical solution adopted by the present invention is as follows:

[0012] A general software access control model based on RBAC, including:

[0013] The authorized resource module counts data resources and classifies them according to needs;

[0014] A menu / button module, including a multi-level menu / button, which displays the classified data resources through the multi-level menu / button in combination with the authorized resource module;

[0015] The operation authority module classifies the actual operation actions and assigns unique codes, and performs relationship matching between the classified actual operation actions and the multi-level menu / button modules.

[0016] Furthermore, the authorization resource module includes:

[0017] According to the business scenario, the resources that require data authorization are classified and maintained in the resource classification table.

[0018] Furthermore, the operation authority module includes:

[0019] Create role information based on business scenarios, classify the role information, and maintain the classified data in the role table.

[0020] Furthermore, the classified resources in the authorized resource module are matched according to the role information in the role table, and the role table is mapped and matched with the levels of the multi-level menu / button module.

[0021] Furthermore, the operation authority module also includes: when the role table matches the authorization resource module and the menu / button module, setting the authority validity period.

[0022] Furthermore, the role table in the operation authority module also includes a built-in user proxy table, which includes matching the role information in the role table with the user proxy table, and assigning corresponding proxy codes to the role information in the role table for temporarily authorizing the role information in the role table.

[0023] The present invention also provides a general software access control method based on RBAC, which adopts a general software access control model based on RBAC. The method comprises:

[0024] Resource matching, matching the mapping of the authorized resource module with the multi-level menu / button;

[0025] User creation, fill in different user information, and allocate and maintain different role information for different users in the role table of the operation authority module. At the same time, in the role table, create an internal role for each user, and the internal role is used to distinguish the permissions of different role information;

[0026] Role resource matching: mapping and matching the internal roles with the multi-level menus / buttons respectively, and acquiring resources through the multi-level menus / buttons.

[0027] Furthermore, when a user needs to have access to other role information in the role table, the user agent table is used to obtain the permission.

[0028] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0029] The permission control model of the present invention, within the scope of general application software, solves various business scenario requirements that cannot be met by the original model, such as data range constraints, permission validity period control, temporary identity proxy support, etc., by expanding and optimizing the existing permission control model based on RBAC (Role-Based Access Control). The newly added functions and optimization measures not only improve the flexibility and accuracy of permission control, but also simplify the authorization process, reduce the complexity of system management, and enhance user experience. The model of the present invention forms a complete set of application permission basic framework design by combining front-end interface design and back-end strategy, making permission management more intuitive and efficient. In addition, by introducing the concept of internal roles to optimize differentiated authorization, the need to create multiple roles for a single user is avoided, further reducing the maintenance cost and management difficulty of the system.

[0030] In summary, the application prospects of the present invention are broad, especially in application scenarios that require highly customized and dynamic permission management, such as enterprise resource management, customer relationship management systems, and other complex systems that require fine-grained permission control. This model can provide a more flexible and efficient access control solution, which helps to improve the availability and security of the overall system. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 A schematic diagram of the network structure of a general software access control model based on RBAC in the present invention;

[0032] Figure 2 A permission table in a general software access control model based on RBAC of the present invention;

[0033] Figure 3 A menu table in a general software access control model based on RBAC according to the present invention;

[0034] Figure 4 A role table in a general software access control model based on RBAC according to the present invention;

[0035] Figure 5 A resource table in a general software access control model based on RBAC of the present invention;

[0036] Figure 6 A user table in a general software access control model based on RBAC of the present invention;

[0037] Figure 7 A user proxy table in a general software access control model based on RBAC according to the present invention;

[0038] Figure 8 A character menu mapping table in an embodiment of the present invention;

[0039] Fig. 9 is a role authority mapping table in an embodiment of the present invention;

[0040] Fig.10 This is a user role mapping table in an embodiment of the present invention. DETAILED DESCRIPTION

[0041] The present invention will be described in detail below in conjunction with the accompanying drawings.

[0042] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0043] Example

[0044] The present invention provides a general software access control model based on RBAC, such as Figure 1 As shown, the blue one is the existing standard RBAC permission control model. In the whole model, an extended design is carried out under the existing standard RBAC permission control model. In addition to the association table, the main core tables include: user table, user agent table, role table, menu table, permission table, and resource table. The specific operations are as follows:

[0045] According to the current business scenario analysis, extract the required operations, assign unique codes, and enter the data into the permission table, such as Figure 2 As shown, the permission table is used to record all permissions. Once the business is fixed, the relevant permission set is fixed; for example: report saving right, report query right, etc., are a series of control permissions for operations;

[0046] Analyze the current business scenario to determine whether data authorization is required and the types of resources to be authorized, and maintain the resource types in the resource classification table. For example, if the business requires data range control by region, then the region is considered as a resource type.

[0047] According to the current business scenario analysis, create the displayed menus / buttons, menu / button levels and menu / button routes, etc., and enter the data into the menu table, such as Figure 3 As shown, the menu table is used to display menu records in the application presentation layer and is dynamically maintained by the application administrator;

[0048] Match the menu / button of the presentation layer with the actual operation action, i.e., the operation permission, and enter the data into the menu permission association table;

[0049] Initialize the model:

[0050] Administrators can configure the following based on business scenarios, such as Figure 4As shown, create the role information needed and enter the data into the role table, such as director, clerk, etc.

[0051] Administrators assign resources and menus to roles. When configuring, they can set validity periods. Data is stored separately as follows: Figure 8 The role menu mapping table shown, Fig. 9 The role permission mapping table shown in the figure and Figure 5 The role resource mapping table shown is a resource permission mapping table. Resources are dynamically designed and generated by business scenarios. Anything can be used as a resource and authorized to a role, and then to a user.

[0052] Model usage phase:

[0053] When a user needs to be created, fill in the user information and assign the user a maintained role; data is entered as Figure 6 The user table shown, Fig.10 The user role mapping table shown in the figure also automatically creates an internal role in the user role association table that only serves the user and is not available to the outside world. This is used to implement the logic of differentiated authorization.

[0054] When a user needs to temporarily assume the identity of another person, the data enters Figure 7 The user agent table shown;

[0055] When the user needs to update the title and order of the menu / button, the administrator can adjust the menu / button properties and update the data to Figure 3 The menu table shown;

[0056] When additional permissions need to be assigned to a user, additional menus, operating permissions or resources are directly assigned to the user on the interface. Internally, authorization is actually performed by assigning the current user an internal role, which does not violate the RBAC principle. The design of internal roles also simplifies the process. There is no need to create another role separately, assign corresponding permissions to the role, and then assign roles to users. This complex operation and redundant role data are no longer required.

[0057] In summary, based on the permission control model of the present invention, through operations in the development stage and the use stage, relevant data is maintained in the permission control model, generating constraints and specifications for business control. These constraints and specifications, as business control principles, realize precise control of the business.

[0058] Compared with the existing RBAC-based permission control model, this embodiment expands its functions and optimizes the complexity of the existing design, and combines the demands of the front-end to optimize and expand the single back-end permission model into a general building block for application software.

[0059] 1. Extended functions: Added constraints on data range. Through the designed resource authorization table, it can flexibly support any transaction as an authorization object. Through role binding, it can ultimately authorize the end user, providing constraint rules for logical processing. Added control over the validity period of permissions. By adding validity period fields and switch states in the relationship tables between the role table and the menu table, the operation permission table and the resource table, the effective duration of the granted permissions can be controlled. Added support for identity proxy. Through the user proxy table, the association relationship and approval status of the agent and the principal are recorded. Through the three-party association relationship of user role permissions, a complete proxy permission relationship network can be constructed, providing a judgment basis for logical processing. Added support for interface menus / buttons, and encapsulated the conversion strategy for converting interface elements and operation permissions. This embodiment allows users to intuitively allocate interface menus through the design of the menu table and the mapping relationship table between operation permissions and menus, and the conversion relationship behind it is processed internally, which improves the intuitiveness of user operations and reduces complexity.

[0060] 2. Optimize functions: optimize differentiated authorization and eliminate the drawbacks of having to create numerous roles;

[0061] This embodiment avoids the above situation through the clever design of an internal role. That is, when creating a user, each user implicitly creates a role. When it is necessary to grant differentiated authorization to a single user or a small number of users, the user only needs to be authorized directly on the interface, and the background will convert it into an implicit role authorization for the user. In this way, the principle of the RBAC permission model is not violated, the complexity is reduced, and user perception is improved.

[0062] The principles and implementation methods of the present invention are described in this article using specific embodiments. The description of the above embodiments is only used to help understand the method and core ideas of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made to the present invention without departing from the principles of the present invention, and these improvements and modifications also fall within the scope of protection of the claims of the present invention.

Claims

1. A general software access control model based on RBAC, characterized in that: include: The authorized resource module counts data resources and classifies them according to needs; A menu / button module, including a multi-level menu / button, which displays the classified data resources through the multi-level menu / button in combination with the authorized resource module; The operation authority module classifies the actual operation actions and assigns unique codes, and performs relationship matching between the classified actual operation actions and the multi-level menus / buttons.

2. A general software access control model based on RBAC according to claim 1, characterized in that: The authorization resource module includes: According to the business scenario, the resources that require data authorization are classified and maintained in the resource classification table.

3. A general software access control model based on RBAC according to claim 1, characterized in that: The operation authority module includes: Create role information based on business scenarios, classify the role information, and maintain the classified data in the role table.

4. A general software access control model based on RBAC according to claim 3, characterized in that: The classified resources in the authorized resource module are matched according to the role information in the role table, and the role table is mapped and matched with the hierarchy of the multi-level menu / button module.

5. A general software access control model based on RBAC according to claim 3, characterized in that: The operation authority module further includes: setting the authority validity period when the role table matches the authorization resource module and the menu / button module.

6. A general software access control model based on RBAC according to claim 3, characterized in that: The role table in the operation authority module also includes a built-in user proxy table, which includes matching the role information in the role table with the user proxy table, and assigning corresponding proxy codes to the role information in the role table for temporarily having the role information authorization in the role table.

7. A general software access control method based on RBAC, adopting a general software access control model based on RBAC as claimed in any one of claims 1 to 6, characterized in that: The method comprises: Resource matching, matching the mapping of the authorized resource module with the multi-level menu / button; User creation, fill in different user information, and allocate and maintain different role information for different users in the role table of the operation authority module. At the same time, in the role table, create an internal role for each user, and the internal role is used to distinguish the permissions of different role information; Role resource matching: mapping and matching the internal roles with the multi-level menus / buttons respectively, and acquiring resources through the multi-level menus / buttons.

8. A general software access control method based on RBAC according to claim 7, characterized in that: When a user needs to have access to other role information in the role table, the permission is obtained through the user proxy table.

Images