Authority management method and device, electronic equipment and readable storage medium

Abstract

The embodiment of the invention provides an authority management method and device, electronic equipment and a readable storage medium, and the method comprises the steps: generating an authority change message according to an authority identifier carried in an authority adjustment request and an adjustment target corresponding to the authority identifier under the condition of receiving the authority adjustment request; the permission change message is used for indicating to adjust the user permission corresponding to the permission identifier according to the adjustment target; when the first strategy type corresponding to the permission change message is a dynamic permission strategy, generating a timed change task according to a time rule corresponding to the permission change message; and executing the timed change task to adjust the user permission corresponding to the permission identifier according to the adjustment target at a preset time point corresponding to the timed change task, thereby improving the security of managing the user permission and improving the efficiency of adjusting the user permission.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a permission management method, device, electronic device and readable storage medium. Background Art

[0002] With the rapid development of information technology, enterprise information systems are becoming increasingly complex, and user rights management has become a key link in ensuring the security and stable operation of the system. Rights management generally refers to the fact that users can access and can only access the resources they are authorized to according to the set security rules or security policies.

[0003] Traditional permission management methods pose security risks because once user permissions are set, they rarely change, which can lead to abuse of permissions or long-unused permissions becoming security vulnerabilities. In addition, in a rapidly changing business environment, companies often need to adjust employee responsibilities and permissions. Static permission management methods cannot meet this demand. Each adjustment requires manual changes to permission settings, which is not only inefficient but also prone to errors. Summary of the invention

[0004] The embodiments of the present application provide a permission management method, device, electronic device and readable storage medium, which can improve the efficiency of adjusting user permissions.

[0005] In a first aspect, an embodiment of the present application discloses a method for managing permissions, the method comprising:

[0006] In the case of receiving a permission adjustment request, generating a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier; the permission change message is used to indicate that the user permission corresponding to the permission identifier is adjusted according to the adjustment target;

[0007] In a case where the first policy type corresponding to the permission change message is a dynamic permission policy, generating a scheduled change task according to a time rule corresponding to the permission change message;

[0008] The scheduled change task is executed to adjust the user authority corresponding to the authority identifier according to the adjustment target at a preset time point corresponding to the scheduled change task.

[0009] Optionally, when the first policy type is a dynamic permission policy, generating a scheduled change task according to a time rule corresponding to the permission change message includes:

[0010] A first scheduled change task is generated based on the first operation corresponding to the permission change message and the effective time corresponding to the first operation; the first scheduled change task is used to indicate the execution of the first operation on the target permission, and the execution result of the first operation is only valid within the effective time.

[0011] Optionally, the effective time includes a start time point and an end time point; and generating a first scheduled change task according to the first operation carried by the permission change message and the effective time corresponding to the first operation includes:

[0012] Generate a first subtask according to the first operation corresponding to the permission change message and the start time point corresponding to the first operation; the first subtask is used to instruct to perform the first operation on the user permission at the start time point;

[0013] A second subtask is generated based on the first operation corresponding to the permission change message and the end time point corresponding to the first operation; the second subtask is used to indicate that the user permission is restored from the first state after executing the first operation to the second state before executing the first operation at the end time point.

[0014] Optionally, the method further comprises:

[0015] In a case where the first policy type corresponding to the permission change message is a static permission policy, generating a change task according to the second operation corresponding to the permission change message;

[0016] The change task is executed to modify the user authority according to the second operation.

[0017] Optionally, the permission adjustment request carries at least one permission identifier and a policy type corresponding to the permission identifier; and upon receiving the permission adjustment request, generating a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier, including:

[0018] When a permission adjustment request is received, at least one permission change message is generated according to each permission identifier carried in the permission adjustment request and the policy type corresponding to the permission identifier; one permission change message corresponds to one permission identifier.

[0019] Optionally, when the first policy type corresponding to the permission change message is a dynamic permission policy, before generating the scheduled change task according to the time rule corresponding to the permission change message, the method further includes:

[0020] Adding the permission change message to a message queue;

[0021] The permission change message is read from the message queue according to a preset rule, and a first policy type corresponding to the permission change message is identified.

[0022] Optionally, the method further comprises:

[0023] Upon receiving an access request from a first user, reading the user rights corresponding to the first user from a cache; the access request carries a target object that the first user desires to access;

[0024] In a case where the user rights include access rights corresponding to the target object, allowing the user to access the target object;

[0025] If the user rights do not include the access rights corresponding to the target object, an error prompt is returned.

[0026] In a second aspect, an embodiment of the present application discloses a rights management device, the device comprising:

[0027] In the case of receiving a permission adjustment request, generating a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier; the permission change message is used to indicate that the user permission corresponding to the permission identifier is adjusted according to the adjustment target;

[0028] In a case where the first policy type corresponding to the permission change message is a dynamic permission policy, generating a scheduled change task according to a time rule corresponding to the permission change message;

[0029] The scheduled change task is executed to adjust the user authority corresponding to the authority identifier according to the adjustment target at a preset time point corresponding to the scheduled change task.

[0030] In a third aspect, an embodiment of the present application discloses an electronic device, which includes a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store executable instructions, and the executable instructions enable the processor to execute the permission management method as described above.

[0031] In a fourth aspect, an embodiment of the present application discloses a readable storage medium, on which a program or instruction is stored, and the program or instruction implements the aforementioned permission management method when executed by a processor.

[0032] The embodiments of the present application include the following advantages:

[0033] The present application provides a permission management method, which generates a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier when a permission adjustment request is received; the permission change message is used to indicate that the user permission corresponding to the permission identifier is adjusted according to the adjustment target; when the first policy type corresponding to the permission change message is a dynamic permission policy, a scheduled change task is generated according to the time rule corresponding to the permission change message; the scheduled change task is executed to adjust the user permission corresponding to the permission identifier according to the adjustment target at a preset time point corresponding to the scheduled change task, thereby improving the security of managing user permissions and improving the efficiency of adjusting user permissions. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0035] Figure 1 It is a flowchart of the steps of an embodiment of a rights management method of the present invention;

[0036] Figure 2 It is a schematic diagram of a rights management system of the present invention;

[0037] Figure 3 It is a structural block diagram of a rights management device of the present invention;

[0038] Figure 4 It is a structural block diagram of an electronic device provided by an example of the present invention. DETAILED DESCRIPTION

[0039] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0040] The terms "first", "second", etc. in the specification and claims of the present invention are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable when appropriate, so that the embodiments of the present invention can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, the term "and / or" in the specification and claims is used to describe the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. In the embodiments of the present invention, the term "multiple" refers to two or more, and other quantifiers are similar.

[0041] Method Embodiment

[0042] Reference Figure 1 , showing a flowchart of a method for managing rights according to an embodiment of the present invention

[0043] Step S101: upon receiving a permission adjustment request, generating a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier.

[0044] The permission change message is used to indicate that the user permission corresponding to the permission identifier is adjusted according to the adjustment target.

[0045] The permission management method provided in the embodiment of the present application can be applied to enterprise internal management systems, online platforms and applications, cloud services and infrastructure. In an enterprise internal management system, permission management refers to the allocation of corresponding permissions according to the positions and responsibilities of employees. As the positions of employees change, permissions also need to be adjusted accordingly. For example, management may need to access the data of all departments, while ordinary employees only need to access the information of their own departments. In e-commerce applications, permission management refers to ensuring that users can only access or operate resources within their accounts to prevent data leakage and abuse; and can dynamically adjust the scope of their permissions based on user behavior and needs. For example, ordinary users may only be able to view product information and shopping cart functions, while administrators may have the functions of creating, editing and deleting goods. In cloud service application scenarios, cloud service platforms usually provide fine-grained permission settings, allowing users to perform refined management as needed. For example, different access levels can be set for different user groups, and control lists can be used to store user access rights, clarify which users or user groups can access specific resources, and define their operating permissions.

[0046] Among them, the situations in which permission adjustment requests are received may include: changes in roles or responsibilities, changes in business requirements, discovery of security vulnerabilities, system or application upgrades, improper permission allocation, etc. Specifically, when a user's position changes, their responsibilities and required permissions will also change accordingly, and user permissions need to be adjusted to match the new role. As the business develops, when new functions or modules are launched, employees need to be assigned corresponding permissions to access or use these new functions. After a security vulnerability is discovered, user permissions need to be adjusted to limit access to affected resources. After a system upgrade, the original permission settings may no longer apply, and permission adjustments need to be made based on the new system architecture and functions. When performing a permission audit, improper or expired permissions may be discovered, and permission adjustment requests need to be issued to correct them.

[0047] Among them, the methods of generating permission adjustment requests may include: user interface-based requests, interface-based requests, and command line-based requests. For example, a permission management system allows administrators to manage and adjust user permissions through a graphical interface; or a permission management system may provide a RESTful API interface, allowing third-party applications or scripts to submit permission adjustment requests through HyperText Transfer Protocol (HTTP) requests. For some systems based on a command line interface, a command line interface tool (CLI) may be provided to allow administrators to submit permission adjustment requests through the command line.

[0048] It should be noted that a permission management module may also be provided, in which at least one permission management policy is stored, and the permission management policy is used to indicate that user access to system resources is restricted according to a preset policy, and the system assigns permissions to each user according to the permission management policy. When the permission management policy changes, the user's permissions need to be modified accordingly, and the permission management module sends a permission change message to modify the user's permissions according to the permission message indication content.

[0049] A permission identifier refers to a sign or code that can uniquely identify a user's access rights to system resources. The permission identifier can be a permission name, and system resources can include files, directories, databases, etc. For example, operating system permissions include Read and Write, and database permissions include SELECT and INSERT.

[0050] The adjustment target refers to the user permission status after the user permission corresponding to the permission identifier is adjusted. For example, if the adjustment target is that the user does not have the permission corresponding to the permission identifier, the user permission corresponding to the permission identifier is deleted.

[0051] In an embodiment of the present application, the permission adjustment request is parsed, and the permission identifier and the adjustment target corresponding to the permission identifier are extracted from the permission adjustment request; based on the permission identifier and the adjustment target corresponding to the permission identifier, a permission change message is constructed, and the constructed permission change message is sent to a designated component for processing. Among them, the permission change message can be composed of the following contents: user identifier, permission identifier, policy type, and operation type.

[0052] Step S102: When the first policy type corresponding to the permission change message is a dynamic permission policy, a scheduled change task is generated according to a time rule corresponding to the permission change message.

[0053] Among them, time rules refer to time-related rules, which can include specified dates, times, time ranges, and cycles. Specifically, the time rule is identified as a one-time task or a periodic task. A one-time task is executed only once at a specified time, while a periodic task is executed repeatedly within a specified time interval.

[0054] A scheduled change task is an automated task that can automatically execute permission change operations at a specific time point or time interval based on preset time rules.

[0055] Generating a scheduled change task may include: configuring a scheduled change task and saving a scheduled change task. Configuring a scheduled change task may include: setting a task parameter task name, and specifying a descriptive name for the scheduled change task for easy identification and management. Specify the command or script to be executed when the scheduled change task is triggered. The command or script usually includes calling a permission management system or API to perform permission change operations. Set the trigger time of the scheduled change task according to the parsed time rules. For periodic tasks, it is also necessary to set the repetition interval and end condition. For example, the end condition can be infinite repetition or end at a specified time. Saving a scheduled change task means selecting a scheduled task tool. In Linux systems, commonly used scheduled task tools include cron, at, etc.; in Windows systems, you can use Task Scheduler. After the scheduled task tool is selected, save the configured scheduled change task to the scheduled task tool.

[0056] Step S103: Execute the scheduled change task to adjust the user authority corresponding to the authority identifier according to the adjustment target at the preset time point corresponding to the scheduled change task.

[0057] User rights refer to the rights granted to users in the system to access specific resources or perform specific operations. User rights can include: basic access rights, system management rights, rights to specific resources or objects, login and session rights, security and audit rights. Basic access rights refer to read rights, write rights, etc. Security rights refer to user access to security-related functions, such as viewing or modifying security policies and logs; audit rights refer to the permission for users to view or generate system audit reports to help monitor and identify potential security threats or illegal operations.

[0058] Among them, the storage location and existence form of user rights depend on the specific system architecture and permission management mechanism. The adjustment methods are different for user rights with different existence forms. The storage location of user rights can be inside the database system, configuration files, and distributed storage services. In most database systems, such as MySQL, PostgreSQL, Oracle, etc., user rights are usually stored in specific tables in the system database. For example, in MySQL, all user names and their permission information are stored in the "user" table in the system database "mysql". In some systems, user rights may be stored in configuration files. The configuration file may exist in plain text and contain user ID, user name, password, and corresponding permission settings. In some cases, user permission information may be passed and managed through environment variables. In cloud computing and distributed system environments, user permission information may be stored in distributed storage services.

[0059] User permissions can exist in the form of a table, a key-value pair, an access control list, or a role-based access control. When user permissions exist in the form of a table, each user or user group corresponds to a row of records, including fields such as user ID, user name, password, and permission range. When user permissions exist in the form of a key-value pair, each user or user group corresponds to a unique key, whose value contains an encoded or serialized representation of permission information. When user permissions exist in the form of an access control list, user permissions exist in the form of a list, specifying the access rights of each user or user group to specific resources. In the role-based access control form, user permissions are associated through roles, each user is assigned one or more roles, each role corresponds to a set of permissions, and user permissions exist in the form of a mapping relationship between roles and permissions.

[0060] It should be noted that the method of executing a scheduled change task can be to call an API interface to adjust the user permissions corresponding to the permission identifier according to the adjustment target at the preset time point corresponding to the scheduled change task; user permissions can also be adjusted based on a custom script.

[0061] In an embodiment of the present application, when a permission adjustment request is received, a permission change message is generated based on the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier; the permission change message is used to indicate that the user permission corresponding to the permission identifier is adjusted according to the adjustment target; when the first policy type corresponding to the permission change message is a dynamic permission policy, a scheduled change task is generated according to the time rule corresponding to the permission change message; the scheduled change task is executed to adjust the user permission corresponding to the permission identifier according to the adjustment target at the preset time point corresponding to the scheduled change task, thereby improving the security of managing user permissions and improving the efficiency of adjusting user permissions.

[0062] Optionally, when the first policy type is a dynamic permission policy, generating a scheduled change task according to a time rule corresponding to the permission change message includes:

[0063] A first scheduled change task is generated according to the first operation corresponding to the permission change message and the effective time corresponding to the first operation; the first scheduled change task is used to indicate the execution of the first operation on the user permission, and the execution result of the first operation is only valid within the effective time.

[0064] The first operation may include: adding, deleting, and replacing; the effective time is a time range.

[0065] It should be noted that when storing user rights, a corresponding validity mark is added to the user rights, and the validity mark reflects that the user rights have two states, namely valid state and invalid state. If the validity mark of the right is valid, it means that the user has the right, and if the validity mark of the right is invalid, it means that the user has the right.

[0066] The trigger time of the scheduled change task is the starting time of the effective time. The scheduled change task is triggered at the starting time. The first operation is performed on the user's authority by executing the scheduled change task, and the effectiveness flag corresponding to the execution result of the first operation is set to a valid state. The maintenance time corresponding to the execution result of the first operation is recorded. When the maintenance time reaches the length of the effective time, the effectiveness flag corresponding to the execution result of the first operation is modified to an invalid state.

[0067] For example, the corresponding permission identifier in the permission change message is Read, the first operation is to add, and the effective time is Monday to Friday of each week; the scheduled change task is a periodic task. At the beginning of Monday of the first week, the read permission corresponding to Read is added to the user permission, and the effectiveness identifier of the read permission is valid; at the end of Friday of the first week, the effectiveness identifier of the read permission is modified to an invalid state. From Monday to Friday of each subsequent week, there is no need to execute the scheduled change task, only the effectiveness identifier corresponding to the user permission needs to be modified.

[0068] In an embodiment of the present application, a first scheduled change task is generated based on the first operation corresponding to the permission change message and the effective time corresponding to the first operation; the first scheduled change task is used to indicate the execution of the first operation on the target permission, and the execution result of the first operation is only valid within the effective time. Compared with manual adjustment of user permissions, the permission management method provided in an embodiment of the present application can improve the efficiency of adjusting user permissions within a specified time.

[0069] Optionally, the effective time includes a start time point and an end time point; and generating a first scheduled change task according to the first operation carried by the permission change message and the effective time corresponding to the first operation includes:

[0070] Step 11: Generate a first subtask according to the first operation corresponding to the permission change message and the start time point corresponding to the first operation; the first subtask is used to instruct to perform the first operation on the user permission at the start time point;

[0071] Step 12: Generate a second subtask based on the first operation corresponding to the permission change message and the end time point corresponding to the first operation; the second subtask is used to indicate that the user permission is restored from the first state after executing the first operation to the second state before executing the first operation at the end time point.

[0072] In the embodiment of the present application, the user ID, permission ID, first operation, generation time, and end time corresponding to the permission change message are read. When dynamically adjusting user permissions, two scheduled tasks are set, each of which corresponds to a time point, and the two scheduled tasks jointly realize the dynamic adjustment of user permissions. The start time is the trigger time of the first subtask; the end time is the trigger time of the second subtask; the execution effect of the first subtask is opposite to the execution effect of the second subtask.

[0073] It should be noted that a permission modification function is set, and the permission modification function performs various operations on user permissions. At the start time point, the first subtask calls the first permission modification function to perform the first operation on the user permissions; at the end time point, the second subtask calls the second permission modification function to restore the user permissions to the state before the first operation is performed.

[0074] Exemplarily, user permissions are stored in a table in a database system, and each user has a corresponding user permission table. When the user name corresponding to the permission change message is "user123", the first operation is "grant", the permission identifier is "access_system", the generation time is "2024-04-01 10:00:00", and the end time is "2024-04-01 18:00:00". The first subtask is executed at 2024-04-01 10:00:00, and the permission corresponding to "access_system" is added to the permission table corresponding to "user123"; the second subtask is executed at 2024-04-01 18:00:00, and the permission corresponding to "access_system" in the permission table corresponding to "user123" is deleted.

[0075] In an embodiment of the present application, a first subtask is generated according to the first operation corresponding to the permission change message and the start time point corresponding to the first operation; the first subtask is used to indicate that the first operation is performed on the user permission at the start time point; a second subtask is generated according to the first operation corresponding to the permission change message and the end time point corresponding to the first operation; the second subtask is used to indicate that the user permission is restored from the first state after the first operation is performed to the second state before the first operation is performed at the end time point. In an embodiment of the present application, two scheduled tasks are set, each of which corresponds to a time point, and the two scheduled tasks jointly adjust the user permission within a specified time period to avoid abuse of permissions and improve the security of the system.

[0076] Optionally, the method further comprises:

[0077] Step 21: When the first policy type corresponding to the permission change message is a static permission policy, a change task is generated according to the second operation corresponding to the permission change message;

[0078] Step 22: Execute the change task to modify the user rights according to the second operation.

[0079] It should be noted that the static permission policy is a passive permission control policy. The static permission policy refers to the "set before use" approach, which means that before the user accesses the system resources, the system has already pre-set the user's access rights. After executing the change task and modifying the user's permissions according to the static permission policy, the user's permissions will remain unchanged unless manually modified.

[0080] The second operation may include: adding, deleting, and replacing.

[0081] Exemplarily, the user name corresponding to the permission change message is "user123", the first operation is "grant", the permission identifier is "access_system", and a change task is generated based on the permission change message. By executing the change task, the permission corresponding to "access_system" is added to "user123". During the subsequent system operation, unless manually modified, "user123" always has the permission corresponding to "access_system".

[0082] In an embodiment of the present application, when the first policy type corresponding to the permission change message is a static permission policy, a change task is generated according to the second operation corresponding to the permission change message; the change task is executed to modify the user permissions according to the second operation; and according to the different policy types corresponding to the permission change message, different methods are used to modify the user permissions, thereby improving the flexibility of managing user permissions.

[0083] Optionally, the permission adjustment request carries at least one permission identifier and a policy type corresponding to the permission identifier; and upon receiving the permission adjustment request, generating a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier, including:

[0084] When a permission adjustment request is received, at least one permission change message is generated according to each permission identifier carried in the permission adjustment request and the policy type corresponding to the permission identifier; one permission change message corresponds to one permission identifier.

[0085] It should be noted that the permission adjustment request can be for adjusting the permissions corresponding to at least one user. The permission adjustment request can carry parameters such as user ID, permission ID, policy type corresponding to the permission ID, change type, etc. The permission adjustment request is usually sent in JSON, XML or other structured data formats. After receiving the permission adjustment request, the permission adjustment request is parsed to extract each permission ID and the policy type corresponding to the permission ID.

[0086] Exemplarily, permission adjustment request A carries {"userId":"user123","permissions":[{"permissionId":"read_data","Type":"GRANT"},{"per missionId":"write_data","Type":"REVOKE"}]}, and permission adjustment request A refers to adding read data permission and deleting write data permission for user user123. Two permission change messages are generated according to permission adjustment request A, permission change message a is used to indicate adding read data permission for user user123, and permission change message b is used to indicate deleting write data permission for user user123.

[0087] In an embodiment of the present application, when a permission adjustment request is received, at least one permission change message is generated according to each permission identifier carried in the permission adjustment request and the policy type corresponding to the permission identifier; one permission change message corresponds to one permission identifier. Among them, the permission adjustment request carries at least one permission identifier, and multiple permission identifiers can be processed to improve the efficiency of managing user permissions.

[0088] Optionally, when the first policy type corresponding to the permission change message is a dynamic permission policy, before generating the scheduled change task according to the time rule corresponding to the permission change message, the method further includes:

[0089] Step 31: Add the permission change message to the message queue;

[0090] Step 32: Read the permission change message from the message queue according to a preset rule, and identify the first policy type corresponding to the permission change message.

[0091] A message queue (MQ) is a container for storing messages. It is essentially a queue for storing data. Message queues enable asynchronous processing of messages. Producers are responsible for creating permission change messages and sending them to message queues so that other services or applications can process the data asynchronously. Producers refer to applications or services that send permission change messages to message queues. Messages can be in the form of various data structures, such as text, binary data, JSON objects, etc. Consumers subscribe to message queues. When new messages arrive, consumers read messages from the queue and process them according to business logic. Consumers refer to applications or services that receive and process messages from message queues. After processing, consumers store the processing results in a database, send notifications, update caches, etc.

[0092] The consumer parses the received permission change message and extracts key information, such as user ID, permission ID, and policy type; and adopts the corresponding parsing method according to the format of the permission change message. The consumer identifies the policy type corresponding to each permission change message and executes the corresponding processing logic according to the policy type.

[0093] Exemplarily, the JSON format is used to represent the permission change message, and the permission change message a is used to indicate the addition of the user's permission to view reports from Monday to Friday each week, the permission change message b is used to indicate the revocation of the user's permission to edit documents, and the permission change message c is used to indicate the addition of the user's permission to access a specific API. After adding the permission change message a, the permission change message b, and the permission change message c to the message queue, read one permission change message from the message queue in turn according to the preset rules, and identify the first policy type corresponding to the permission change message. When the policy type is static, the user's permissions are adjusted according to the permission change message; when the policy type is dynamic, a scheduled task is generated according to the permission change message, and the scheduled task is executed at a predetermined time point to adjust the user's permissions.

[0094] like Figure 2 As shown in the figure, a schematic diagram of a permission management system is given. The permission management module generates permission change messages and adds permission change messages to the message queue. The permission message consumer

[0095] In an embodiment of the present application, a permission change message is added to a message queue; the permission change message is read from the message queue according to a preset rule, and the first policy type corresponding to the permission change message is identified. The sender does not need to wait for the receiver to process the message, and can continue to perform other tasks by putting the message into the queue, thereby improving the response speed and throughput of the system. In a high-concurrency scenario, the message queue can buffer burst traffic, prevent the system from directly facing request peaks, and make the system load more stable.

[0096] Optionally, the step of reading the permission change message from the message queue according to the prediction rule in step 32 includes:

[0097] According to a first-in-first-out rule, a permission change message is read from the message queue, and a first policy type corresponding to the permission change message is identified.

[0098] For example, the permission change message is represented in JSON format, and permission change message a is used to indicate that the user's permission to view reports is increased from Monday to Friday every week, permission change message b is used to indicate that the user's permission to edit documents is revoked, and permission change message c is used to indicate that the user's permission to access a specific API is increased. After adding permission change message a, permission change message b, and permission change message c to the message queue, the order in which the permission change messages are read from the message queue is permission change message a, permission change message b, and permission change message c.

[0099] In an embodiment of the present application, according to the first-in-first-out rule, the permission change message is read from the message queue, and the first policy type corresponding to the permission change message is identified. Orderly message processing can reduce unnecessary waiting and competition and improve the efficiency of reading permission change messages.

[0100] Optionally, the step of reading the permission change message from the message queue in step 32 includes:

[0101] Step 321: setting a priority for each permission change message included in the message queue;

[0102] Step 322: Read the permission change message from the message queue according to the priority level corresponding to each permission change message, and identify the first policy type corresponding to the permission change message.

[0103] It should be noted that the priority of permission change messages can be set according to at least one principle. Priority is set for each permission change message in the message queue according to the urgency of the permission change message; specifically, security-related permission changes, such as emergency revocation of access rights, have a higher priority than regular permission changes. Priority is set according to the number of users or system scope affected by the permission change, and messages that affect more users have a higher priority than messages that affect fewer users.

[0104] In the case where there are dependencies between permission change messages, specifically, the processing result of one message depends on the processing of another message, their priorities need to be adjusted to ensure the correct processing order. For example, there is an enterprise resource planning system in which user permissions are divided into multiple levels, including basic access permissions, advanced operation permissions, and administrator permissions. In order to maintain the security of the system and the integrity of the data, it is stipulated that users must first obtain basic access permissions before they can apply for advanced operation permissions; similarly, users must first have advanced operation permissions before they can be granted administrator permissions. Permission change message a adds basic access permissions to the user, and permission change message b adds advanced operation permissions to the user. The execution of permission change message b depends on permission change message a having been executed.

[0105] The priority of each permission change message may be set based on the urgency of the permission change message or the dependency between the permission change messages; or the priority of each permission change message may be set based on the urgency of the permission change message and the dependency between the permission change messages.

[0106] The permission change messages are read from the message queue in order from high to low priority according to the priority of each permission change message.

[0107] In an embodiment of the present application, a priority is set for each permission change message included in the message queue; according to the priority corresponding to each permission change message, the permission change message is read from the message queue, and the first policy type corresponding to the permission change message is identified, so that high-priority permission change messages can be responded to in a timely manner, thereby improving the processing efficiency of the permission change messages.

[0108] Optionally, the method further comprises:

[0109] Step 41: upon receiving an access request from a first user, reading the user rights corresponding to the first user from a cache; the access request carries a target object that the first user wants to access;

[0110] Step 42: if the user rights include the access rights corresponding to the target object, allow the user to access the target object;

[0111] Step 43: If the user rights do not include the access rights corresponding to the target object, an error prompt is returned.

[0112] It should be noted that monitoring and receiving user access requests are usually implemented through network protocols. Once the request is received, the access request is parsed to extract the user identity, such as user ID, user name, token, and the target object of the user request. The target object refers to resources or operation information.

[0113] Based on the user identity extracted from the request, query the cache for the corresponding permission data of the user. If the permission data of the user exists in the cache, verify whether the user has the right to access the requested resource or perform the requested operation based on the obtained permission data. After successful verification, the system can allow the user to access or perform the operation, and may update some access statistics; if the verification fails, an error prompt is returned, indicating that the first user does not have the permission to access the target object.

[0114] If the user's permission data does not exist in the cache, it is necessary to query the data from persistent storage, such as memory. After querying the permission data, the system can cache it so that subsequent requests can access it quickly. Before the data is cached, the target object denies the user's access request or provides a degraded service, such as a read-only service.

[0115] In an embodiment of the present application, when an access request from a first user is received, the user rights corresponding to the first user are read from a cache; the access request carries a target object that the first user desires to access; when the user rights include access rights corresponding to the target object, the user is allowed to access the target object; when the user rights do not include access rights corresponding to the target object, an error prompt is returned to prevent users who do not have access rights from accessing the target object, thereby ensuring the security of the target object.

[0116] In summary, the embodiment of the present application provides a permission management method, in the case of receiving a permission adjustment request, generating a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier; the permission change message is used to indicate that the user permission corresponding to the permission identifier is adjusted according to the adjustment target; the permission change message is added to the message queue; the permission change message is read from the message queue according to the preset rules, and the first policy type corresponding to the permission change message is identified to improve the efficiency of reading the permission change message. In the case where the first policy type corresponding to the permission change message is a dynamic permission policy, a scheduled change task is generated according to the time rule corresponding to the permission change message; in the case where the first policy type corresponding to the permission change message is a static permission policy, a change task is generated according to the second operation corresponding to the permission change message; the change task is executed to modify the user permission according to the second operation, thereby improving the efficiency of modifying the user permission.

[0117] Device Embodiment

[0118] Reference Figure 3 , shows a structural block diagram of a rights management device of the present invention, the device comprising:

[0119] The message generation module 310 is used to generate a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier when receiving the permission adjustment request; the permission change message is used to indicate that the user permission corresponding to the permission identifier is adjusted according to the adjustment target;

[0120] A task generation module 320 is used to generate a scheduled change task according to a time rule corresponding to the permission change message when the first policy type corresponding to the permission change message is a dynamic permission policy;

[0121] The dynamic adjustment module 330 is used to execute the scheduled change task to adjust the user authority corresponding to the authority identifier according to the adjustment target at a preset time point corresponding to the scheduled change task.

[0122] Optionally, the task generation module includes:

[0123] A scheduled task generation module is used to generate a first scheduled change task based on the first operation corresponding to the permission change message and the effective time corresponding to the first operation; the first scheduled change task is used to indicate the execution of the first operation on the target permission, and the execution result of the first operation is only valid within the effective time.

[0124] Optionally, the effective time includes a start time point and an end time point; and the scheduled task generation module includes:

[0125] A first subtask generating module, configured to generate a first subtask according to a first operation corresponding to the permission change message and a start time point corresponding to the first operation; the first subtask is configured to instruct to perform the first operation on the user permission at the start time point;

[0126] A second subtask generating module is used to generate a second subtask based on the first operation corresponding to the permission change message and the end time point corresponding to the first operation; the second subtask is used to indicate that the user permission is restored from the first state after executing the first operation to the second state before executing the first operation at the end time point.

[0127] Optionally, the device further comprises:

[0128] a change task generating module, configured to generate a change task according to a second operation corresponding to the permission change message when the first policy type corresponding to the permission change message is a static permission policy;

[0129] An execution module is used to execute the change task to modify the user authority according to the second operation.

[0130] Optionally, the permission adjustment request carries at least one permission identifier and a policy type corresponding to the permission identifier; and the message generating module includes:

[0131] The message generation submodule is used to generate at least one permission change message according to each permission identifier carried in the permission adjustment request and the policy type corresponding to the permission identifier when receiving the permission adjustment request; one permission change message corresponds to one permission identifier.

[0132] Optionally, the device further comprises:

[0133] An adding module, used for adding the permission change message to a message queue;

[0134] The message reading module is used to read the permission change message from the message queue according to a preset rule and identify a first policy type corresponding to the permission change message.

[0135] Optionally, the device further comprises:

[0136] A permission reading module, configured to read the user permission corresponding to the first user from the cache when receiving an access request from the first user; the access request carries the target object that the first user wants to access;

[0137] An access module, configured to allow the user to access the target object if the user rights include the access rights corresponding to the target object;

[0138] The prompt module is used to return an error prompt when the user authority does not include the access authority corresponding to the target object.

[0139] In summary, the embodiment of the present application provides a permission management device, which, upon receiving a permission adjustment request, generates a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier; the permission change message is used to indicate that the user permission corresponding to the permission identifier is adjusted according to the adjustment target; the permission change message is added to the message queue; the permission change message is read from the message queue according to a preset rule, and the first policy type corresponding to the permission change message is identified, thereby improving the efficiency of reading the permission change message. In the case where the first policy type corresponding to the permission change message is a dynamic permission policy, a scheduled change task is generated according to the time rule corresponding to the permission change message; in the case where the first policy type corresponding to the permission change message is a static permission policy, a change task is generated according to the second operation corresponding to the permission change message; the change task is executed to modify the user permission according to the second operation, thereby improving the efficiency of modifying the user permission.

[0140] The rights management device in the embodiment of the present application can be an electronic device or a component in the electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices other than a terminal. Exemplarily, the electronic device can be a GPU BOX, a mobile phone, a tablet computer, a laptop computer, a PDA, a vehicle-mounted electronic device, a mobile Internet device (Mobile Internet Device, MID), an augmented reality (augmented reality, AR) / virtual reality (virtual reality, VR) device, a robot, a wearable device, an ultra-mobile personal computer (ultra-mobile personal computer, UMPC), a netbook or a personal digital assistant (personal digital assistant, PDA), etc. It can also be a server, a network attached storage (Network Attached Storage, NAS), a personal computer (personal computer, PC), a television (television, TV), a teller machine or a self-service machine, etc., which is not specifically limited in the embodiment of the present application.

[0141] The rights management device provided in the embodiment of the present application can achieve Figure 1 To avoid repetition, the various processes implemented by the method embodiment are not described here.

[0142] Alternatively, if Figure 4 As shown, an embodiment of the present application also provides an electronic device, including a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the program or instructions are executed by the processor, the various steps of the above-mentioned rights management method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, they are not described here.

[0143] In an embodiment of the present application, the memory may be used to store software programs and various data. The memory may mainly include a first storage area for storing programs or instructions and a second storage area for storing data, wherein the first storage area may store an operating system, an application program or instructions required for at least one function (such as a sound playback function, an image playback function, etc.), etc. In addition, the memory may include a volatile memory or a non-volatile memory, or the memory may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), a synchronous dynamic random access memory (SDRAM), a double data rate synchronous dynamic random access memory (DDRSDRAM), an enhanced synchronous dynamic random access memory (ESDRAM), a synchronous link dynamic random access memory (SLDRAM) and a direct memory bus random access memory (DRRAM). The memory in the embodiments of the present application includes but is not limited to these and any other suitable types of memory.

[0144] The processor may include one or more processing units; optionally, the processor integrates an application processor and a modem processor, wherein the application processor mainly processes operations related to the operating system, user interface, and application programs, and the modem processor mainly processes wireless communication signals, such as a baseband processor. It is understandable that the modem processor may not be integrated into the processor.

[0145] An embodiment of the present application also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the various processes of the above-mentioned rights management method embodiment are implemented and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0146] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory ROM, a random access memory RAM, a magnetic disk or an optical disk.

[0147] An embodiment of the present application provides a computer program product, which is stored in a storage medium. The program product is executed by at least one processor to implement the various processes of the above-mentioned rights management method embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0148] It should be noted that, in this article, the terms "comprise", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises one..." does not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the method and device in the embodiment of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method may be performed in an order different from that described, and various steps may also be added, omitted or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0149] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the relevant technology, can be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM / RAM, a disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0150] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims

1. A rights management method, characterized in that: The method comprises: In the case of receiving a permission adjustment request, generating a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier; the permission change message is used to indicate that the user permission corresponding to the permission identifier is adjusted according to the adjustment target; In a case where the first policy type corresponding to the permission change message is a dynamic permission policy, generating a scheduled change task according to a time rule corresponding to the permission change message; The scheduled change task is executed to adjust the user authority corresponding to the authority identifier according to the adjustment target at a preset time point corresponding to the scheduled change task.

2. The method according to claim 1, characterized in that In the case where the first policy type is a dynamic permission policy, generating a scheduled change task according to a time rule corresponding to the permission change message includes: A first scheduled change task is generated based on the first operation corresponding to the permission change message and the effective time corresponding to the first operation; the first scheduled change task is used to indicate the execution of the first operation on the target permission, and the execution result of the first operation is only valid within the effective time.

3. The method according to claim 2, characterized in that The effective time includes a start time point and an end time point; the generating a first scheduled change task according to the first operation carried by the permission change message and the effective time corresponding to the first operation includes: Generate a first subtask according to the first operation corresponding to the permission change message and the start time point corresponding to the first operation; the first subtask is used to instruct to perform the first operation on the user permission at the start time point; A second subtask is generated based on the first operation corresponding to the permission change message and the end time point corresponding to the first operation; the second subtask is used to indicate that the user permission is restored from the first state after executing the first operation to the second state before executing the first operation at the end time point.

4. The method according to claim 1, characterized in that: The method further comprises: In a case where the first policy type corresponding to the permission change message is a static permission policy, generating a change task according to the second operation corresponding to the permission change message; The change task is executed to modify the user authority according to the second operation.

5. The method according to claim 1, characterized in that The permission adjustment request carries at least one permission identifier and a policy type corresponding to the permission identifier; upon receiving the permission adjustment request, generating a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier, including: When a permission adjustment request is received, at least one permission change message is generated according to each permission identifier carried in the permission adjustment request and the policy type corresponding to the permission identifier; one permission change message corresponds to one permission identifier.

6. The method according to claim 1, characterized in that In a case where the first policy type corresponding to the permission change message is a dynamic permission policy, before generating a scheduled change task according to a time rule corresponding to the permission change message, the method further includes: Adding the permission change message to a message queue; The permission change message is read from the message queue according to a preset rule, and a first policy type corresponding to the permission change message is identified.

7. The method according to claim 1, characterized in that The method further comprises: Upon receiving an access request from a first user, reading the user rights corresponding to the first user from a cache; the access request carries a target object that the first user desires to access; In a case where the user rights include access rights corresponding to the target object, allowing the user to access the target object; If the user rights do not include the access rights corresponding to the target object, an error prompt is returned.

8. A rights management device, characterized in that: The device comprises: A message generation module, configured to generate a permission change message according to the permission identifier carried in the permission adjustment request and the adjustment target corresponding to the permission identifier, upon receiving the permission adjustment request; the permission change message is used to indicate that the user permission corresponding to the permission identifier is adjusted according to the adjustment target; A task generation module, configured to generate a timed change task according to a time rule corresponding to the permission change message when the first policy type corresponding to the permission change message is a dynamic permission policy; The dynamic adjustment module is used to execute the scheduled change task to adjust the user authority corresponding to the authority identifier according to the adjustment target at a preset time point corresponding to the scheduled change task.

9. An electronic device, characterized in that: The electronic device includes a processor, a memory, a communication interface and a communication bus, and the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store executable instructions, and the executable instructions enable the processor to execute the permission management method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that: The readable storage medium stores programs or instructions, and when the programs or instructions are executed by the processor, the rights management method described in any one of claims 1 to 7 is implemented.

Images