Method, apparatus, computer device and storage medium for managing permissions

Abstract

The application relates to a permission management method and device, computer equipment and a storage medium. The method comprises the following steps: in response to a resource access request of a target user, obtaining a user token of the target user and permission acquisition logic of a data resource to be accessed; the permission acquisition logic comprises at least one access logic of the data resource to be accessed; obtaining a role permission set of the target user according to the user token; the role permission set comprises operation permissions of the target user for a plurality of data resources; in the case that the operation permissions of each data resource in the role permission set meet any one of the access logics in the permission acquisition logic, processing the resource access request of the target user. The method can flexibly manage user permissions and improve data security.

Description

Technical Field

[0001] This application relates to the field of computer security technology, and in particular to a method, apparatus, computer device, and storage medium for access control. Background Technology

[0002] With the rapid development of computer technology, data transmission and storage have become increasingly convenient, but the risk of data breaches has also increased. Under these circumstances, data security has become a major concern.

[0003] In related technologies, when protecting data in information systems, user access permissions are usually restricted based on the interface dimension. Access control models are used to verify the user's access interface permissions, and the user is allowed to process the data corresponding to the interface after the permission verification is successful.

[0004] However, the access control methods in these technologies are not very flexible and still suffer from low data security. Summary of the Invention

[0005] Therefore, it is necessary to provide a permission management method, device, computer equipment, and storage medium that can flexibly manage user permissions and improve data security in response to the above-mentioned technical problems.

[0006] Firstly, this application provides a method for managing access rights, the method comprising:

[0007] In response to a resource access request from a target user, the system acquires the target user's user token and the permission acquisition logic for the data resource to be accessed; the permission acquisition logic includes at least one access logic for the data resource to be accessed.

[0008] The target user's set of roles and permissions is obtained based on the user token; the set of roles and permissions includes the target user's operation permissions for multiple data resources.

[0009] If the operation permissions of each data resource in the role permission set satisfy any of the access logics in the permission acquisition logic, process the resource access request of the target user.

[0010] In the technical solution provided in this application embodiment, in response to a target user's resource access request, the system obtains the target user's user token and the permission acquisition logic for the data resource to be accessed, and obtains the target user's role permission set based on the user token. The permission acquisition logic includes at least one access logic for the data resource to be accessed, and the role permission set includes the target user's operation permissions for multiple data resources. Then, if the operation permissions for each data resource in the role permission set satisfy any one of the access logics in the permission acquisition logic, the target user's resource access request is processed. In this method, the target user's role permission set is determined based on the user token to determine the target user's operation permissions for multiple data resources. Then, the permission acquisition logic for the data resource to be accessed is compared with the role permission set, and if the role permission set satisfies any one of the access logics for the resource to be accessed, the target user's resource access request is processed. This is equivalent to defining the target user's operation permissions and the operation permissions for the data to be accessed from a data dimension. Through refined comparison at the data dimension, the system precisely controls the target user's data operation permissions to prevent the target user from accessing system data outside their authorized scope, thus ensuring the security of system data.

[0011] In one embodiment, obtaining the target user's set of role permissions based on the user token includes:

[0012] Parse the user token to obtain the target user's initial permission set;

[0013] The permissions in the initial permission set are filtered to obtain the role permission set.

[0014] In the technical solution provided in this application embodiment, the user token is parsed to obtain the initial permission set of the target user. Then, the permissions in the initial permission set are filtered to obtain the role permission set. In this way, the role permission set determined by different levels of permission management is matched with multiple dimensions such as the target user's role, login environment, and access system, thereby improving the effectiveness of the role permission set.

[0015] In one embodiment, the user token is parsed to obtain the initial set of permissions for the target user, including:

[0016] Parse the user token to obtain the target user's user identifier;

[0017] Based on the user identifier, determine at least one role information of the target user;

[0018] The initial permissions matched with each role's information are aggregated to obtain the initial permission set.

[0019] In the technical solution provided in this application embodiment, based on the user token, the user identifier, role information, and initial permissions matching each role information of the target user are determined sequentially, and the initial permissions are summarized to obtain an initial permission set. The initial permission set obtained in this way is close to the user's role in the system, avoiding the user from accessing data beyond the scope of their role permissions, and providing a reliable basis for subsequently determining the role permission set.

[0020] In one embodiment, permissions in the initial permission set are filtered to obtain a role-based permission set, including:

[0021] Obtain the environment feature list for the deployment environment and the authorized feature list for the system;

[0022] In the initial permission set, remove permissions that are not in the environment function list and authorized function list to obtain the role permission set.

[0023] In the technical solution provided in this application embodiment, based on the environment function list of the deployment environment and the authorized function list of the system, the access permissions of data content in the initial permission set are filtered from two dimensions: deployment environment and system permission. The role permission set determined in this way supports users to access business data within their own role and the authorized scope of the system and environment, avoiding accidental or incorrect access to system data, thereby improving the security of system data.

[0024] In one embodiment, the resource access request carries the resource identifier and access type of the data resource to be accessed; the process of obtaining the permission acquisition logic for the data resource to be accessed includes:

[0025] Retrieve multiple access logics that match both the resource identifier and access type from the preset access logic mapping table; the access logic mapping table includes multiple data resources and multiple access logics corresponding to each data resource;

[0026] By summarizing the various access logics corresponding to the data resource to be accessed, the permission acquisition logic for the data resource to be accessed is obtained.

[0027] In the technical solution provided in this application embodiment, multiple access logics that match both the resource identifier and the access type are obtained from a preset access logic mapping table. The multiple access logics corresponding to the data resource to be accessed are summarized to obtain the permission acquisition logic of the data resource to be accessed. This supports target users to access the data resource to be accessed in different ways, thereby improving the diversity and flexibility of data access.

[0028] In one embodiment, the user token generation process includes:

[0029] Receive encrypted information and key pair identifiers sent by the client;

[0030] Based on the key pair identifier, determine the private key in the key pair;

[0031] If the encrypted information is successfully decrypted using the private key, a user token is generated based on the decrypted data and the target user's login information.

[0032] In the technical solution provided in this application embodiment, the encrypted information and key pair identifier sent by the client are received, the private key of the encrypted information is determined according to the key pair identifier, and the encrypted information is decrypted asymmetrically to obtain plaintext data, so as to improve the security of data transmission. Then, a user token is generated based on the decrypted plaintext data and the login information of the target user, so as to provide a reliable parsing basis for subsequent user resource access.

[0033] In one embodiment, the method further includes:

[0034] Upon detecting a user login to the system, a key pair is generated; the key pair includes a public key and a private key; the public key is used to instruct the encryption of key data in the login information to obtain ciphertext information.

[0035] If successful decryption of the ciphertext based on the private key is detected, delete the key pair.

[0036] In the technical solution provided in this application embodiment, when a user is detected logging into the system, a key pair is generated to encrypt and decrypt key data in the login information, ensuring the security of the user's key data during network transmission. Then, when the decryption of the ciphertext information based on the private key is successfully detected, the key pair is deleted, and the system security is further enhanced by using the key only once.

[0037] Secondly, this application also provides an access control device, comprising:

[0038] The request and response module is used to respond to the resource access request of the target user, obtain the user token of the target user and the permission acquisition logic of the data resource to be accessed; the permission acquisition logic includes at least one access logic of the data resource to be accessed.

[0039] The permission acquisition module is used to obtain the set of role permissions for a target user based on the user token; the set of role permissions includes the target user's operation permissions for multiple data resources;

[0040] The request processing module is used to process the resource access request of the target user if the role permission set satisfies any of the access logics in the permission acquisition logic.

[0041] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method in any of the embodiments of the first aspect described above.

[0042] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method in any of the embodiments of the first aspect described above.

[0043] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method in any of the embodiments of the first aspect described above. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is an application environment diagram of the permission management method in one embodiment;

[0046] Figure 2 This is a flowchart illustrating a permission management method in one embodiment;

[0047] Figure 3 This is a flowchart illustrating the steps for obtaining a set of role permissions in one embodiment;

[0048] Figure 4 This is a flowchart illustrating the initial permission set acquisition step in one embodiment;

[0049] Figure 5 This is a flowchart illustrating the steps for obtaining the role permission set in another embodiment;

[0050] Figure 6 This is a flowchart illustrating the access logic acquisition steps in one embodiment;

[0051] Figure 7 This is a flowchart illustrating the user token generation steps in one embodiment;

[0052] Figure 8 This is a flowchart illustrating the key pair processing steps in one embodiment;

[0053] Figure 9 This is a flowchart illustrating the user token generation step in another embodiment;

[0054] Figure 10 This is a flowchart illustrating the permission management method in another embodiment;

[0055] Figure 11 This is a flowchart illustrating the permission management method in another embodiment;

[0056] Figure 12 This is a structural block diagram of a permission management device in one embodiment;

[0057] Figure 13 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0059] The technical background of the embodiments of this application will be described below.

[0060] With the increasing frequency of data breaches, businesses and consumers are paying more and more attention to data security. Therefore, it is necessary to take security measures such as data encryption and access control to protect user data from being leaked.

[0061] In related technologies, user access control is typically based on permission verification across the entire information system. Once a user's access permission is verified, they are allowed to access all data within the system. However, for systems such as cluster systems and distributed systems that support a large number of users, the actual access permissions for different users vary. In this case, the management methods in related technologies are not flexible enough and cannot provide targeted permission management for users, resulting in a low level of data security in the system.

[0062] Based on this, the embodiments of this application provide a permission management method that allows for flexible management and verification of permissions for different users, enabling users to access data supported by their own permissions, avoiding data leakage in the system, and improving the security of system data.

[0063] The permission management method provided in this application embodiment can be applied to, for example, Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located on the cloud or other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0064] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings, taking the server as the execution subject.

[0065] In one exemplary embodiment, such as Figure 2 As shown, a permission management method is provided, including the following steps:

[0066] S201, in response to the resource access request of the target user, obtain the user token of the target user and the permission acquisition logic of the data resource to be accessed; the permission acquisition logic includes at least one access logic of the data resource to be accessed.

[0067] The data resource to be accessed includes data content, which can be a single file or multiple files. A resource access request is a request triggered by the target user on the client side for the data resource to be accessed. In practical applications, the user triggers a resource access request on the client side, and the server receives the resource access request sent by the client.

[0068] The resource access request carries the target user's user token, the data identifier of the data resource to be accessed, and the access type. The target user's user token is generated upon successful login to the system and includes login information such as user ID, login name, login type, and login time. It is stored on the client side and used to verify the target user's identity. The data identifier identifies the location of the data resource to be accessed in the database and can be the data resource name, the file storage address of the data to be accessed, etc. The access type refers to operations such as viewing, modifying, adding, or deleting data content. For example, the resource access request might specify modifying table A, merging the modified table A with table B, or modifying table B.

[0069] In response to a target user's resource access request, the user token of the target user is extracted from the resource access request to verify the identity of the target user; at the same time, the data identifier and access type of the data resource to be accessed are identified from the resource access request, and the permission acquisition logic of the data resource to be accessed is further obtained based on the data identifier and access type.

[0070] Taking a resource access request as an example of modifying table B, if both file 1 and file 2 store the storage location of table B, then the permission acquisition logic for this resource access request has at least two possibilities: ① query permission for file 1 and modification permission for table B, ② query permission for file 2 and modification permission for table B.

[0071] Taking a resource access request as an example of modifying table A and merging the modified table A and table B, the permission acquisition logic of this resource access request has at least two possibilities: ① query permission, modify permission, and save permission for table A, modify permission and save permission for table B, or ② merge permission and save permission for tables A and B, and modify permission for the merged file.

[0072] S202, Obtain the target user's set of role permissions based on the user token; the set of role permissions includes the target user's operation permissions for multiple data resources.

[0073] During system management, roles in the information system are predefined, and each role is given operation permissions for specified data resources. Then, different roles are assigned to system users, granting them operation permissions for data resources.

[0074] In this application, the user token includes at least one role information of the target user, and each role information corresponds to an operation permission for a data resource. In this case, by parsing the user token, the target user's role information is obtained, and the operation permissions for the data resources corresponding to each role information are summarized to obtain the target user's role permission set.

[0075] S203: If the operation permissions of each data resource in the role permission set satisfy any one of the access logics in the permission acquisition logic, process the resource access request of the target user.

[0076] Each access logic in the permission acquisition logic is broken down into role permissions for multiple data resources, resulting in a set of access permissions for each access logic. If the operation permissions of each data resource in the role permission set cover any set of access permissions, then the permission acquisition logic is satisfied, and the resource access request is processed.

[0077] Continuing with the example of modifying table B using a resource access request, if the role permission set includes query permission for file 1 and modification permission for table B, then the visual editing interface of table B will be displayed so that the target user can modify table B.

[0078] In this embodiment, in response to a target user's resource access request, the system obtains the target user's user token and the permission acquisition logic for the data resource to be accessed, and then obtains the target user's role permission set based on the user token. The permission acquisition logic includes at least one access logic for the data resource to be accessed, and the role permission set includes the target user's operation permissions for multiple data resources. Next, if the operation permissions for each data resource in the role permission set satisfy any one of the access logics in the permission acquisition logic, the target user's resource access request is processed. This method determines the target user's role permission set based on the user token to determine the target user's operation permissions for multiple data resources. Then, the permission acquisition logic for the data resource to be accessed is compared with the role permission set. If the role permission set satisfies any one of the access logics for the resource to be accessed, the target user's resource access request is processed. This is equivalent to defining the target user's operation permissions and the operation permissions for the data to be accessed from a data dimension. Through refined comparison at the data dimension, the system precisely controls the target user's data operation permissions to prevent the target user from accessing system data outside their authorized scope, thus ensuring the security of system data.

[0079] As described in the foregoing embodiments, when managing permissions for a target user, the set of role permissions and the permission acquisition logic for the data resource to be accessed are compared to determine whether the target user has the necessary access permissions. Next, one possible method for obtaining the set of role permissions will be explained.

[0080] In one exemplary embodiment, such as Figure 3 As shown, obtaining the target user's set of role permissions based on the user token includes the following steps:

[0081] S301, parse the user token to obtain the initial permission set of the target user.

[0082] User tokens include identifiers for the current access environment, such as development environment identifiers, production environment identifiers, and test environment identifiers.

[0083] Optionally, the user token is parsed to obtain the environment identifier of the login environment. Based on the environment identifier, the user permissions supported by the current access environment are determined. For example, the development environment supports user debugging, user modification, and user query. Then, the user permissions supported by the current access environment are initially filtered based on the predefined authorized function list of the login system to select the user permissions in the authorized function list as the initial permission set for the target user.

[0084] S302, filter the permissions in the initial permission set to obtain the role permission set.

[0085] User tokens can include user role information to limit the range of data a target user can access. In this case, based on the user's role information, a range of data content matching the role information can be filtered from the initial permission set. Then, the data content and the initial permission set are combined to obtain the target user's role permission set.

[0086] In this embodiment, the user token is parsed to obtain the initial permission set of the target user. Then, the permissions in the initial permission set are filtered to obtain the role permission set. In this way, the role permission set determined by different levels of permission management is matched with multiple dimensions such as the target user's role, login environment, and access system, thereby improving the effectiveness of the role permission set.

[0087] In one exemplary embodiment, such as Figure 4 As shown, another possible implementation of the aforementioned step S301, "parse the user token to obtain the initial permission set of the target user," includes the following steps:

[0088] S401, parse the user token to obtain the user identifier of the target user.

[0089] The user identifier can be a user's login name or login account, used to uniquely identify the target user's identity. In this embodiment, the user identifier is encapsulated in a user token. After obtaining the user token, the user identifier of the target user is determined by identifying the information type in the user token.

[0090] S402, Based on the user identifier, determine at least one role information of the target user.

[0091] In practical applications, one user identifier corresponds to one or more role information. The user identifiers and corresponding role information of all logged-in users in the system are stored in a mapping table in the database or client. After determining the user identifier of the target user, the mapping table is used to query the role information corresponding to that user identifier.

[0092] S403 summarizes the initial permissions matched with each role's information to obtain the initial permission set.

[0093] In practical applications, each role information corresponds to an initial permission, which refers to access permissions for a specific business data. All role information and initial permissions in the system are stored in a table format in the database or on the client side. After determining the role information for the target user, the initial permissions corresponding to each role information are queried from the table, and the retrieved initial permissions are summarized to obtain the initial permission set.

[0094] In this embodiment of the application, based on the user token, the user identifier, role information, and initial permissions matching each role information of the target user are determined sequentially, and the initial permissions are summarized to obtain an initial permission set. The initial permission set obtained in this way is close to the user's role in the system, which avoids the user from accessing data beyond the scope of their role permissions, and provides a reliable basis for subsequently determining the role permission set.

[0095] In one exemplary embodiment, such as Figure 5 As shown, another possible implementation of the aforementioned step S302, "filtering the permissions in the initial permission set to obtain the role permission set," includes the following steps:

[0096] S501, obtain the list of environment functions for the deployment environment and the list of authorized functions for the system.

[0097] In this context, "deployment environment" refers to the environment type the target user logs into, such as development, testing, or production environments. The environment function list refers to the set of permissions for the allowed operation types within that environment. "System" refers to the computer system the user logs into, and the system's authorized function list refers to the predefined scope of permitted functions within the computer system. In other words, the environment function list is an environment-level access permission list used to restrict access to data content in the initial permission set from the perspective of the deployment environment; the authorized function list is a system-level access permission list used to restrict access to data content in the initial permission set from the perspective of system permissions.

[0098] S502, among the multiple permissions in the initial permission set, delete the permissions that are not in the environment function list and the authorized function list to obtain the role permission set.

[0099] Optionally, the environment function list includes operation types for multiple business data, and the authorization function list also includes operation types for multiple business data. Each permission in the initial permission set includes one operation type for one business data. Invalid permissions in the initial permission set are removed from both the business data content and operation type dimensions to obtain the valid role permission set for the target user.

[0100] In the initial permission set, delete permissions that differ from those in the environment function list in both data content and access permission type. Also delete permissions from the authorized function list that differ from those in both data content and access permission type.

[0101] In this embodiment, based on the environment function list of the deployment environment and the authorized function list of the system, the access permissions of data content in the initial permission set are filtered from two dimensions: deployment environment and system permissions. The determined role permission set supports users to access business data within their own roles and the authorized scope of the system and environment, avoiding accidental or incorrect access to system data, thereby improving the security of system data.

[0102] The foregoing embodiments have provided a detailed explanation of how to obtain the set of role permissions. Next, we will further explain how to obtain the permission acquisition logic for the data resources to be accessed.

[0103] In one exemplary embodiment, such as Figure 6 As shown, the resource access request carries the resource identifier and access type of the data resource to be accessed; the process of obtaining the permission acquisition logic for the data resource to be accessed includes the following steps:

[0104] S601, retrieve multiple access logics that match both the resource identifier and access type from the preset access logic mapping table; the access logic mapping table includes multiple data resources and multiple access logics corresponding to each data resource.

[0105] Data resource access logic refers to the access method in which the content of a data resource is determined in the system and access permissions for that data resource are granted.

[0106] For any data resource to be accessed, there can be multiple access logics. For example, if table B is modified, the resource identifier is "table B" and the access type is "modification". The access logic of the data resource to be accessed is determined based on the file storing the location of table B. If both file 1 and file 2 store the storage location of table B, the permission acquisition logic of the data resource to be accessed can be: query permission for file 1 and modification permission for table B, or it can be: query permission for file 2 and modification permission for table B.

[0107] S602, summarize the various access logics corresponding to the data resource to be accessed, and obtain the permission acquisition logic for the data resource to be accessed.

[0108] By summarizing the various access logics corresponding to the data resource to be accessed, the permission acquisition logic for the data resource to be accessed is obtained.

[0109] In this embodiment, multiple access logics that match both the resource identifier and the access type are obtained from a preset access logic mapping table. The multiple access logics corresponding to the data resource to be accessed are summarized to obtain the permission acquisition logic of the data resource to be accessed. This allows the target user to access the data resource to be accessed in different ways, thereby improving the diversity and flexibility of data access.

[0110] In practical applications, the target user first logs into the system and then accesses the data resources within the system. During the login process, the server generates a user token for the target user. After logging into the system, when accessing data resources, the server manages user permissions by parsing the user token, such as verifying whether the user's access has timed out and obtaining the user's role and permission set, etc.

[0111] In one exemplary embodiment, such as Figure 7 As shown, the user token generation process includes the following steps:

[0112] S701 receives encrypted information and key pair identifiers sent by the client.

[0113] A key pair consists of an asymmetric public key and a private key. The public key is used to encrypt plaintext to generate ciphertext, and the private key is used to decrypt the ciphertext to obtain the plaintext. The key pair identifier refers to the identifier of the key pair to which the public key belongs.

[0114] The client encrypts the key data entered by the target user on the system login interface using the public key, obtaining ciphertext information. This ciphertext information is then sent to the server. Upon receiving the ciphertext information, the server decrypts it based on the key pair identifier.

[0115] S702, based on the key pair identifier, determines the private key in the key pair.

[0116] S703, if the encrypted information is successfully decrypted based on the private key, generates a user token based on the decrypted data and the target user's login information.

[0117] The database is queried to see if the private key of the key pair corresponding to the key pair exists. If it exists, the encrypted information is decrypted using the private key to obtain the plaintext information. This plaintext information is then combined with the target user's login information, such as login time, user account, and username, to encapsulate the plaintext information and obtain the user token.

[0118] In this embodiment, the encrypted information and key pair identifier sent by the client are received. The private key of the encrypted information is determined according to the key pair identifier, and it is asymmetrically decrypted to obtain plaintext data, thereby improving the security of data transmission. Then, a user token is generated based on the decrypted plaintext data and the login information of the target user, providing a reliable parsing basis for subsequent user resource access.

[0119] In one exemplary embodiment, such as Figure 8 As shown, the method also includes the following steps:

[0120] S801, upon detecting a user login to the system, generates a key pair; the key pair includes a public key and a private key; the public key is used to instruct the encryption of key data in the login information to obtain ciphertext information.

[0121] Upon detecting a user login, in response to a key pair generation request sent by the client, a random asymmetric key pair is generated, including a public key and a private key. The key pair identifier and the public key are then sent to the client. After receiving the public key, the client encrypts the critical information entered by the user for login, such as the login key, to obtain ciphertext information.

[0122] S802, if successful decryption of ciphertext information based on the private key is detected, delete the key pair.

[0123] After receiving the encrypted information sent by the client, the key is decrypted using the private key of the key pair. If the decryption is successful, the key pair is deemed to have been used and is confirmed to be invalid, and then deleted.

[0124] In this embodiment, when a user is detected logging into the system, a key pair is generated to encrypt and decrypt key data in the login information, ensuring the security of the user's key data during network transmission. Then, when the decryption of the ciphertext information based on the private key is successfully detected, the key pair is deleted, and the system's security is further enhanced by using the key only once.

[0125] In one exemplary embodiment, such as Figure 9 As shown, the user token generation process in a user login scenario includes the following steps:

[0126] S901 responds to the key generation request sent by the client and generates a key pair.

[0127] S902, receive the key pair identifier, ciphertext, and login information sent by the client; the ciphertext is obtained by the client encrypting the key data based on the public key.

[0128] S903, based on the key pair identifier, query whether the private key exists in the key pair.

[0129] S904, if it exists, decrypt the ciphertext using the private key to obtain the plaintext data.

[0130] S905 verifies the validity of plaintext data and login information.

[0131] S906, if the verification is successful, a user token is generated.

[0132] S907, a login success message is returned.

[0133] If S908 does not exist, a login failure message will be returned.

[0134] In this embodiment of the application, to ensure the security of users' critical data during network transmission, the critical data is asymmetrically encrypted, and the security of the system is further enhanced by using the key only once.

[0135] In one exemplary embodiment, such as Figure 10 As shown, in the scenario of resource access after user login, the permission verification method includes the following steps:

[0136] S1001, in response to a resource access request triggered by the target user on the client, parses the user token to obtain the user identifier.

[0137] S1002, obtain multiple role information of the user based on the user identifier.

[0138] S1003: Obtain the initial permission information of the target user based on the role information.

[0139] S1004. Based on the system function permission list and the authorized function permission list, the initial permission information is filtered to obtain the set of valid permissions for the target user.

[0140] S1005: Obtain the permission logic acquisition method for the data resource to be accessed based on the data identifier of the data resource to be accessed.

[0141] S1006, determine whether each permission in the valid permission set matches the permission logic acquisition.

[0142] S1007 displays the data resources to be accessed.

[0143] S1008, returned permission verification failure message.

[0144] In this embodiment, permission management at the environment, function, and role levels ensures that users can access data within their authorized scope, guaranteeing system security and flexibility. By customizing user permissions at the data dimension level, precise control over user access permissions can be achieved when users request different data resources through the same interface, ensuring users access data resources within their authorized scope, enhancing system security, and protecting data integrity and confidentiality.

[0145] In one exemplary embodiment, such as Figure 11 As shown, the access control method includes the following steps:

[0146] S1101, Upon detecting that a user has logged into the system, a key pair is generated; the key pair includes a public key and a private key; the public key is used to instruct the encryption of key data in the login information to obtain ciphertext information.

[0147] S1102, Receive the encrypted information and key pair identifier sent by the client.

[0148] S1103, Based on the key pair identifier, determine the private key in the key pair.

[0149] S1104, if the encrypted information is successfully decrypted based on the private key, generate a user token based on the target user's login information.

[0150] S1105, if successful decryption of ciphertext information based on the private key is detected, delete the key pair.

[0151] S1106, in response to the target user's resource access request, obtain the target user's user token.

[0152] S1107, retrieve multiple access logics that match both the resource identifier and access type from the preset access logic mapping table; the access logic mapping table includes multiple data resources and multiple access logics corresponding to each data resource.

[0153] S1108, summarize the various access logics corresponding to the data resource to be accessed, and obtain the permission acquisition logic for the data resource to be accessed.

[0154] The permission acquisition logic includes at least one access logic for the data resource to be accessed.

[0155] S1109, parse the user token to obtain the user identifier of the target user.

[0156] S1110, Based on the user identifier, determine at least one role information of the target user.

[0157] S1111, summarize the initial permissions matched with the information of each role to obtain the initial permission set.

[0158] S1112, obtain the list of environment functions for the deployment environment and the list of authorized functions for the system.

[0159] S1113, among the multiple permissions in the initial permission set, delete the permissions that are not in the environment function list and the authorized function list to obtain the role permission set.

[0160] The set of role permissions includes the target user's operation permissions for multiple data resources.

[0161] S1114, if the operation permissions of each data resource in the role permission set satisfy any one of the access logics in the permission acquisition logic, process the resource access request of the target user.

[0162] In this embodiment, the target user's role permission set is determined based on the user token to determine the target user's operation permissions for multiple data resources. Then, the permission acquisition logic of the data resource to be accessed is compared with the role permission set. If the role permission set satisfies any of the access logics of the resource to be accessed, the target user's resource access request is processed. This is equivalent to defining the target user's operation permissions and the operation permissions of the data to be accessed from the data dimension. Through fine-grained comparison at the data dimension, the target user's data operation permissions are precisely controlled to prevent the target user from accessing system data outside the scope of their permissions, thus ensuring the security of system data.

[0163] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0164] Based on the same inventive concept, this application also provides a permission management device for implementing the permission management method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more permission management device embodiments provided below can be found in the limitations of the permission management method described above, and will not be repeated here.

[0165] In one exemplary embodiment, such as Figure 12As shown, a permission management device is provided, including: a request response module 1201, a permission acquisition module 1202, and a request processing module 1203, wherein:

[0166] The request and response module 1201 is used to respond to the resource access request of the target user, obtain the user token of the target user and the permission acquisition logic of the data resource to be accessed; the permission acquisition logic includes at least one access logic of the data resource to be accessed.

[0167] The permission acquisition module 1202 is used to obtain the target user's set of role permissions based on the user token; the set of role permissions includes the target user's operation permissions for multiple data resources;

[0168] The request processing module 1203 is used to process the resource access request of the target user when the role permission set satisfies any of the access logics in the permission acquisition logic.

[0169] In an exemplary embodiment, the request-response module 1201 includes: a token parsing unit and a permission filtering unit, wherein:

[0170] The token parsing unit is used to parse the user token and obtain the initial set of permissions for the target user;

[0171] The permission filtering unit is used to filter the permissions in the initial permission set to obtain the role permission set.

[0172] In an exemplary embodiment, the token resolution unit includes: an identifier acquisition subunit, a role determination subunit, and a permission aggregation subunit, wherein:

[0173] The identifier acquisition subunit is used to parse the user token and obtain the user identifier of the target user;

[0174] The role determination subunit is used to determine at least one role information of the target user based on the user identifier;

[0175] The permission aggregation subunit is used to aggregate the initial permissions that match the information of each role to obtain the initial permission set.

[0176] In an exemplary embodiment, the permission filtering unit includes: a list retrieval subunit and a permission deletion subunit, wherein:

[0177] The list retrieval sub-unit is used to retrieve the list of environment functions for the deployment environment and the list of authorized functions for the system.

[0178] The permission deletion subunit is used to delete permissions that are not in the environment function list and authorized function list from multiple permissions in the initial permission set, thus obtaining the role permission set.

[0179] In an exemplary embodiment, the resource access request carries the resource identifier and access type of the data resource to be accessed. The request response module 1201 includes: a logical acquisition unit and a logical aggregation unit, wherein:

[0180] The logic acquisition unit is used to acquire multiple access logics that match both the resource identifier and the access type from a preset access logic mapping table; the access logic mapping table includes multiple data resources and multiple access logics corresponding to each data resource;

[0181] The logic aggregation unit is used to aggregate multiple access logics that match the resource identifier to obtain the permission acquisition logic for the data resource to be accessed.

[0182] In an exemplary embodiment, the access control device further includes: a ciphertext acquisition module, a private key determination module, and a token generation module, wherein:

[0183] The ciphertext acquisition module is used to receive ciphertext information and key pair identifiers sent by the client;

[0184] The private key determination module is used to determine the private key in a key pair based on the key pair identifier;

[0185] The token generation module is used to generate a user token based on the decrypted data and the target user's login information, provided that the encrypted information has been successfully decrypted using the private key.

[0186] In an exemplary embodiment, the access control device further includes: a key pair generation module and a key pair destruction module, wherein:

[0187] The key pair generation module is used to generate a key pair when a user login is detected. The key pair includes a public key and a private key. The public key is used to instruct the encryption of key data in the login information to obtain ciphertext information.

[0188] The key pair destruction module is used to delete the key pair when successful decryption of ciphertext information based on the private key is detected.

[0189] Each module in the aforementioned access control device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0190] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 13As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores access control data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements an access control method.

[0191] Those skilled in the art will understand that Figure 13 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0192] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0193] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0194] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0195] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0196] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0197] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0198] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for managing access permissions, characterized in that, The method includes: In response to a resource access request from a target user, the system acquires the target user's user token and permission acquisition logic for the data resource to be accessed; the permission acquisition logic includes at least one access logic for the data resource to be accessed. The target user's role and permission set is obtained based on the user token; the role and permission set includes the target user's operation permissions for multiple data resources. If the operation permissions of each data resource in the set of role permissions satisfy any one of the access logics in the permission acquisition logic, then process the resource access request of the target user.

2. The method according to claim 1, characterized in that, The step of obtaining the target user's role permission set based on the user token includes: The user token is parsed to obtain the initial permission set of the target user; The permissions in the initial permission set are filtered to obtain the role permission set.

3. The method according to claim 2, characterized in that, The step of parsing the user token to obtain the initial permission set of the target user includes: The user token is parsed to obtain the user identifier of the target user; Based on the user identifier, at least one role information of the target user is determined; The initial permissions that match the information of each role are aggregated to obtain the initial permission set.

4. The method according to claim 2, characterized in that, The step of filtering permissions in the initial permission set to obtain the role permission set includes: Obtain the environment feature list for the deployment environment and the authorized feature list for the system; In the initial permission set, permissions that are not in the environment function list and the authorized function list are deleted to obtain the role permission set.

5. The method according to any one of claims 1-4, characterized in that, The resource access request carries the resource identifier and access type of the data resource to be accessed; The process of obtaining the permission acquisition logic for the data resource to be accessed includes: Multiple access logics that match both the resource identifier and the access type are obtained from a preset access logic mapping table; the access logic mapping table includes multiple data resources and multiple access logics corresponding to each data resource; By summarizing the various access logics corresponding to the data resource to be accessed, the permission acquisition logic for the data resource to be accessed is obtained.

6. The method according to any one of claims 1-4, characterized in that, The process of generating the user token includes: Receive encrypted information and key pair identifiers sent by the client; Based on the key pair identifier, determine the private key in the key pair; If the encrypted information is successfully decrypted using the private key, the user token is generated based on the decrypted data and the target user's login information.

7. The method according to claim 6, characterized in that, The method further includes: Upon detecting a user login to the system, the key pair is generated; the key pair includes a public key and a private key; the public key is used to instruct the encryption of key data in the login information to obtain the ciphertext information. If the decryption of the ciphertext information based on the private key is successfully detected, the key pair is deleted.

8. A permission management device, characterized in that, The device includes: The request-response module is used to respond to a resource access request from a target user and obtain the target user's user token and permission acquisition logic for the data resource to be accessed; the permission acquisition logic includes at least one access logic for the data resource to be accessed. The permission acquisition module is used to acquire the target user's role permission set based on the user token; the role permission set includes the target user's operation permissions for multiple data resources; The request processing module is used to process the resource access request of the target user when the set of role permissions satisfies any one of the access logics in the permission acquisition logic.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images