CN118916906A - Data authority configuration method, device and storage medium - Google Patents

Abstract

The application discloses a data authority configuration method, equipment and a storage medium, which relate to the technical field of information security and comprise the following steps: when a data role configuration request of an administrator is detected, acquiring a data role to be configured; configuring system data resource rights of the data roles based on the system data dimension selected by the administrator; and configuring the universal data resource authority of the data role based on the universal data dimension selected by the administrator. The flexibility of data authority configuration is improved.

Description

Data permission configuration method, device and storage medium

Technical Field

The present application relates to the field of information security technology, and in particular to a data permission configuration method, device and storage medium.

Background Art

The RBAC (Role-Based Access Control) model is a permission management method that indirectly manages permissions by assigning permissions to specific roles and then associating users with these roles.

In related technologies, administrators usually create roles at the level of the entire business system and configure unified permissions for these roles. For example, an administrator can set up an "employee" role and configure its permission to view basic information. After associating a user with "employee", the user can access basic information in the personnel management subsystem and the financial management subsystem.

However, as business systems become increasingly complex, the management requirements for data permissions in different subsystems have become more refined, and the above configuration method is difficult to meet this fine-grained level. For example, if it is necessary to grant financial approval permissions to "employees" for business needs, the administrator can only configure unified approval permissions for them, which means that the approval permissions of "employees" include not only finance, but also other areas such as personnel. Therefore, the existing data permission configuration method is not flexible enough.

The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art.

Summary of the invention

The main purpose of this application is to provide a data permission configuration method, device and storage medium, aiming to solve the technical problem of insufficient flexibility in data permission configuration.

To achieve the above purpose, the present application proposes a data permission configuration method, which includes:

When a data role configuration request from an administrator is detected, the data role to be configured is obtained;

Based on the system data dimensions selected by the administrator, configure the system data resource permissions of the data role;

Based on the common data dimensions selected by the administrator, the common data resource permissions of the data role are configured.

In one embodiment, after the step of configuring the general data resource permissions of the data role based on the general data dimension selected by the administrator, the step further includes:

Determine the system data resources corresponding to the system data resource authority and the general data resources corresponding to the general data resource authority;

Based on the administrator's selection of the permission level, the operation permissions of the system data resources and the common data resources are configured.

In one embodiment, after the step of configuring the general data resource permissions of the data role based on the general data dimension selected by the administrator, the step further includes:

When a data role assignment request of the administrator is detected, parsing the user identifier and the target data role in the data role assignment request;

An association relationship between the user identifier and the target data role is established.

In one embodiment, before the step of establishing the association relationship between the user identifier and the target data role, the step further includes:

If the target data role is a key data role, determining the total number of all the key data roles;

If the total number is lower than the number threshold, the step of establishing the association relationship between the user identifier and the target data role is performed.

In one embodiment, after the step of configuring the general data resource permissions of the data role based on the general data dimension selected by the administrator, the step further includes:

When a reference request from the administrator is detected, determining and displaying reference data dimensions associated with the reference request, wherein the reference data dimensions include a plurality of the common data dimensions;

Determining corresponding reference data resource permissions based on the administrator's selected operation on the reference data dimension;

The reference data resource permissions and the general data resource permissions are deduplicated and unioned, and the general data resource permissions of the data role are configured according to the processing results.

In one embodiment, the step of determining and displaying the reference data dimension associated with the reference request includes:

Determining a business process type in the reference request;

According to the common data dimensions involved in the business process type, the reference data dimensions are determined and displayed.

In one embodiment, after the step of configuring the general data resource permissions of the data role based on the general data dimension selected by the administrator, the step further includes:

When a login request from a user is detected, authenticating the login request;

If the identity authentication is successful, the target data role and access request in the login request are parsed;

Determine the target data resource authority corresponding to the target data role;

According to the access control policy, the access decision corresponding to the target data resource authority and the access request is determined, and the operation corresponding to the access decision is executed.

In one embodiment, the step of determining the target data resource authority corresponding to the target data role includes:

If there are multiple target data roles, determining the candidate data resource permissions associated with each target data role;

The candidate data resource permissions are deduplicated and merged to obtain the target data resource permissions.

In addition, to achieve the above-mentioned purpose, the present application also proposes a data permission configuration device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the data permission configuration method described above.

In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the data permission configuration method described above are implemented.

One or more technical solutions proposed in this application have at least the following technical effects:

The present application provides a data permission configuration method, which allows the dynamic configuration of the permissions of each data role based on the interactive actions of the administrator. This allows the administrator to dynamically configure the permissions in real time at runtime without restarting or reconfiguring the system, and the administrator can also adjust the permission settings at any time according to actual needs, without being limited to the fixed role and permission relationship, so as to more effectively deal with temporary permission change requirements. In addition, this embodiment distinguishes between system data resource permissions and general data resource permissions. This division enables permission settings to be specific to the subsystem level, rather than generally covering the entire system or a wide range of functions. This fine-grained permission division strategy enables permission allocation to more accurately match the needs of specific business scenarios, thereby effectively improving the accuracy and pertinence of permission control. In summary, fine-grained permission division and flexible permission configuration mechanism enable administrators to independently configure the permissions of each data role in different systems without creating multiple similar roles to deal with temporary permission changes. This not only reduces the number of roles, but also effectively avoids the occurrence of overlapping and confusing permissions between roles.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

FIG1 is a schematic diagram of a flow chart of a method for configuring data permissions in accordance with an embodiment of the present invention;

FIG2 is a schematic diagram of a flow chart of a second embodiment of a method for configuring data permissions in this application;

FIG3 is a flow chart of a third embodiment of the data permission configuration method of the present application;

FIG4 is a flow chart of a fourth embodiment of a method for configuring data permissions in this application;

FIG5 is a user login diagram provided in Embodiment 4 of the data permission configuration method of the present application;

FIG6 is a diagram showing the association structure of the data authority service library table of the data authority configuration method of the present application;

FIG7 is a flowchart of a data permission interface call when applying data permission for the data permission configuration method of the present application;

FIG8 is a schematic diagram of the device structure of the hardware operating environment involved in the data permission configuration method in the embodiment of the present application.

The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings.

DETAILED DESCRIPTION

It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

The main solution of the embodiment of the present application is: when an administrator's data role configuration request is detected, the data role to be configured is obtained; based on the system data dimension selected by the administrator, the system data resource permissions of the data role are configured; based on the common data dimension selected by the administrator, the common data resource permissions of the data role are configured.

As business systems become increasingly complex, the management requirements for data permissions in different subsystems have become more refined, and traditional configuration methods are difficult to meet this granularity. For example, if it is necessary to grant financial approval permissions to "employees" for business needs, the administrator can only configure unified approval permissions for them, which results in the approval permissions of "employees" not only covering finance, but also involving other areas such as personnel.

Moreover, in the traditional RBAC model, the relationship between roles and permissions is relatively fixed. This static definition is not flexible enough to cope with changes in business needs. For example, the "employee" role has the permission to view employee information in the human resources management system, but only has the permission to view reimbursements in the financial management system. If, due to business needs, it is temporarily necessary to enhance the permissions of the "employee" so that it can approve reimbursements, the traditional RBAC model can only create new roles to cope with it, which can easily cause confusion in data permissions.

To solve the above problems, this application provides a solution to distinguish between system data resource permissions and general data resource permissions, and supports dynamic configuration by administrators. This fine-grained permission division and flexible permission configuration mechanism improves the flexibility of data permission configuration.

It should be noted that the execution subject of this solution can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or a data permission configuration device capable of realizing the above functions, etc. The following embodiments are described below taking the data permission configuration device as an example.

Based on this, an embodiment of the present application provides a data permission configuration method, referring to FIG. 1 , which is a flow chart of the first embodiment of the data permission configuration method of the present application.

In this embodiment, the data permission configuration method includes steps S10 to S30:

Step S10, when a data role configuration request from an administrator is detected, obtaining the data role to be configured;

The data permission configuration method of this embodiment can be applied to a permission management platform (hereinafter referred to as the platform). The platform can assign permissions to users, roles, or specific resources. Administrators can configure, review, and change these permissions through the platform to respond to changes in business needs.

It is important to note that data role is a core concept, which is different from users. Users refer to entities that actually use the database, while roles are an abstraction of a set of permissions that can be granted to users.

The platform has mechanisms to detect administrator requests. These requests may be generated through GUI button clicks, form submissions, API calls, or other forms of interaction.

Exemplarily, the permission management platform displays a data permission configuration interface, showing all current data roles and their properties, and the administrator can select the data role to be configured in this interface. To achieve this function, the platform sets up an event detector. When the administrator clicks a button, the event detector captures the click event and collects relevant information on the current interface, including the selected data role and other configuration parameters. Subsequently, this information is sent to the backend through a data role configuration request for subsequent processing.

Accordingly, after receiving the request, the backend first performs a simple content check on the request to verify whether it exists and conforms to the expected structure. For example, it checks whether the "roleId" field is included. If so, it is determined to be a data role configuration request.

Furthermore, middleware is used to automatically process and parse requests, which can convert requests into objects that can be used by the backend. Once the request is parsed, the backend can extract the required fields from the request, that is, the data roles to be configured, according to the predefined API (Application Programming Interface) specifications.

Step S20, configuring the system data resource permissions of the data role based on the system data dimension selected by the administrator;

Step S30: configuring the general data resource permissions of the data role based on the general data dimension selected by the administrator.

It should be noted that this solution adopts a multi-dimensional permission control method, dividing the dimensions into system data dimensions and general data dimensions.

System data dimensions refer to permission dimensions that are customized according to the needs of specific business systems. These dimensions are highly personalized and are designed to solve permission control problems in specific business scenarios. System data dimensions can be added or modified at any time according to the needs of business development, providing greater flexibility and adaptability.

For example, for an e-commerce business system, product type, inventory status, etc. can be considered as system data dimensions. These dimensions allow access rights to be customized based on product characteristics and inventory status, such as limiting certain users to only view specific types of products.

Common data dimensions refer to a set of predefined commonly used permission dimensions, which provide standard permission templates and are applicable to most business scenarios. These dimensions are usually cross-system and universally applicable, and can cover common permission control requirements.

For example, the time dimension and the geographic location dimension can be considered as common data dimensions. The time dimension may predefine the access rights for working days and non-working days, while the geographic location dimension may limit the access rights of users in a specific region.

Permissions can be defined independently for both general data dimensions and system data dimensions. These dimensions can be associated and interacted to form combined authorizations, making permission control more refined and flexible. For example, by combining the time dimension with the geographic location dimension, it is possible to precisely control "user A can access data in region D during time period T." This association and combination between allowed dimensions builds a three-dimensional permission control system, thereby achieving fine-grained, dynamic permission configuration and joint authorization.

Optionally, the permission management platform displays a data permission configuration interface. After selecting a data role, the administrator can select the dimension to be used for permission control in the customized system data dimension list. At this time, the event detector captures the selected operation and sends it to the backend.

Correspondingly, after receiving the selected operation, the backend will extract the system data dimensions selected by the administrator. The specific principle is the same as the processing flow of the data role configuration request, which will not be repeated here.

Next, determine the code corresponding to the system data dimension, and search for the corresponding system data resource permissions in the preset permission mapping table, so as to configure these system data resource permissions for the currently selected data role.

Similarly, in the preset permission mapping table, find the general data resource permissions corresponding to the general data dimensions, and then complete the configuration of the general data resource permissions.

It is understandable that data resources are the objects of data permission control. Administrators can also set different operation permissions for data resources, such as read-only, edit, manage, etc. By finely controlling the access rights of different users to data resources, unauthorized data access, modification or leakage can be prevented.

Specifically, the mapping relationship between data permissions and data resources is queried to determine the system data resources corresponding to the system data resource permissions and the general data resources corresponding to the general data resource permissions. Then, the system data resources and general data resources are displayed on the user interface so that the administrator can easily configure their permissions.

When the user selects the permission level on the interface, the corresponding configuration request will be automatically triggered. The backend parses the request and configures the operation permissions for system data resources and general data resources.

For example, for financial statements corresponding to financial permissions. If read-only permissions are configured, users can view financial statements but cannot make any modifications; if edit permissions are configured, users can view and modify financial statements but cannot delete them; if management permissions are configured, users can view, edit, and delete financial statements, and can generate new financial statements. This solution only allows users with specific permissions to edit data resources, which can prevent data from being changed at will, thereby maintaining data consistency and accuracy, which is particularly important for business scenarios that require highly accurate data.

This embodiment provides a data permission configuration method, which allows the dynamic configuration of the permissions of each data role based on the interactive actions of the administrator. This allows the administrator to dynamically configure the permissions in real time at runtime without restarting or reconfiguring the system, and the administrator can also adjust the permission settings at any time according to actual needs, without being limited to the fixed role and permission relationship, so as to more effectively respond to temporary permission change requirements. In addition, this embodiment distinguishes between system data resource permissions and general data resource permissions. This division enables permission settings to be specific to the subsystem level, rather than generally covering the entire system or a wide range of functions. This fine-grained permission division strategy enables permission allocation to more accurately match the needs of specific business scenarios, thereby effectively improving the accuracy and pertinence of permission control. In summary, fine-grained permission division and flexible permission configuration mechanism enable administrators to independently configure the permissions of each data role in different systems without creating multiple similar roles to respond to temporary permission changes. This not only reduces the number of roles, but also effectively avoids the occurrence of overlapping and confusion of permissions between roles.

Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above description, and will not be repeated in the following. On this basis, please refer to FIG. 2, after step S30, the data permission configuration method further includes steps A10 to A20:

Step A10, when a data role assignment request from the administrator is detected, parsing the user identifier and the target data role in the data role assignment request;

Step A20: establishing an association relationship between the user identifier and the target data role.

After the administrator has configured the data role and the corresponding resource permissions, he or she can bind the data role to a specific user.

The administrator triggers a data role assignment request through the interface or API call. After the backend detects the data role assignment request, it extracts the user ID and the target data role from it. The user ID is the user's unique identification information, and the target data role is the permission role that you want to grant to the user.

Next, the backend will establish an association between the user ID and the target data role. This means that the user will be granted the permissions of the target data role. This association is usually stored in the permission management database for subsequent permission verification and management. The system can determine the user's permissions when accessing data resources based on this association.

It is understandable that data roles are divided into key data roles and non-key data roles according to business needs. Key data roles usually have higher permissions and can access or operate sensitive data. The number of users associated with key data roles can be limited to ensure that key permissions are not abused.

Specifically, when an administrator requests to assign a user to a target data role, the backend will query the role database to determine whether the target data role is a key data role. If the target data role is a key data role, the backend will perform a query operation to count the total number of all current key data roles.

The backend has a preset quantity threshold to determine whether the current number of key data roles is within an acceptable range. This threshold can be set based on the organization's security policies and business needs.

The backend will compare the total number of key data roles counted with the quantity threshold. If the total number of key data roles is lower than the set quantity threshold, the step of associating the user ID with the target data role is allowed. This means that in the case of insufficient number of key data roles, the system will allow the addition of new key roles to ensure the flexibility and security of data access. If the total number of key data roles is higher than or equal to the quantity threshold, the system may reject the role assignment request to prevent excessive concentration or abuse of permissions.

Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above description, and will not be repeated in the following. On this basis, please refer to FIG. 3, after step S30, the data permission configuration method further includes steps B10 to B30:

Step B10, when a reference request from the administrator is detected, determining and displaying reference data dimensions associated with the reference request, wherein the reference data dimensions include a plurality of the common data dimensions;

Step B20, determining corresponding reference data resource permissions based on the administrator's selection operation on the reference data dimension;

Step B30, deduplication and union processing are performed on the reference data resource permissions and the general data resource permissions, and the general data resource permissions of the data role are configured according to the processing results.

In this embodiment, the general dimension permissions can be inherited and inherited, and the administrator can define some general permission configurations to be inherited, thereby reducing the duplication of configurations.

Optionally, the user interface is provided with a reference button, and when the administrator clicks the reference button, a reference request is automatically triggered. The system needs to parse the reference request, determine all the reference data dimensions associated with it, and display them to the administrator.

The reference data dimension can be in two forms: one is a fixed template customized by the administrator, and the other is flexibly generated according to the specific business process. The flexible generation method can accurately determine the required data dimensions, avoiding the mismatch or redundancy problems that may be caused by fixed templates.

Specifically, the request is parsed to extract the relevant parameters of the business process, such as data roles, business scenario descriptions, business process types, etc. The backend maintains a business process mapping table, which records the historical process records of each business process type. Therefore, the backend will determine the historical process records corresponding to the current business process type based on the business process mapping table, thereby identifying the common data dimensions involved in the process record. Next, these common data dimensions are filtered and sorted to generate the final reference data dimension list.

As for the specific display method, since the general dimension permissions have a tree structure, the backend can display these dimensions to the administrator in a hierarchical manner, so that the administrator can clearly see the inheritance relationship between the dimensions.

Furthermore, the administrator selects one or more reference data dimensions from the displayed reference data dimensions according to actual needs. Based on the administrator's selection operation, the backend further determines the reference data resource permissions corresponding to these selected dimensions. Since common dimension permissions can be inherited, the dimensions selected by the administrator may automatically include the permissions of their parent dimensions, thereby reducing configuration duplication.

Next, the backend will deduplicate the referenced data resource permissions and existing general data resource permissions to ensure that there are no duplicate permission configurations; then, the two will be merged to obtain the final data role permission configuration. Due to the inheritance characteristics of general permissions, the merged permission set may contain multiple levels of permissions.

For example, when the administrator configures the data role "finance personnel", he clicks the reference button in the interface, and the backend determines the business department of the data role and displays the department common dimensions corresponding to the business department, that is, displays the common data dimensions in the financial management system. In response to the administrator's selection operation, the backend determines the corresponding reference data resource permissions, such as the permission to view financial documents.

In addition, the backend can further analyze the departmental positions of data roles in the business department and bind the departmental special permissions corresponding to the departmental positions. For example, the "financial director" role will obtain the financial form review permission. This measure not only gives the "financial director" a wider range of powers, but also ensures that the "financial personnel" group can continue to enjoy the necessary access and operation permissions based on the department's general permission framework, ensuring that data permissions can flexibly adapt to the needs of specific scenarios on the basis of meeting the general configuration, thereby maintaining the consistency of the permission system while achieving the refinement and differentiation of permission allocation, ensuring effective response to various complex permission management scenarios.

This embodiment provides a data permission configuration method that supports the inheritance and overwriting mechanism of general permissions, so that administrators can flexibly implement permission inheritance and refined overwriting when performing selected operations on referenced data dimensions. This mechanism can ensure that roles have appropriate permissions, while minimizing the management and maintenance workload, and effectively improving the efficiency of permission management.

Based on the first embodiment of the present application, in the fourth embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above description, and will not be repeated in the following. On this basis, please refer to FIG. 4, after step S30, the data permission configuration method further includes steps C10 to C40:

Step C10, when a user's login request is detected, identity verification is performed on the login request;

Step C20, if the identity authentication is passed, parsing the target data role and access request in the login request;

Step C30, determining the target data resource authority corresponding to the target data role;

Step C40: Determine the access decision corresponding to the target data resource authority and the access request according to the access control policy, and execute the operation corresponding to the access decision.

As shown in Figure 5, the user enters login information, such as user name, password, mobile phone number verification code, etc. through the front-end interface, and the front-end interface submits a login request to the back-end server.

After receiving the login request from the front-end, the back-end retrieves the user information from the database and can use a security algorithm to verify whether the password hash value matches. If it matches, the identity authentication is successful; otherwise, a verification failure reminder is fed back.

Furthermore, if the identity authentication is passed, the target data role and access request information are extracted from the login request. Then, according to the target data role, the data role and data resource permission mapping table in the database is queried to determine the corresponding target data resource permission.

Compare the target data resource permissions with the access request, determine the access decision and execute it according to the access control policy. The specific steps are as follows:

Parse the target data resource permissions to determine the accessible data resources and the operations that can be performed on these resources, which can be returned in the form of resource points. At the same time, parse the user's access request to extract the target data resource involved in the request, the requested operation type, and other related parameters.

Compare the parsed permissions with the request. The comparison process needs to carefully match whether the target resource of the request is within the user's permissions and whether the requested operation type is allowed.

Adopt applicable access control policies based on current user attributes, resource attributes and other factors. These policies can be predefined or dynamically generated to adapt to different business scenarios and security requirements. For example, allow access: if the user's permissions match the request type, the system will allow access and perform the corresponding operation; deny access: if the user's permissions do not match the request type, the system will deny access and return the corresponding error message; additional processing: in some cases, additional access control processing may be required, such as multi-factor authentication, audit records, log encryption, etc.

Based on the comparison results and access control policy, the final access decision is generated, which can be "allow access", "deny access", or "additional processing".

Additionally, consider that in some cases a user may be assigned multiple roles, each of which may correspond to different permissions.

Therefore, when it is detected that the user has multiple target data roles, the system needs to process these roles. A query is performed for each target data role to obtain the candidate data resource permissions associated with it, and these candidate data resource permissions are collected into a set to form a list containing all candidate data resource permissions.

Since a user may have the same permissions in multiple roles, it is necessary to implement a deduplication algorithm to traverse the set, identify and remove duplicate permission items, and ensure that each permission appears only once. After deduplication, all unique candidate permissions are merged to form the final target data resource permission set.

In addition, this solution can also establish a complete audit tracking mechanism to comprehensively record users' data access operations and provide security analysis and monitoring.

Specifically, the system will record detailed audit logs for each user data access request, including information such as the operating subject, access period, access location, and requested resources. These audit logs can be used for permission security analysis to help administrators discover abnormal access patterns or trends and prevent data leakage risks. In addition, the system will conduct real-time detection and review of the permission control process. Once an unauthorized operation request is found, it can immediately take measures such as interception or flow control to protect and respond.

Through perfect auditing and monitoring methods, the whole life cycle tracking of permission control can be realized, abnormal access can be discovered and blocked in time, and the integrity and confidentiality of data are not threatened. This significantly improves the reliability and security of the system's permission control.

This embodiment provides a data permission configuration method, which adopts a strong verification and authorization mechanism. By strictly verifying the identity of the user, unauthorized access can be prevented, thereby protecting sensitive data in the system from being snooped or tampered with by unauthorized users. Moreover, the access control policy ensures that users can only access the resources they are authorized to, which further enhances the security of the system and reduces the risk of internal leakage or misoperation. This verification and authorization mechanism runs through and constrains the entire data permission control process. The system rejects any unauthorized access requests, which strengthens the data security of the overall system and the standardization of permission management.

Exemplarily, in order to help understand the implementation process of the data permission configuration method obtained by combining this embodiment with the above-mentioned embodiment 1, refer to Figure 6, which provides a data permission business library table association structure diagram of this method, specifically:

(1) A user can belong to multiple organizations, and an organization can include multiple users.

(2) A position can belong to multiple organizations, and an organization can include multiple positions.

(3) One user can be associated with multiple positions, and one position can be associated with multiple users.

(4) A user can belong to multiple systems, and a system can include multiple users, that is, a user can have multiple system permissions.

(5) You can define some common permission configurations, namely common data dimensions, such as region, gender, year, quarter, etc.

(6) Define common data permission resources for common dimensions, which can be inherited by other permissions. Permission inheritance can be established between roles or users, or across different dimensions.

(7) Each subsystem can customize system permission configuration according to business application scenarios, that is, system data dimensions, such as personnel departments, etc.

(8) Define system data authority resources corresponding to system data dimensions, such as a department’s special task force, etc.

(9) Role-related data resources, including general data resources and system data resource permissions. Roles are granted multi-dimensional permission resources.

(10) One user can have multiple roles, and one role can be assigned to multiple users. That is, users are assigned data permissions corresponding to their roles, and user members are assigned permissions to obtain data corresponding to their roles.

(11) Supports dynamic configuration of permissions and adjustment of permission resource configuration without restarting or reconfiguring the system. It takes effect based on the actual configuration permission details and synchronizes the latest permission resource strategy to perform data permission access control.

Referring to FIG. 7 , FIG. 7 provides a data permission interface call flow chart when applying data permission, specifically:

(1) When a user logs in, the data role of the system owned by the user is obtained through the token and system code.

(2) Query the roles associated with the user. If no role is associated, the result is null permissions, which means no data permissions.

(3) If the user is associated with some data roles, the data resource permissions corresponding to the data dimension code of each role in the system will be processed separately according to the general data dimension or system data dimension code.

(4) Query the selected data resource permissions under all associated data roles in the system according to the data dimension code. Then, deduplicate these data resource permissions and take the union to obtain the data resource permissions that the user has in the system.

(5) If a user is associated with multiple data roles, the system will obtain the data dimension codes defined by each role associated with the user, and merge permissions based on the same dimension code. That is, for the same data dimension defined in the role, the system will perform a union operation on the permission resources, remove duplications, and aggregate them into the user's permissions for the data dimension.

(6) Common data permission resources can be inherited by other permissions. Permission inheritance can be established between roles or between users, and can also span different dimensions. For example, a department manager role can inherit some or all permissions from a company administrator role, or a project role can inherit permissions from a business role. This role-based permission inheritance can quickly build authorization logic between roles. In addition, a user can inherit permissions from multiple roles to meet their needs for multiple responsibilities in the organization.

It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the data permission configuration method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

The present application provides a data permission configuration device, which includes: at least one processor; and a memory that is communicatively connected to the at least one processor; wherein the memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the data permission configuration method in the above-mentioned embodiment one.

Reference is made to Figure 8 below, which shows a schematic diagram of the structure of a data authority configuration device suitable for implementing an embodiment of the present application. The data authority configuration device in the embodiment of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. The data authority configuration device shown in Figure 8 is only an example and should not bring any limitations to the functions and scope of use of the embodiments of the present application.

As shown in FIG8 , the data authority configuration device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which may perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the data authority configuration device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other via a bus 1005. An input/output (I/O) interface 1006 is also connected to the bus. Typically, the following systems may be connected to the I/O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the data rights configuration device to communicate wirelessly or wired with other devices to exchange data. Although the data rights configuration device with various systems is shown in the figure, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

The data authority configuration device provided by the present application adopts the data authority configuration method in the above embodiment, which can solve the technical problem of insufficient flexibility of data authority configuration. Compared with the prior art, the beneficial effects of the data authority configuration device provided by the present application are the same as the beneficial effects of the data authority configuration method provided by the above embodiment, and the other technical features in the data authority configuration device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

The present application provides a computer-readable storage medium having a computer program stored thereon, and the computer-readable program instructions are used to execute the data permission configuration method in the above-mentioned embodiment.

The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

The computer-readable storage medium may be included in the data authority configuration device; or may exist independently without being assembled into the data authority configuration device.

The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the data permission configuration device, the data permission configuration device: when detecting the administrator's data role configuration request, obtains the data role to be configured; based on the system data dimension selected by the administrator, configures the system data resource permissions of the data role; based on the general data dimension selected by the administrator, configures the general data resource permissions of the data role.

Computer program code for performing the operations of the present application may be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and/or flow chart, and the combination of the boxes in the block diagram and/or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

The modules involved in the embodiments of the present application may be implemented by software or hardware, wherein the name of the module does not limit the unit itself in some cases.

The readable storage medium provided in this application is a computer-readable storage medium, which stores a computer program for executing the above-mentioned data permission configuration method, and can solve the technical problem of insufficient flexibility of data permission configuration. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the data permission configuration method provided in the above-mentioned embodiment, and will not be repeated here.

The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct/indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims (10)

1. A data permission configuration method, characterized in that the method comprises: When a data role configuration request from an administrator is detected, the data role to be configured is obtained; Based on the system data dimensions selected by the administrator, configure the system data resource permissions of the data role; Based on the common data dimensions selected by the administrator, the common data resource permissions of the data role are configured. 2. The method according to claim 1, characterized in that after the step of configuring the general data resource permissions of the data role based on the general data dimension selected by the administrator, the method further comprises: Determine the system data resources corresponding to the system data resource authority and the general data resources corresponding to the general data resource authority; Based on the administrator's selection of the permission level, the operation permissions of the system data resources and the common data resources are configured. 3. The method according to claim 1, characterized in that after the step of configuring the general data resource permissions of the data role based on the general data dimension selected by the administrator, the method further comprises: When a data role assignment request of the administrator is detected, parsing the user identifier and the target data role in the data role assignment request; An association relationship between the user identifier and the target data role is established. 4. The method according to claim 3, characterized in that before the step of establishing the association relationship between the user identification and the target data role, it also includes: If the target data role is a key data role, determining the total number of all the key data roles; If the total number is lower than the number threshold, the step of establishing the association relationship between the user identifier and the target data role is performed. 5. The method according to claim 1, characterized in that after the step of configuring the general data resource permissions of the data role based on the general data dimension selected by the administrator, the method further comprises: When a reference request from the administrator is detected, determining and displaying reference data dimensions associated with the reference request, wherein the reference data dimensions include a plurality of the common data dimensions; Determining corresponding reference data resource permissions based on the administrator's selected operation on the reference data dimension; The reference data resource permissions and the general data resource permissions are deduplicated and unioned, and the general data resource permissions of the data role are configured according to the processing results. 6. The method according to claim 5, wherein the step of determining and displaying the reference data dimension associated with the reference request comprises: Determining a business process type in the reference request; According to the common data dimensions involved in the business process type, the reference data dimensions are determined and displayed. 7. The method according to claim 1, characterized in that after the step of configuring the general data resource permissions of the data role based on the general data dimension selected by the administrator, the method further comprises: When a login request from a user is detected, authenticating the login request; If the identity authentication is successful, the target data role and access request in the login request are parsed; Determine the target data resource authority corresponding to the target data role; According to the access control policy, the access decision corresponding to the target data resource authority and the access request is determined, and the operation corresponding to the access decision is executed. 8. The method according to claim 7, wherein the step of determining the target data resource authority corresponding to the target data role comprises: If there are multiple target data roles, determining the candidate data resource permissions associated with each target data role; The candidate data resource permissions are deduplicated and merged to obtain the target data resource permissions. 9. A data permission configuration device, characterized in that the device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the data permission configuration method as described in any one of claims 1 to 8. 10. A storage medium, characterized in that the storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium, and when the computer program is executed by a processor, the steps of the data permission configuration method according to any one of claims 1 to 8 are implemented.