Method and device for querying permission data, storage medium and electronic device

Abstract

The application discloses a permission data query method and device, a storage medium and an electronic device, and relates to the technical field of smart homes. The method comprises the following steps: determining a target identifier corresponding to a target object using a permission management system; determining one or more role identifiers from a pre-defined first relationship set based on the target identifier, and determining one or more resource identifiers from a pre-defined second relationship set and the pre-defined first relationship set based on the target identifier; in the case that it is determined that a management object has entered a query condition in the permission management system, inputting the role identifier, the resource identifier and the query condition into a pre-configured permission model in the permission management system to obtain a permission rule of the target object, and analyzing the permission rule to determine a query result of permission data corresponding to the target object, thereby solving the problem of querying permission data in addition to authorization requests.

Description

Technical Field

[0001] This application relates to the field of smart home technology, and more specifically, to a method and apparatus for querying access data, a storage medium, and an electronic device. Background Technology

[0002] Traditional access control methods include role-based access control (RBAC) and attribute-based access control (ABAC). RBAC is widely used and simple to implement, but its functionality is relatively limited, only allowing configuration at the role level. Attribute-based access control allows for flexible configuration of permission rules based on attributes, but its implementation is more complex. While most applications can meet their permission requirements using role-based methods, some applications require attribute-based or more complex permission models. Application systems typically customize their permission management solutions according to their specific needs, resulting in a coupling between permissions and application requirements.

[0003] In related technologies, a separate permission management module can be used to decouple permissions from application business logic, thereby reducing the development cost of third-party applications. However, this requires the permission module to be relatively independent and universal, capable of supporting multiple permission schemes. Existing open-source general-purpose permission management systems implement RBAC and ABAC separately, such as Keycloak. Additionally, some customized permission management systems integrate attribute-based filtering on top of RBAC, such as Amazon AWS IAM, which supports filtering by role and resource tags; and Alibaba Cloud Service Resource Permission Control RAM, which supports simple service resource condition filtering. However, their use of attribute-based filtering is not universal enough; only the former supports combined filtering by role tags and resource tags, and cannot be used as a general-purpose permission management system.

[0004] No effective solution has yet been proposed to address the issue that related technologies cannot meet the query needs for permission data other than authorization requests. Summary of the Invention

[0005] This application provides a method and apparatus for querying permission data, a storage medium, and an electronic device to at least solve the problems in related technologies that cannot meet the query needs for permission data other than authorization requests.

[0006] According to one embodiment of this application, a method for querying permission data is provided, comprising: determining a target identifier corresponding to a target object using a permission management system, wherein the target identifier is a unique identifier of the target object through authentication by the permission management system; determining one or more role identifiers from a predefined first relation set based on the target identifier, and determining one or more resource identifiers from a predefined second relation set and a predefined first relation set based on the target identifier; and, if it is determined that the managed object has entered query conditions in the permission management system, inputting the role identifier, the resource identifier, and the query conditions into a pre-configured permission model in the permission management system to obtain the permission rules of the target object, and parsing the permission rules to determine the query results of the permission data corresponding to the target object.

[0007] In an exemplary embodiment, parsing the permission rules to determine the query results for permission data corresponding to the target object includes: parsing the permission rules to determine the target permission data corresponding to the target object; wherein the permission rules are used to indicate rules that allow or deny the target object to perform operations on resources; identifying the restrictions in the target permission data, wherein the restrictions include at least: allowing or denying object extended attributes corresponding to the target object and resource extended attributes corresponding to the resource; and using the search engine of the permission management system to query the cache database and storage database of the permission management system based on the restrictions to obtain the query results for the permission data corresponding to the target object.

[0008] In an exemplary embodiment, the search engine of the access control system performs queries based on restrictions in the cache database and storage database of the access control system to obtain corresponding query results, including: determining the first content corresponding to the object extended attribute and determining the second content corresponding to the resource extended attribute; obtaining the attribute conditions corresponding to the access control system; and, if the restrictions satisfy the query criteria of the attribute conditions, determining the query results corresponding to the restrictions based on the first content, the second content, and the attribute conditions.

[0009] In an exemplary embodiment, before parsing the permission rules to determine the query results of the permission data corresponding to the target object, the method further includes: obtaining a query instruction input by the target object, wherein the query instruction is used to indicate the data type of the query result to be obtained by the target object, and the query instruction includes at least one of the following: an authorization query instruction of the target object, a resource data query instruction of the target object, and an object data query instruction of the target object; determining the preset permission rule features of the query instruction, and performing recognition processing on the permission rules based on the preset permission rule features to obtain the target permission rule corresponding to the query instruction.

[0010] In an exemplary embodiment, determining the preset permission rule features of a query instruction and performing identification processing on the permission rules based on the preset permission rule features to obtain the target permission rule corresponding to the query instruction includes: when the query instruction is an authorization query instruction, determining that the data type corresponding to the target permission rule is a first rule, wherein the first rule is used to determine whether the target object has the permission to operate resources; when the query instruction is a resource data query instruction, determining that the data type corresponding to the target permission rule is a second rule, wherein the second rule is used to determine the resources that the target object has permission to access; and when the query instruction is an object data query instruction, determining a list of target objects for which resources under the current permission management system need to be obtained.

[0011] In an exemplary embodiment, when the query instruction is an authorization query instruction, determining the data type corresponding to the target permission rule as a first rule includes: obtaining the target identifier corresponding to the target object, a set of resource identifiers to be confirmed, and an operation type to be executed; determining the set of role identifiers corresponding to the target identifier from the cache database, and determining the resource extended attributes corresponding to each resource identifier in the set of resource identifiers to be confirmed and the resource corresponding to the set of resource identifiers; and determining the first rule based on the set of role identifiers, the resource extended attributes, the resource, and the operation type.

[0012] In an exemplary embodiment, when the query instruction is a resource data query instruction, determining that the data type corresponding to the target permission rule is a second rule includes: obtaining the target identifier corresponding to the target object and the resource type to be confirmed; determining the extended attribute value corresponding to the target identifier from the cache database; determining the corresponding rule filtering conditions based on the extended attribute value and the resource type; querying the target object using the rule filtering conditions and the permission rule of the target object to obtain the second rule.

[0013] In an exemplary embodiment, when the query instruction is an object data query instruction, the method further includes determining a list of target objects for which resources under the current permission management system need to be obtained. This involves: obtaining a set of role identifiers to be confirmed and a set of resource identifiers to be confirmed input by the target object; determining, in a storage database, a set of objects matching the role identifiers in the set of role identifiers to be confirmed, and determining the resource extended attributes corresponding to each resource identifier in the set of resource identifiers to be confirmed. The resource extended attributes include: the extended attribute value of the resource and the resource path corresponding to the resource; and determining a list of target objects with permissions to subordinate resources in the permission management system based on the multiple resource extended attributes corresponding to the object set and the set of resource identifiers to be confirmed.

[0014] In an exemplary embodiment, determining a list of target objects with subordinate resource permissions in the permission management system based on multiple resource extended attributes corresponding to the object set and the resource identifier set to be confirmed includes: determining permission rules that match objects in the object set in the rule records of the permission management system; converting the restrictions in the permission rules into a first query statement according to preset syntax rules, and adding the multiple resource extended attributes to the query statement to obtain a second query statement; and using the second query statement to perform matching in the storage database of the permission management system to obtain a list of target objects with subordinate resource permissions.

[0015] According to another embodiment of this application, a permission data query device is also provided, comprising: a first determining module, configured to determine a target identifier corresponding to a target object using a permission management system, wherein the target identifier is a unique identifier of the target object through authentication by the permission management system; a second determining module, configured to determine one or more role identifiers from a predefined first relation set based on the target identifier, and to determine one or more resource identifiers from a predefined second relation set and a predefined first relation set based on the target identifier; and a permission module, configured to, when it is determined that the managed object has entered query conditions in the permission management system, input the role identifier, the resource identifier, and the query conditions into a pre-configured permission model in the permission management system to obtain the permission rules of the target object, and parse the permission rules to determine the query results of the permission data corresponding to the target object.

[0016] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is configured to execute the above-mentioned permission data query method when running.

[0017] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the above-mentioned permission data query method through the computer program.

[0018] In this embodiment, a target identifier corresponding to the target object using the access control system is determined, wherein the target identifier is a unique identifier of the target object through the authentication of the access control system; one or more role identifiers are determined from a predefined first relation set based on the target identifier, and one or more resource identifiers are determined from a predefined second relation set and a predefined first relation set based on the target identifier; when it is determined that the managed object has entered query conditions in the access control system, the role identifier, the resource identifier, and the query conditions are input into a pre-configured access control model in the access control system to obtain the access control rules of the target object, and the access control rules are parsed to determine the query results of the access control data corresponding to the target object; by adopting the above technical solution, the problems in related technologies, such as the inability to meet the query needs of access control data other than authorization requests, are solved, and the technical effect of compatibility with multiple access control models and efficient and fast query of corresponding access control data is achieved. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the hardware environment for a method of querying permission data according to an embodiment of this application;

[0022] Figure 2 This is a flowchart of a method for querying permission data according to an embodiment of this application;

[0023] Figure 3 This is a system schematic diagram of an optional permission model according to an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of the structure of a management system corresponding to an optional permission model according to an embodiment of this application;

[0025] Figure 5 This is a flowchart illustrating an optional authorization query process for a management system according to an embodiment of this application;

[0026] Figure 6This is a flowchart illustrating an optional resource data query process for a management system according to an embodiment of this application;

[0027] Figure 7 This is a flowchart illustrating an optional user data query process for a management system according to an embodiment of this application.

[0028] Figure 8 This is a flowchart illustrating an optional If-else conditional statement conversion method according to an embodiment of this application;

[0029] Figure 9 This is a structural block diagram of an optional permission data query device according to an embodiment of this application. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] Existing permission management systems typically only satisfy authorization requests, i.e., querying whether a user (authorizing subject) has a certain type of permission for a resource (authorizing object). Besides authorization requests, application systems often have permission data query requirements, i.e., querying a user's (equivalent to the target object) permission for a type of resource they have permission for; or, querying a user with a specific role's permission for a resource. Whether the permission model is role-based or attribute-based, it targets authorization requests. No implementation solution is provided for the aforementioned customized permission data query function, and permission systems typically do not implement this function or cannot implement it efficiently. Furthermore, third-party application systems may require complex permission rules for attribute constraints. This could involve combining attribute constraints using AND, OR, NOT, or other logical combinations, or defining conditional expressions such as "when attribute 1 meets a certain condition, attribute 2 must also meet a certain condition." Existing permission systems only provide simple conditional syntax such as "size" and "equality comparisons," and the logical relationships between multiple conditions only support "AND," without supporting nesting. Therefore, they cannot express the aforementioned complex permission rules.

[0033] According to one aspect of the embodiments of this application, a method for querying permission data is provided. This method for querying permission data is widely applicable to whole-house intelligent digital control application scenarios such as smart homes, smart home ecosystems, and intelligence house ecosystems. Optionally, in this embodiment, the above-mentioned method for querying permission data can be applied to, for example... Figure 1 The hardware environment shown consists of terminal device 102, server 104, and camera device 106. For example... Figure 1 As shown, server 104 is connected to terminal device 102 via a network and can be used to provide services (such as application services) to the terminal or clients installed on the terminal. A database can be set up on the server or independently of the server to provide data storage services for server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data processing services for server 104.

[0034] The aforementioned network may include, but is not limited to, at least one of the following: wired network, wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network, metropolitan area network, local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity), Bluetooth. The terminal device 102 may not be limited to PC, mobile phone, tablet computer, smart air conditioner, smart range hood, smart refrigerator, smart oven, smart stove, smart washing machine, smart water heater, smart washing equipment, smart dishwasher, smart projector, smart TV, smart clothes rack, smart curtains, smart audio-visual equipment, smart socket, smart speaker, smart speaker box, smart fresh air equipment, smart kitchen and bathroom equipment, smart bathroom equipment, smart robot vacuum cleaner, smart window cleaning robot, smart mopping robot, smart air purifier, smart steam oven, smart microwave oven, smart water heater, smart air purifier, smart water dispenser, smart door lock, etc.

[0035] This embodiment provides a method for querying permission data, applied to the aforementioned camera device. Figure 2 This is a flowchart of an optional method for querying permission data according to an embodiment of this application. The process includes the following steps:

[0036] Step S202: Determine the target identifier corresponding to the target object using the access control system, wherein the target identifier is a unique identifier of the target object through the authentication of the access control system;

[0037] Step S204: Determine one or more role identifiers from a predefined first relationship set based on the target identifier, and determine one or more resource identifiers from a predefined second relationship set and a predefined first relationship set based on the target identifier;

[0038] Step S206: If it is determined that the management object has entered the query conditions in the permission management system, the role identifier, the resource identifier and the query conditions are input into the permission model pre-configured in the permission management system to obtain the permission rules of the target object, and the permission rules are parsed to determine the query results of the permission data corresponding to the target object.

[0039] It should be noted that the above query conditions can be attribute conditions, operation types, resource types, etc.

[0040] Optionally, the above permission rules include three parts: 1. The relationship between users and roles. 2. The relationship between roles and permissions. 3. Permissions, which may include resource paths, resource extended attribute conditions, user extended attribute conditions, allowed operations, etc., which are not subject to further restrictions in this application.

[0041] Optionally, the above permission model may include multiple sets of permission rule data, wherein a set of permission rule data includes: roles corresponding to one or more role identifiers, resources corresponding to one or more resource identifiers associated with the roles, and a set of restrictions involving target object attributes and resource attributes.

[0042] Through the above steps, the target identifier corresponding to the target object using the access control system is determined, wherein the target identifier is a unique identifier of the target object through the authentication of the access control system. Based on the target identifier, one or more role identifiers are determined from a predefined first relation set, and one or more resource identifiers are determined from a predefined second relation set and a predefined first relation set. If it is determined that the managed object has entered query conditions in the access control system, the role identifier, the resource identifier, and the query conditions are input into the pre-configured access control model in the access control system to obtain the access control rules for the target object. The access control rules are parsed to determine the query results of the access control data corresponding to the target object. That is, by confirming the target identifier of the target object using the access control system, the role identifier and resource identifier corresponding to the target object are determined, and the corresponding access control rules are obtained through the access control model. The access control rules are parsed to obtain the access control data that the target object needs to query. This technical solution solves the problem in related technologies that cannot meet the query needs for access control data other than authorization requests, achieves compatibility with multiple access control models, and enables efficient and rapid querying of corresponding access control data.

[0043] Optionally, the above permission model can consist of multiple elements. Figure 3 This is a schematic diagram of an optional permission model according to an embodiment of this application, including:

[0044] User (equivalent to the target object in this embodiment of the invention): that is, the user of the permission management system, and the subject granting permissions. After authentication, the user obtains a unique user ID within the system, which is subsequently used for permission binding.

[0045] User extended attributes: These are user attributes in ABAC, in key-value pair format; the attribute value includes the attribute type. System administrators can set user extended attributes, which can be used as restrictions in permission rules.

[0046] Resources: The objects to which permissions are granted, defined by the tenant administrator. This system is a multi-tenant system; each tenant can correspond to a group of third-party applications, and resource identifiers within the same tenant cannot be duplicated. In addition to the resource identifier, a resource includes the following attributes:

[0047] Resource Type: Defined by the tenant administrator, it can include: Parent Resource ID: The ID of the parent resource, indicating the resource hierarchy. By specifying the parent resource ID to construct a resource tree, unified authorization can be applied to a subtree of the resource tree. Resource Path: The cascading ID from the root node to the resource. For example, if the root node resource ID is "x"; the root node has a parent node resource with the resource ID "y"; and the parent node has a leaf node resource with the resource ID "z", then the resource path of the leaf node is "xyz".

[0048] Extended resource attributes: These are resource attributes in ABAC, in key-value pair format, with the attribute value including the attribute type. Tenant administrators can set extended resource attributes, which can be used as filtering conditions in permission rules.

[0049] Roles: These are the roles in the RBAC model. By defining roles, roles are associated with users and permissions, thus decoupling users and resources. Roles are defined by the tenant administrator, and each role has a unique role ID; role IDs cannot be duplicated under the same tenant.

[0050] Permission policy: A collection of permission rules that can be associated with roles.

[0051] Permission Rules: These are the specific descriptions of permissions, including the following elements: Resource Path: A list of resource paths to which this permission rule applies. A ".*" suffix can be used to identify a specific resource subtree, "*" to identify all resources, or "resource ID" to specify a particular resource. Permission rules indirectly associate resources through the description of resource paths. Operation: The name of the operation defined by the tenant, such as "Get," "Update," or "Delete." Authorization requests can obtain permissions for specific operations by specifying the operation name. Judgment: "Allow" or "Deny," indicating the effect of the permission rule. Attribute Conditions: A list of attribute restrictions. Each attribute restriction is a triple consisting of an attribute, a relational operator, and a value. Multiple attribute conditions can be combined using logical operators such as and, or, if, and not, and recursive nesting is supported.

[0052] User group: A collection of users. Tenant administrators can define a collection of users as a user group and associate user groups with roles.

[0053] Organization: This refers to the company's organizational structure, with each user associated with an organization. Organizations can be linked to roles, making it easy to authorize permissions within an organization.

[0054] It should be noted that attributes and values ​​can be user-extended attribute names, resource-extended attribute names, or constants, and can take the following three forms:

[0055] 1. "user.attribute_name + constant": This represents the constant constraint condition for user extended attributes. In implementation, the corresponding value needs to be obtained based on the user extended attribute name and compared with the constant.

[0056] 2. "res.property_name + constant": This represents the constant constraints of the resource extended property. In implementation, the corresponding value needs to be obtained based on the resource extended property name and compared with the constant.

[0057] 3. "user.attribute_name + res.attribute_name": This represents the combined constraint condition of user extended attributes and resource extended attributes. In implementation, the corresponding values ​​need to be obtained separately for each extended attribute name and resource extended attribute name, and then compared. The above is merely one feasible example, and this application does not impose any limitations on it.

[0058] In an exemplary embodiment, parsing the permission rules to determine the query results for permission data corresponding to the target object includes: parsing the permission rules to determine the target permission data corresponding to the target object; wherein the permission rules are used to indicate rules that allow or deny the target object to perform operations on resources; identifying the restrictions in the target permission data, wherein the restrictions include at least: allowing or denying object extended attributes corresponding to the target object and resource extended attributes corresponding to the resource; and using the search engine of the permission management system to query the cache database and storage database of the permission management system based on the restrictions to obtain the query results for the permission data corresponding to the target object.

[0059] In simple terms, after obtaining the permission rules for the current target object through the permission model, it is necessary to configure the query results for the target object according to the permission rules. By determining the restrictions in the permission rules and searching for the data corresponding to the restrictions in the cache database and storage database of the permission management system, the query results of the permission data corresponding to the target object are finally obtained.

[0060] In an exemplary embodiment, the search engine of the access control system performs queries based on restrictions in the cache database and storage database of the access control system to obtain corresponding query results, including: determining the first content corresponding to the object extended attribute and determining the second content corresponding to the resource extended attribute; obtaining the attribute conditions corresponding to the access control system; and, if the restrictions satisfy the query criteria of the attribute conditions, determining the query results corresponding to the restrictions based on the first content, the second content, and the attribute conditions.

[0061] Optionally, since search engines support full-text indexing and recursive combined search conditions, queries can be performed on object extended attributes, resources, and resource extended attributes corresponding to the restrictions. This allows for rapid data retrieval primarily through search engines when querying data in the access control system. For example, resources can be retrieved based on the resource path or attribute condition (equivalent to the second point mentioned above) in the resource extended attribute of the target object in the access control rule. By segmenting and indexing the resource path field, precise results can be obtained. Optionally, the aforementioned attribute conditions can include various binary relation conditions and nested logical relation conditions such as AND, OR, and NOT. The introduction of these conditions makes the access control rules more flexible and expressive, resulting in more precise query results for access control data corresponding to the target object.

[0062] In an exemplary embodiment, before parsing the permission rules to determine the query results of the permission data corresponding to the target object, the method further includes: obtaining a query instruction input by the target object, wherein the query instruction is used to indicate the data type of the query result to be obtained by the target object, and the query instruction includes at least one of the following: an authorization query instruction of the target object, a resource data query instruction of the target object, and an object data query instruction of the target object; determining the preset permission rule features of the query instruction, and performing recognition processing on the permission rules based on the preset permission rule features to obtain the target permission rule corresponding to the query instruction.

[0063] In an exemplary embodiment, determining the preset permission rule features of a query instruction and performing identification processing on the permission rules based on the preset permission rule features to obtain the target permission rule corresponding to the query instruction includes: when the query instruction is an authorization query instruction, determining that the data type corresponding to the target permission rule is a first rule, wherein the first rule is used to determine whether the target object has the permission to operate resources; when the query instruction is a resource data query instruction, determining that the data type corresponding to the target permission rule is a second rule, wherein the second rule is used to determine the resources that the target object has permission to access; and when the query instruction is an object data query instruction, determining a list of target objects for which resources under the current permission management system need to be obtained.

[0064] In an exemplary embodiment, when the query instruction is an authorization query instruction, determining the data type corresponding to the target permission rule as a first rule includes: obtaining the target identifier corresponding to the target object, a set of resource identifiers to be confirmed, and an operation type to be executed; determining the set of role identifiers corresponding to the target identifier from the cache database, and determining the resource extended attributes corresponding to each resource identifier in the set of resource identifiers to be confirmed and the resource corresponding to the set of resource identifiers; and determining the first rule based on the set of role identifiers, the resource extended attributes, the resource, and the operation type.

[0065] In an exemplary embodiment, when the query instruction is a resource data query instruction, determining that the data type corresponding to the target permission rule is a second rule includes: obtaining the target identifier corresponding to the target object and the resource type to be confirmed; determining the extended attribute value corresponding to the target identifier from the cache database; determining the corresponding rule filtering conditions based on the extended attribute value and the resource type; querying the target object using the rule filtering conditions and the permission rule of the target object to obtain the second rule.

[0066] In an exemplary embodiment, when the query instruction is an object data query instruction, the method further includes determining a list of target objects for which resources under the current permission management system need to be obtained. This involves: obtaining a set of role identifiers to be confirmed and a set of resource identifiers to be confirmed input by the target object; determining, in a storage database, a set of objects matching the role identifiers in the set of role identifiers to be confirmed, and determining the resource extended attributes corresponding to each resource identifier in the set of resource identifiers to be confirmed. The resource extended attributes include: the extended attribute value of the resource and the resource path corresponding to the resource; and determining a list of target objects with permissions to subordinate resources in the permission management system based on the multiple resource extended attributes corresponding to the object set and the set of resource identifiers to be confirmed.

[0067] For example, permission rules that are deemed permissible can be selected and converted into search engine queries for users (equivalent to the first query statement) based on resource extension attributes. The basic conversion rules are as follows: For attribute restrictions in the form of "user.attribute_name + constant", they are converted into equivalent search engine queries for a specific user extension attribute according to attribute condition syntax rules; for attribute restrictions in the form of "user.attribute + res.attribute", since the resource extension attribute is known, it can be considered a constant, or it can be converted into an equivalent search engine query statement for a specific user extension attribute. For the overall permission rules, the search engine queries converted from each attribute restriction are merged and combined according to the syntax rule parsing algorithm to obtain a composite search engine query statement. Specifically, the list of matching user IDs (equivalent to the target identifier in this embodiment) obtained based on role identifiers, the obtained search engine query statements, and the user extension attribute key-value pairs (optional) specified in the parameters are merged into a composite search engine query statement (equivalent to the second query statement). The composite search engine query statement is used to query the cache database and storage database of the permission management system and return the user IDs that meet the conditions.

[0068] In an exemplary embodiment, determining a list of target objects with subordinate resource permissions in the permission management system based on multiple resource extended attributes corresponding to the object set and the resource identifier set to be confirmed includes: determining permission rules that match objects in the object set in the rule records of the permission management system; converting the restrictions in the permission rules into a first query statement according to preset syntax rules, and adding the multiple resource extended attributes to the query statement to obtain a second query statement; and using the second query statement to perform matching in the storage database of the permission management system to obtain a list of target objects with subordinate resource permissions.

[0069] In short, to improve the system's applicability and efficiency, the access control system can also implement multi-functional query functions based on the query commands input by the target object. As an optional implementation method, it can be one of the following three processes:

[0070] Method 1: Authorization query process (i.e., querying whether a user has permission to perform a certain operation on a resource based on the user ID (equivalent to the target identifier) ​​and resource ID (equivalent to the resource identifier). By determining the target identifier and resource identifier of the target object, and combining the operation type, the resource path, user extended attributes, and resource extended attributes obtained based on the permission rules, and using the attribute conditional syntax rule parsing algorithm to determine the permission rules, filtering out the valid permission rules, and then combining the denial priority strategy, the determination results (allow or deny) of multiple valid permission rules are merged to obtain the final determination result.

[0071] Method 2: Resource data query process (i.e., based on the user querying a certain type of resource they have permission to access), by determining the target identifier of the target object, and also combining it with the operation type, the target permission rules used to determine whether the target object has permission to access the resource are obtained from the permission rules. The permission rules are converted into resource query statements according to the extended attribute conversion syntax, and finally the resource data that the target object has permission to access is retrieved based on the resource query statements.

[0072] Method 3: Target object data query process (i.e., querying users with certain roles who have permissions based on resources). By determining the role identifier and resource identifier, and combining operation and user extended attribute key-value pairs, a comprehensive query statement is generated through deduplication and judgment. This query statement is used to query the user extended attributes and return the user IDs that meet the conditions.

[0073] To better understand the process of querying the above-mentioned permission data, the implementation flow of the above-mentioned permission data query method will be described below in conjunction with optional embodiments, but it is not intended to limit the technical solution of the embodiments of this application.

[0074] In related technologies, the RBAC permission model is used for permission management, and these models have been extended to some extent. For example, Amazon Web Services (IAM) supports ABAC-style tag filtering, allowing users to specify role and resource tags as filtering conditions in permission rules; Alibaba Cloud Access Control (RAM) supports specifying resource filtering conditions or built-in global filtering conditions in permission rules to filter permissions. Besides customizing permissions within application systems, permissions can also be extracted and used as independent general-purpose permission services. However, while the filtering conditions implemented by Amazon IAM and Alibaba Cloud RAM based on RBAC reflect the ABAC concept to some extent, they do not fully support ABAC. Amazon IAM supports role and resource tags, but users do not have tags; Alibaba Cloud RAM only supports filtering built-in resource attributes and does not support custom attributes or user attributes. Therefore, they cannot be directly exposed as independent general-purpose permission management systems to third-party application systems. Furthermore, the open-source general-purpose permission management system Keycloak supports both RBAC and ABAC permission rules, and can restrict resource attributes via JavaScript, but it does not support user attributes. The RBAC and ABAC permission rules are implemented separately and independently, not integrated into a single model. This introduces functional limitations and affects the versatility of the permission management system. In practice, third-party application systems, besides authorization requirements (i.e., determining whether a user has a certain permission based on the user and resource), may also need to query resources or users with permissions. For example, an application menu page might directly query "What menu resources does the user have permission to access?" through the permission management system; a sales management application might query "Who is the sales manager corresponding to a certain store?". However, general permission management systems in related technologies cannot efficiently support such permission data queries. Corresponding standard permission models do not define implementation schemes for permission data queries; neither RBAC nor ABAC does. Existing permission systems do not support such queries; Alibaba Cloud RAM, Amazon IAM, and Keycloak all do not support them. Keycloak supports multiple independent permission rules because it directly binds permission rules to resources. However, it requires traversing all resources and individually determining the permission rules bound to each resource.

[0075] For ABAC, the ability of permission rules to support complex permission logic configurations depends on the strength of the syntax rules of the attribute condition expressions. Keycloak's ABAC supports the use of JavaScript, follows JavaScript syntax rules, has strong descriptive capabilities, and can support various complex permission configurations, but it requires parsing JavaScript, resulting in poor performance. Alibaba Cloud RAM and Amazon Cloud IAM use custom Domain Specific Languages ​​(DSLs) for attribute conditions, supporting binary logical expressions like StringEquals, but the relationships between different conditions are logical AND relationships, and they do not support the combination and nesting of logical relationships, thus limiting their descriptive capabilities.

[0076] To address the aforementioned shortcomings, this invention proposes a universal permission management system that supports multiple permission models in optional embodiments. This system defines a unified, efficient permission model that meets various permission requirements by considering authorization requests and permission data query needs, and integrating commonly used permission schemes. It can adapt to the diverse permission requirements of third-party application systems. Furthermore, by supporting permission rule syntax and parsing that includes nested if, and, or logical expression constraints, the universal permission management system simultaneously ensures efficient querying of authorized resources and authorized subjects.

[0077] Optional, Figure 3 This is a system schematic diagram of an optional permission model according to an embodiment of this application. The permission model combines RBAC and ABAC and has the following advantages:

[0078] 1. Based on RBAC design, it supports most permission usage scenarios. For third-party application systems that only need to use RBAC, it is only necessary to define roles, specify resource paths in permission rules, set attribute conditions to empty, and then associate users, roles, and permission policies.

[0079] 2. Seamlessly supports ABAC and complex permission configurations. For third-party application systems that only need to use ABAC, restrictions on user extended attributes and resource extended attributes can be specified in the permission rules, and the resource path can be set to "*", associated with a general role, and then batch associated with users (users, user groups, or organizations) according to the role.

[0080] 3. Supports batch authorization of resource sets in a tree structure. For third-party application systems where resources have hierarchical relationships, by defining resources as a tree and configuring permissions for sub-tree nodes, all child nodes can be affected, thereby simplifying the complexity of permission configuration, reducing the amount of configuration data, and lowering the implementation cost of the permission system.

[0081] As an optional implementation, after constructing the above-mentioned permission model, a corresponding permission query service process can be set up. Figure 4 This is a schematic diagram of the structure of a management system corresponding to an optional permission model according to an embodiment of this application, including the following components:

[0082] Permission query service 42: Implements a stateless service for the permission model described in this invention, and supports multi-process deployment.

[0083] KV storage 44 (equivalent to the cache database in this embodiment of the invention): a key-value storage system, including but not limited to Redis, which caches user permission rules to improve system response speed.

[0084] The relational database 46 (equivalent to the storage database in this embodiment of the invention), including but not limited to MySQL, stores basic information such as users, roles and permission rules, but does not store user extended attributes and resources and their extended attributes, and mainly provides the function of querying permission rules.

[0085] Search Engine 48: Used to support full-text indexing and recursive combined search conditions, including but not limited to Elasticsearch, for storing user extended attributes, resources, and resource extended attributes. The reason for storing extended attributes in a search engine instead of a traditional relational database is mainly due to the following two considerations regarding query performance: (1) Finding the corresponding resource based on the resource path in the permission rules. The resource path may contain the form ".*" to wildcard the resource subtree, such as "xy*". For the above situation, relational databases can use SQL statements such as like and or, but the query performance is poor. Using a search engine, by segmenting and indexing the resource path field, the results can be obtained through precise retrieval. In the example above, a simple search for "y" can obtain all resources in the subtree. (2) Retrieving resources based on attribute conditions. As indicated in the permission model above, attribute conditions can contain various binary relation conditions and nested logical relation conditions such as and, or, not. Compared with traditional relational databases, search engines support more powerful search functions, and the performance of the above queries is better.

[0086] As an optional implementation, the access control system can provide a variety of query functions, such as authorization query, resource data query, and user data query.

[0087] Optional, Figure 5 This is a flowchart illustrating an optional authorization query process for a management system according to an embodiment of this application, such as... Figure 5 As shown:

[0088] Input the following into the management system: User ID, Resource ID, Operation Type (optional). Output: Whether the user has permission for the resource. The main purpose of the authorization query process is to query whether a user has permission for a certain operation on a resource based on the User ID and Resource ID. This is the most basic function of the permission system (authorization, abbreviated as Authz). The specific process is as follows:

[0089] S1: Query the user's associated roles and permission rules in MySQL based on the user ID, and then remove duplicates.

[0090] S2: Check if the attribute conditions of the permission rule contain user extended attributes in the form of "user.[attribute name]". If so, proceed to S3; otherwise, proceed to S4.

[0091] S3: Query the extended attribute values ​​of a user in the Elasticsearch search engine based on the user's extended attribute name.

[0092] S4: Check if the attribute conditions of the permission rule contain resource extended attributes in the form of "res.[attribute name]". If so, proceed to S5; otherwise, proceed to S6.

[0093] S5: Query the resource's extended attribute value and resource path in the Elasticsearch search engine based on the resource ID and extended attribute name. Proceed to S7.

[0094] S6: Query the resource path in the Elasticsearch search engine based on the resource ID.

[0095] S7: Based on the resource path, user extended attributes, and resource extended attributes obtained in the above steps, use the attribute conditional syntax rule parsing algorithm to determine the permission rules and filter out the valid permission rules.

[0096] S8: Based on the denial-first policy, merge the judgment results (allow or deny) of multiple valid permission rules to obtain the final judgment result.

[0097] Optional, Figure 6 This is a flowchart illustrating an optional resource data query process for a management system according to an embodiment of this application, as shown below. Figure 6 As shown:

[0098] In the management system, input: User ID, Resource Type (optional); Output: Resources that the user has permission to access; The main purpose of the resource data query process is to query a user's authorized resource type, which falls under the permission data query function. The specific process is as follows:

[0099] S1: Query the user's associated roles and permission rules in MySQL based on the user ID, and then remove duplicates.

[0100] S2: Filter the permission rules and retain the permission rules that are judged as "allow".

[0101] S3: Query extended attribute values ​​of a user in Elasticsearch based on the user ID.

[0102] S4: Filter permission rules based on user extended attribute values ​​and resource types. The basic filtering rules are as follows: For user attribute restrictions in the form of "user.attribute name + constant", evaluate them based on the user extended attribute value. If the expression is no longer true, it needs to be filtered. For resource attribute restrictions in the form of "res.type + constant" (where type represents the resource type attribute), evaluate them based on the specified resource attribute (if specified). If the expression is no longer true, it needs to be filtered. When an attribute expression is no longer true, the entire permission rule is filtered according to the syntax rule parsing algorithm.

[0103] S5: Convert the filtered permission rules into Elasticsearch queries targeting resources. The basic conversion rules are as follows: For resource attribute restrictions in the form of "res.attribute_name + constant", convert them into equivalent Elasticsearch queries targeting a specific resource attribute according to the attribute condition syntax rules; for combined attribute restrictions in the form of "res.attribute_name + user.attribute_name", since the user attribute value is known, it can be considered a constant and can also be converted into equivalent Elasticsearch queries targeting a specific resource attribute. For the overall permission rules, merge and combine the Elasticsearch statements converted from each attribute restriction according to the syntax rule parsing algorithm to obtain a composite Elasticsearch query.

[0104] S6: Perform a query based on the Elasticsearch query statement converted from the permission rules to obtain resources that meet the conditions.

[0105] S7: If S1 contains permission rules that are determined to be "deny", then each resource obtained in step S6 needs to be determined by authz according to the "authorization query process" to obtain the final resources that meet the conditions.

[0106] Optional, Figure 7 This is a flowchart illustrating an optional user data query process for a management system according to an embodiment of this application, as shown below. Figure 7 As shown:

[0107] In the management system, input the resource ID, role ID, operation (optional), and user extended attribute key-value pairs (optional). Output: User IDs that meet the requirements and have the necessary permissions. The main purpose of the user data query process is to query users with specific roles who have permissions based on the resource; this falls under the permission data query function. The specific process is as follows:

[0108] S1: Based on the role ID, query the permission rules associated with the role in MySQL and remove duplicates.

[0109] S2: Based on the resource ID and the extended attribute name used in the permission rules, query the extended attribute value and resource path of the resource in the Elasticsearch search engine.

[0110] S3: Determine the permission rules based on the resource path, permission rules, and resource extended attributes. This process is similar to authz's S7 step, but ignores restrictions including user extended attributes. If the determination fails, return null.

[0111] S4: Based on the role ID, query the list of user IDs associated with that role in MySQL.

[0112] S5: Select the permission rules in S1 that are judged as "allow," and convert them into Elasticsearch search engine queries for the user based on the resource extended attributes. The basic conversion rules are as follows: For attribute restrictions in the form of "user.attribute_name + constant," convert them into equivalent Elasticsearch search engine queries for a specific user extended attribute according to the attribute condition syntax rules; for attribute restrictions in the form of "user.attribute + res.attribute," since the resource extended attribute is known, it can be considered a constant and can also be converted into equivalent Elasticsearch search engine queries for a specific user extended attribute.

[0113] For the overall permission rules, the Elasticsearch search engine statements converted from each attribute restriction condition are merged and combined according to the syntax rule parsing algorithm to obtain a composite Elasticsearch search engine query statement. This process is similar to step S5 of the "Resource Data Query Process".

[0114] S6: Combine the list of user IDs obtained in S4, the Elasticsearch search engine query obtained in S5, and the user extended attribute key-value pairs (optional) specified in the parameters into a single composite Elasticsearch query.

[0115] S7: Use the query statements from S6 in the Elasticsearch search engine to query user extended attributes and return the user IDs that meet the conditions.

[0116] S8: Optional, if there is a permission rule in S1 that is determined to be "deny", then the user IDs returned in S7 need to be determined by authz according to the "authorization query process" in turn, and the user IDs that are determined to be "deny" in the whole should be filtered out and returned.

[0117] It's important to note that the key to the implementation process of the three query services described above lies in the parsing of attribute conditional syntax rules: The authorization query process relies on attribute conditional syntax rules to determine permission rules. The resource data query process relies on attribute conditional syntax rules to determine permission rules, ignoring resource extended attributes, and generates Elasticsearch query statements for the resource and its extended attributes. The user data query process relies on attribute conditional syntax rules to pre-determine permission rules, ignoring user extended attributes, and generates Elasticsearch query statements for user extended attributes. Therefore, after determining the management system and building the permission model, it is also necessary to configure the syntax rules of the permission management system.

[0118] Optionally, attribute constraints are an important component of permission rules, enabling the permission management system to support the ABAC model. To support complex permission rule descriptions, this optional embodiment of the invention also designs a set of attribute constraint syntax rules, characterized by: supporting lists containing multiple value relational expressions, supporting the use of `and` and `or` to combine conditions and multi-level nesting, and supporting `if` condition semantics. Attribute Condition Syntax Rules. Specifically, the meaning and related restrictions of the decision operators in the attribute constraint syntax rules are shown in Table 1 below:

[0119] Table 1

[0120]

[0121]

[0122] Optionally, the attribute constraint can be a JSON expression. The above determiners can be used in attribute constraints, with the basic usage shown below:

[0123]

[0124] In this context, the conditional operators are related by a logical AND relationship. A single conditional operator can contain multiple lvalue-rvalue pairs, also exhibiting a logical AND relationship. For example, the property conditions for using the string equality conditional operator StringEquals are as follows:

[0125]

[0126] This means that the resource extended attribute attr1 must be equal to the string "abc", and the resource extended attribute attr2 must be equal to the user extended attribute attr2, both of which are strings. The general syntax rules apply to ordinary single-valued determiners. The syntax rules for multi-valued determiners are slightly different: when the right-hand side of a multi-valued determiner is a list, the syntax rules are as follows:

[0127]

[0128] For example, the property conditions for using the StringSubsetOf property to determine the subset of a list of strings are as follows:

[0129]

[0130] This means that the resource extended attribute attr1 must be a subset of the set ["aaa","bbb","ccc"].

[0131] In particular, combinational logic determiners use special syntax rules. For example, the syntax rules for the conditional semantic determiner Choices are as follows:

[0132]

[0133]

[0134]

[0135] This means that if the if condition is true, then the then condition must also be true; otherwise, if the else-if condition is true, then the then condition must also be true; otherwise, the else condition (if it exists) must also be true. The else clause is optional.

[0136] For example, the constraints for using the conditional semantics Choices decision operator are as follows:

[0137]

[0138]

[0139] The meaning is as follows: If the user's category attribute is one of the lists ["M,A,Q,T"] (condition 1), then the prefix of the resource's netOwner attribute must be "A" (condition 2); otherwise (i.e., condition 1 is not true), if the user's category attribute is not one of the lists ["M,A,Q,T"] (condition 3), then the prefix of the resource's netOwner attribute must be "S" (condition 4); otherwise (i.e., conditions 1 and 3 are not true), then the prefix of the resource's netOwner attribute must be "D" (condition 5).

[0140] The syntax rules for the logical OR semantic determiner Or are as follows:

[0141]

[0142]

[0143] This means that the multiple constraints connected by `Or` are logically ORed, and at least one of them must be true. The syntax rules for the logical AND semantic determiner `And` are:

[0144]

[0145] This means that the multiple constraints connected by AND are logically ANDed, and the whole condition is only true if all of them are true.

[0146] The Choices, Or, and And logical determiners can be combined and nested with other basic determiners to support complex permission rules.

[0147] Optionally, the attribute condition syntax rules described above can be combined and nested to form complex permission rules. For ease of use, an optional embodiment of the present invention also provides a recursive parsing algorithm for the syntax rules. This algorithm parses the attribute condition syntax rules to support the authorization query process (Authz), resource data query process (Query-Resource), and user data query process (Query-User). Specifically, the parsing algorithm solves the following problems: Authz: ​​Determines the attribute conditions in the program and returns success or failure. Query-Resource: Given known user extended attributes, determines the attribute conditions, resulting in failure or undeterminability (including resource attributes); converts the attribute conditions into Elasticsearch query conditions for resource extended attributes. Query-User: Given known resource extended attributes, determines the attribute conditions, resulting in failure or undeterminability (including user attributes); converts the attribute conditions into Elasticsearch query statements for user extended attributes.

[0148] Optionally, by analyzing the above process, the analytical algorithm can be broken down into the following sub-algorithms:

[0149] 1. Judgment Algorithm: The algorithm judges the attribute conditions based on user attributes and resource attributes, and returns success or failure.

[0150] 2. Partial decision algorithm: If the user attribute and resource attribute are consistent, the algorithm will make a decision on the attribute condition and return failure or undecidable.

[0151] 3. Elasticsearch query generation algorithm: Given either user attributes or resource attributes, convert the attribute conditions into an Elasticsearch query statement for the other.

[0152] The decision algorithm itself is unremarkable; it simply uses a depth-first search algorithm to recursively parse the attribute conditions, essentially implementing the original semantics of the decision operator using a programming language. Since the semantics of the decision operator originate from the programming language, implementing it directly in a programming language is straightforward when all parameters are available, and therefore will not be elaborated further.

[0153] Optionally, both the attribute condition determination algorithm and the Elasticsearch query generation algorithm are recursive algorithms used to convert attribute conditions into Elasticsearch query statements. The specific patterns for converting attribute conditions into Elasticsearch query statements (i.e., the Elasticsearch query statement patterns corresponding to the basic determiners) are shown in Table 2 below:

[0154] Table 2

[0155]

[0156] Logical determiners cannot directly generate basic queries; instead, they combine subqueries, as shown in the following pattern:

[0157] And: Bool (specify filter parameter) + subquery, which uses And to connect multiple query conditions by default;

[0158] OR: Boolean (specifying the should parameter) + subquery;

[0159] For the above decision rules, Elasticsearch provides equivalent query statements, allowing for equivalent conversion. However, the `Choices` decision rule does not directly support the `if-else` semantics expressed by Elasticsearch. Therefore, this invention proposes a conversion method for `if-else` conditional statements. Using this method, it is possible to convert `if-else` queries into equivalent query statements even when the search engine does not support them.

[0160] Optional, Figure 8 This is a flowchart illustrating an optional If-else conditional statement transformation method according to an embodiment of this application, as shown below. Figure 8 As shown:

[0161] S1: Based on whether the attribute conditions in the if statement are known, the conversion is divided into forward mode and reverse mode.

[0162] S2: If it is a forward mode, that is, all the attribute conditions involved in the if statement are known and can be directly judged, then go to step S3; otherwise, it is a reverse mode, go to step S4.

[0163] S3: Positive mode, which validates the attribute conditions contained in the if statement.

[0164] S3-1: Check if the if statement is successful. If it is successful, proceed to step S3-2; otherwise, proceed to step S3-3.

[0165] S3-2: Recursively return the query statement generated by the corresponding then statement, and the process ends.

[0166] S3-3: Check if there are any other if statements. If so, go to step S3; otherwise, go to step S3-4.

[0167] S3-4: Check if there is an else statement. If so, go to S3-5; otherwise, go to S3-6.

[0168] S3-5: Recursively return the query statement generated by the else statement, and the process ends.

[0169] S3-6: Returns an empty query, process ends.

[0170] S4: Reverse mode, check if an else statement is included. If included, go to step S4-1; otherwise, go to step S4-2.

[0171] S4-1: Contains an else statement, and converts the sub-conditions into query statements according to rule one below.

[0172] Rule 1:

[0173] Transformation rules for statements containing else:

[0174] If A then B

[0175] If C then D

[0176] else E

[0177] Convert to:

[0178] should:[

[0179] A and B,

[0180] Not A, C, and D

[0181] Not A and not C and E

[0182] ],

[0183] minimum_should_match:1

[0184] In this context, `should`, `and`, and `not` use Elasticsearch's Boolean query, and `minimum_should_match` means that at least one of the sub-conditions of `should` must be satisfied. The process ends here.

[0185] S4-2: If there is no else statement, convert the subcondition into a query statement according to rule two below.

[0186] Rule Two:

[0187] Transformation rules excluding else statements:

[0188] If A then B

[0189] If C then D is converted to:

[0190] should:[

[0191] A and B,

[0192] Not A, C, and D

[0193] not A and not C

[0194] ],

[0195] minimum_should_match:1

[0196] In this context, `should`, `and`, and `not` use Elasticsearch's Boolean query, and `minimum_should_match` means that at least one of the sub-conditions of `should` must be satisfied. The process ends here.

[0197] In other words, through the recursive parsing algorithm based on the above syntax rules, the original if-else query statement is transformed into the and, or, and should query statements supported by the search engine by logical combination, thereby executing the query.

[0198] Optionally, there are two algorithms: the attribute condition evaluation algorithm (Evaluate) and the query generation algorithm (GenQuery). Since both algorithms are recursive algorithms operating on attribute conditions, the decision delimiters are divided into "leaf nodes" and "intermediate nodes" based on whether they support combination. "Leaf nodes" do not support sub-conditions and cannot contain other nodes, such as basic decision delimiters like StringEquals; "intermediate nodes" contain sub-conditions and can contain other "intermediate nodes" or "leaf nodes," such as combinational logic decision delimiters Or, And, and Choices. Therefore, only "intermediate nodes" support recursive calls; hence, "leaf nodes" and "intermediate nodes" are identified separately.

[0199] The attribute condition partial determination algorithm addresses the problem of performing partial determination on attribute conditions when one of the user's extended attributes or resource extended attributes is known. There are three possible determination results:

[0200] 1. Successful determination: All attribute conditions are known and true. For example, the condition is "the value of user attribute attr1 is 1", and the user attribute is known and true.

[0201] 2. Failure Decision: The known attribute condition is deemed a failure, and the overall result is also a failure. For example, the condition is "the value of user attribute attr1 is 1", and the user attribute is known, but it happens to be false.

[0202] 3. Unable to determine: This condition is not considered a failure, but due to the existence of unknown attributes, it must be skipped. For example, if the condition is "the value of user attribute attr1 is 1", but the user attribute is unknown, it cannot be considered a failure and must be skipped.

[0203] It should be noted that failure has higher priority than inability to determine. Optionally, two return values ​​can be used to represent the three states: Return value `result`: Whether the determination was successful. A boolean value; if false, it indicates failure; if true, the return value `skipPass` determines whether the determination was successful or unsuccessful. Return value `skipPass`: Whether the determination was unsuccessful. A boolean value; only effective when `result` is true. If true, it indicates unsuccessful; if false, it indicates successful. This application does not impose any restrictions on this.

[0204] It should be noted that the algorithm for determining the attribute conditions described above takes the following inputs: attribute conditions, user attribute dictionary, and resource attribute dictionary (if either one is null, it means that the attribute is ignored), and finally outputs: result (whether the determination was successful) and shipPass (whether the determination could not be made). The specific process is as follows:

[0205] Step 1. If the current attribute conditional statement is the base conditional statement:

[0206] a) If the attribute criteria only include user-extended attributes:

[0207] i. If the user attribute dictionary is not null, proceed directly to the judgment. If the judgment is successful, result = true; if the judgment fails, result = false. shipPass = false.

[0208] ii. If the user attribute dictionary is null, return result = true and shipPass = true.

[0209] b) If the attribute criteria only contain resource extended attributes:

[0210] i. If the resource attribute dictionary is not null, proceed directly to the judgment. If the judgment is successful, result = true; if the judgment fails, result = false. shipPass is always false.

[0211] ii. If the resource attribute dictionary is null, return result=true and shipPass=true.

[0212] c) If the attribute condition includes user extended attributes and resource extended attributes: directly return result=true, shipPass=true.

[0213] Step 2. If the current attribute condition check is AND:

[0214] a) Recursively evaluate sub-conditions and merge them according to the following rules.

[0215] b) According to the logical semantics of AND, if a sub-condition returns failure, then failure is returned directly, i.e., result = false; skipPass = false.

[0216] c) Otherwise, if there exists a subcondition skipPass that is true, then skipPass is true; result = true.

[0217] Step 3. If the current attribute condition checkpoint is Or:

[0218] a) Recursively evaluate sub-conditions and merge them according to the following rules.

[0219] b) According to the OR logical semantics, if a sub-condition returns success, then result is true.

[0220] i. According to the logical semantics of OR, if there exists a subcondition that returns success and its skipPass is true, then skipPass is true.

[0221] ii. Otherwise, skipPass = false.

[0222] c) Otherwise, result = false, skipPass = false.

[0223] Step 4. If the current attribute condition checker is Choices:

[0224] a) Iterate through the if statements in the case, recursively evaluating the sub-conditions of the if statements until a sub-condition where result = true is found.

[0225] i. If the sub-condition skipPass is true, then return result=true, skipPass=true, indicating that it cannot be determined.

[0226] ii. If the sub-condition skipPass is false, it means that the if sub-condition is true, then the recursive return is the result of the corresponding then statement.

[0227] b) At this point, no if sub-conditions that return result as true have been found. Check for any else statements.

[0228] i. If there is no else statement, it means that the Choices criterion is optional, and return result = true, skipPass = false.

[0229] ii. If there is an else statement, then the recursion returns the result of the else statement.

[0230] As an optional implementation, the query generation algorithm (GenQuery) aims to convert attribute conditions into Elasticsearch queries, following the query conversion pattern described above. When generating a query, if part of the attribute condition fails, no further query generation is needed; therefore, the query generation algorithm calls the Evaluate algorithm. However, since Evaluate is a recursive algorithm, calling it at an "intermediate node" leads to recursive traversal of sub-conditions, which is highly inefficient. In fact, the GenQuery algorithm is also recursive and recursively traverses sub-conditions; therefore, it can return the Evaluate results of sub-conditions simultaneously during the recursive traversal.

[0231] Therefore, the return values ​​of the query generation algorithm include: `query`: the corresponding Elasticsearch query statement, which can be null to indicate an empty query. `result`: the same as the return value of the `Evaluate` algorithm. `skipPass`: the same as the return value of the `Evaluate` algorithm.

[0232] The query generation algorithm (GenQuery) is described as follows:

[0233] Name: Query Generation Algorithm (GenQuery);

[0234] Input: attribute conditions, user attribute dictionary, resource attribute dictionary (one of which is null, indicating that the attribute is ignored);

[0235] Output: query (corresponding query statement), result (whether the condition is true or false), shipPass (whether the condition cannot be determined);

[0236] Detailed process:

[0237] Step 1. If the current attribute conditional statement is the base conditional statement:

[0238] a) Call Evaluate to achieve the corresponding result and skipPass for this condition.

[0239] b) If result = false, it means the condition is not met, no query statement needs to be generated, and result = false is returned.

[0240] c) Otherwise, if the condition is met, generate the corresponding query statement according to the query statement conversion mode and return it.

[0241] Step 2. If the current attribute condition check is AND:

[0242] a) Recursively call the GenQuery algorithm to obtain the results for the sub-conditions, and merge them according to the following rules.

[0243] b) The processing of result and skipPass is the same as the Evaluate algorithm. That is, if there is a subcondition result = false, then result returns false and no query needs to be processed; otherwise, if there is a subcondition skipPass = true, then skipPass returns true.

[0244] c) If result is not false, process the queries for the sub-conditions. If a query for a sub-condition is null, skip it; merge the remaining queries for the sub-conditions using the AND pattern and return them; if all are skipped, return null for the query.

[0245] Step 3. If the current attribute condition checkpoint is Or:

[0246] a) Recursively call the GenQuery algorithm to obtain the results for the sub-conditions, and merge them according to the following rules.

[0247] b) The handling of result and skipPass is similar to Evaluate: if result = false for a subcondition, skip it; if skipPass = true for a subcondition, skipPass returns true.

[0248] c) Process queries with subconditions. If the subcondition query = null, i.e., an empty query, it means the condition is true, and according to the OR logical semantics, query = null is returned directly.

[0249] d) Check the number of remaining sub-conditions. If there is less than one, return result = false, indicating that the condition is not met.

[0250] e) Merge the remaining sub-condition queries according to the OR pattern and return them.

[0251] Step 4. If the current attribute condition checker is Choices:

[0252] a) Recursively call the GenQuery algorithm to obtain the results for all if sub-conditions in the case.

[0253] b) Check if there are cases where skipPass = true in the above results to distinguish between forward and reverse modes. Because the syntax restricts "if clauses at the same level can only contain either res.property_name or user.property_name", the meaning of skipPass—whether it is undeterminable—allows us to distinguish between forward and reverse modes.

[0254] c) If skipPass is not true, i.e., in forward mode:

[0255] i. Iterate through the return values ​​of the if sub-conditions, find the first condition where result is true, recursively call the GenQuery algorithm on its corresponding then statement and return.

[0256] ii. If none of the if subconditions are met, and an else statement exists, the GenQuery algorithm is recursively called on the else statement and returned.

[0257] iii. If all the if sub-conditions are met and there is no else statement, return query=null, result=true, skipPass=false to indicate an empty query.

[0258] d) If skipPass is true, i.e., reverse mode:

[0259] i. Recursively call the GenQuery algorithm on the then statement corresponding to each if statement to obtain the result and cache it.

[0260] ii. If the result returned by the if statement or the then statement is false, it means that the condition is not true. According to the if-else conditional statement conversion method above, the if-then statement is skipped.

[0261] iii. If an else statement exists, the GenQuery algorithm is recursively called on the else statement to obtain the result. If result = false in the result, it is treated as if no else statement exists.

[0262] iv. Merge queries: As mentioned above, the if-else conditional statement conversion method merges queries and returns them.

[0263] In other words, by proposing a set of syntax rule parsing algorithms, syntax rules can be directly converted into query statements, enabling efficient permission data retrieval using the capabilities of search engines. Furthermore, through the aforementioned set of attribute condition syntax rules and their parsing algorithms, specifically, the syntax rules support logical conditions such as if-else, and, or, which can be combined and nested. The corresponding query statement conversion scheme and recursive parsing algorithm can convert logical conditions into equivalent query statements, enabling efficient retrieval through search engines.

[0264] In summary, the optional embodiments of this invention propose a complete set of general-purpose permission management system implementation schemes, making the permission model compatible with RBAC+ABAC, capable of meeting various permission requirements of third-party application systems, and supporting efficient permission data querying. It supports complex attribute condition configurations, greatly enhancing the versatility of the permission management system. Furthermore, in addition to supporting authorization query requests, the permission management system also supports permission data queries, including querying resources that a user has permissions for, and querying authorized users for those resources. These types of requirements are common but often overlooked by other systems. Moreover, the permission management system supports rich attribute condition syntax rules, including logical expressions such as if-else, and, or, supporting combination and nesting, thereby supporting relatively complex permission configurations. This is something that existing related solutions cannot achieve.

[0265] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0266] Figure 9 This is a structural block diagram of an optional permission data query device according to an embodiment of this application; as shown below. Figure 9 As shown, it includes:

[0267] The first determining module 92 is used to determine the target identifier corresponding to the target object using the access control system, wherein the target identifier is a unique identifier of the target object through the authentication of the access control system;

[0268] The second determining module 94 is used to determine one or more role identifiers from a predefined first relationship set based on the target identifier, and to determine one or more resource identifiers from a predefined second relationship set and a predefined first relationship set based on the target identifier;

[0269] The permission module 96 is used to input the role identifier, the resource identifier, and the query conditions into the permission model pre-configured in the permission management system when it is determined that the managed object has entered the query conditions in the permission management system, to obtain the permission rules of the target object, and to parse the permission rules to determine the query results of the permission data corresponding to the target object.

[0270] The above-described device determines the target identifier corresponding to the target object using the access control system, wherein the target identifier is a unique identifier of the target object through the authentication of the access control system. Based on the target identifier, one or more role identifiers are determined from a predefined first relation set, and one or more resource identifiers are determined from a predefined second relation set and a predefined first relation set. If it is determined that the managed object has entered query conditions in the access control system, the role identifier, the resource identifier, and the query conditions are input into a pre-configured access control model in the access control system to obtain the access control rules for the target object. The access control rules are then parsed to determine the query results for the access control data corresponding to the target object. In other words, by confirming the target identifier of the target object using the access control system, the corresponding role identifier and resource identifier are determined, and the corresponding access control rules are obtained through the access control model. The access control rules are then parsed to obtain the access control data that the target object needs to query. This technical solution solves the problem in related technologies that cannot meet the query needs for access control data other than authorization requests, achieving compatibility with multiple access control models and enabling efficient and rapid querying of corresponding access control data.

[0271] In an exemplary embodiment, the aforementioned permission module is further configured to parse the permission rules to determine the target permission data corresponding to the target object; wherein the permission rules are used to indicate rules for allowing or denying the target object's permission to perform operations on resources; identify the limiting conditions in the target permission data, wherein the limiting conditions include at least: allowing or denying the object extended attributes corresponding to the target object and the resource extended attributes corresponding to the resource; and using the permission management system's search engine to query the permission management system's cache database and storage database based on the limiting conditions to obtain query results for the permission data corresponding to the target object.

[0272] In an exemplary embodiment, the above-mentioned permission module is further configured to determine the first content corresponding to the object extended attribute and the second content corresponding to the resource extended attribute; obtain the attribute conditions corresponding to the permission management system; and, if the restriction conditions satisfy the query criteria of the attribute conditions, determine the query result corresponding to the restriction conditions based on the first content, the second content, and the attribute conditions.

[0273] In an exemplary embodiment, the above apparatus further includes: a query module, configured to obtain a query instruction input by a target object, wherein the query instruction indicates the data type of the query result to be obtained by the target object, and the query instruction includes at least one of the following: an authorization query instruction of the target object, a resource data query instruction of the target object, and an object data query instruction of the target object; determining the preset permission rule features of the query instruction, and performing recognition processing on the permission rules based on the preset permission rule features to obtain the target permission rule corresponding to the query instruction.

[0274] In an exemplary embodiment, the query module is further configured to: when the query instruction is an authorization query instruction, determine that the data type corresponding to the target permission rule is a first rule, wherein the first rule is used to determine whether the target object has permission to operate resources; when the query instruction is a resource data query instruction, determine that the data type corresponding to the target permission rule is a second rule, wherein the second rule is used to determine the resources that the target object has permission to access; and when the query instruction is an object data query instruction, determine that a list of target objects for which resources under the current permission management system need to be obtained.

[0275] In an exemplary embodiment, the query module further includes: a first confirmation unit, configured to obtain a target identifier corresponding to the target object, a set of resource identifiers to be confirmed, and an operation type to be executed; determine a set of role identifiers corresponding to the target identifier from the cache database, and determine the resource extended attribute corresponding to each resource identifier in the set of resource identifiers to be confirmed and the resource corresponding to the set of resource identifiers; and determine a first rule based on the set of role identifiers, the resource extended attribute, the resource, and the operation type.

[0276] In an exemplary embodiment, the query module further includes: a second confirmation unit, configured to obtain the target identifier corresponding to the target object and the resource type to be confirmed, determine the extended attribute value corresponding to the target identifier from the cache database; determine the corresponding rule filtering conditions based on the extended attribute value and the resource type, and query the target object using the rule filtering conditions and the permission rules of the target object to obtain a second rule.

[0277] In an exemplary embodiment, the query module further includes: a third confirmation unit, configured to stop the identification processing of the target permission rules, and obtain the set of role identifiers to be confirmed and the set of resource identifiers to be confirmed input by the target object; determine the set of objects that match the role identifiers in the set of role identifiers to be confirmed in the storage database, and determine the resource extended attributes corresponding to each resource identifier in the set of resource identifiers to be confirmed, wherein the resource extended attributes include: the extended attribute value of the resource and the resource path corresponding to the resource; and determine the list of target objects with subordinate resource permissions of the permission management system based on the multiple resource extended attributes corresponding to the set of objects and the set of resource identifiers to be confirmed.

[0278] In an exemplary embodiment, the third confirmation unit is further configured to determine, in the rule records of the permission management system, permission rules that match objects in the object set; convert the restrictions in the permission rules into a first query statement according to preset syntax rules, and add the plurality of resource extension attributes to the query statement to obtain a second query statement; use the second query statement to match in the storage database of the permission management system to obtain a list of target objects with subordinate resource permissions.

[0279] Embodiments of this application also provide a storage medium including a stored program, wherein the program executes any of the methods described above when it is run.

[0280] Optionally, in this embodiment, the storage medium may be configured to store program code for performing the following steps:

[0281] S1, determine the target identifier corresponding to the target object using the access control system, wherein the target identifier is a unique identifier of the target object through the authentication of the access control system;

[0282] S2, determine one or more role identifiers from a predefined first relationship set based on the target identifier, and determine one or more resource identifiers from a predefined second relationship set and a predefined first relationship set based on the target identifier;

[0283] S3, if it is determined that the management object has entered the query conditions in the permission management system, the role identifier, the resource identifier and the query conditions are input into the permission model pre-configured in the permission management system to obtain the permission rules of the target object, and the permission rules are parsed to determine the query results of the permission data corresponding to the target object.

[0284] Embodiments of this application also provide an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0285] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0286] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0287] S1, determine the target identifier corresponding to the target object using the access control system, wherein the target identifier is a unique identifier of the target object through the authentication of the access control system;

[0288] S2, determine one or more role identifiers from a predefined first relationship set based on the target identifier, and determine one or more resource identifiers from a predefined second relationship set and a predefined first relationship set based on the target identifier;

[0289] S3, if it is determined that the management object has entered the query conditions in the permission management system, the role identifier, the resource identifier and the query conditions are input into the permission model pre-configured in the permission management system to obtain the permission rules of the target object, and the permission rules are parsed to determine the query results of the permission data corresponding to the target object.

[0290] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0291] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0292] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing systems. They can be centralized on a single computing system or distributed across a network of multiple computing systems. Optionally, they can be implemented using program code executable by a computing system, thereby storing them in a storage system for execution by the computing system. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0293] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for querying permission data, characterized in that, include: Determine the target identifier corresponding to the target object using the access control system, wherein the target identifier is a unique identifier for the target object through the authentication of the access control system; Based on the target identifier, one or more role identifiers are determined from a predefined first set of relationships, and one or more resource identifiers are determined from a predefined second set of relationships and a predefined first set of relationships, based on the target identifier; If it is determined that the management object has entered the query conditions in the permission management system, the role identifier, the resource identifier and the query conditions are input into the permission model pre-configured in the permission management system to obtain the permission rules of the target object, and the permission rules are parsed to determine the query results of the permission data corresponding to the target object; The permission rules include: the relationship between users and roles; the relationship between roles and permissions; resource paths, resource extended attribute conditions, user extended attribute conditions, and permissions corresponding to allowed operations; The permission model includes multiple sets of permission rule data. One set of permission rule data includes: roles corresponding to one or more role identifiers, resources corresponding to one or more resource identifiers associated with the roles, and a set of restrictions involving target object attributes and resource attributes.

2. The method for querying permission data according to claim 1, characterized in that, Parsing the permission rules to determine the query results for the permission data corresponding to the target object includes: The permission rules are parsed to determine the target permission data corresponding to the target object; wherein, the permission rules are used to indicate the rules that allow or deny the target object to perform operations on resources; Identify the restrictions in the target permission data, wherein the restrictions include at least: allowing or denying the object extended attributes corresponding to the target object and the resource extended attributes corresponding to the resource; The search engine of the permission management system performs a query based on the restrictions in the cache database and storage database of the permission management system to obtain the query results of the permission data corresponding to the target object.

3. The method for querying permission data according to claim 2, characterized in that, The search engine of the access control system performs queries based on the restrictions in the cache database and storage database of the access control system to obtain corresponding query results, including: Determine the first content corresponding to the object's extended attribute and determine the second content corresponding to the resource's extended attribute; Obtain the attribute conditions corresponding to the permission management system; If the constraints meet the query criteria of the attribute conditions, the query results corresponding to the constraints are determined based on the first content, the second content, and the attribute conditions.

4. The method for querying permission data according to claim 1, characterized in that, Before parsing the permission rules to determine the query results for the permission data corresponding to the target object, the method further includes: Obtain the query instruction input by the target object, wherein the query instruction is used to indicate the data type of the query result to be obtained by the target object, and the query instruction includes at least one of the following: the target object's authorization query instruction, the target object's resource data query instruction, and the target object's object data query instruction; The preset permission rule features of the query instruction are determined, and the permission rules are identified and processed based on the preset permission rule features to obtain the target permission rule corresponding to the query instruction.

5. The method for querying permission data according to claim 4, characterized in that, Determine the preset permission rule features of the query instruction, and perform identification processing on the permission rules based on the preset permission rule features to obtain the target permission rule corresponding to the query instruction, including: When the query instruction is an authorization query instruction, the data type corresponding to the target permission rule is determined to be a first rule, wherein the first rule is used to determine whether the target object has the permission to operate resources; When the query instruction is a resource data query instruction, the data type corresponding to the target permission rule is determined to be a second rule, wherein the second rule is used to determine the resources that the target object has permission for; When the query instruction is an object data query instruction, it is determined that a list of target objects corresponding to the resources under the current permission management system needs to be obtained.

6. The method for querying permission data according to claim 5, characterized in that, When the query instruction is an authorization query instruction, determining that the data type corresponding to the target permission rule is a first rule includes: Obtain the target identifier corresponding to the target object, the set of resource identifiers to be confirmed, and the operation type to be executed; Determine the set of role identifiers corresponding to the target identifier from the cache database, and determine the extended resource attributes corresponding to each resource identifier in the set of resource identifiers to be confirmed, as well as the resource corresponding to the set of resource identifiers; The first rule is determined based on the set of role identifiers, the extended attributes of the resources, the resources, and the operation type.

7. The method for querying permission data according to claim 5, characterized in that, When the query instruction is a resource data query instruction, determining that the data type corresponding to the target permission rule is a second rule includes: Obtain the target identifier and the resource type to be confirmed corresponding to the target object, and determine the extended attribute value corresponding to the target identifier from the cache database; Based on the extended attribute value and the resource type, the corresponding rule filtering conditions are determined. The target object is queried using the rule filtering conditions and the permission rules of the target object to obtain the second rule.

8. The method for querying permission data according to claim 5, characterized in that, When the query instruction is an object data query instruction, it is determined that a list of target objects corresponding to the resources under the current permission management system needs to be obtained, including: Obtain the set of role identifiers to be confirmed and the set of resource identifiers to be confirmed input by the target object; In the storage database, determine the set of objects that match the role identifiers in the set of role identifiers to be confirmed, and determine the resource extended attributes corresponding to each resource identifier in the set of resource identifiers to be confirmed, wherein the resource extended attributes include: the extended attribute value of the resource and the resource path corresponding to the resource; The list of target objects with subordinate resource permissions in the permission management system is determined based on the multiple extended attributes corresponding to the object set and the resource identifier set to be confirmed.

9. The method for querying permission data according to claim 8, characterized in that, Based on the object set and the set of resource identifiers to be confirmed, a list of target objects with subordinate resource permissions in the permission management system is determined, including: The permission rules that match the objects in the object set are determined from the rule records of the permission management system; According to the preset syntax rules, the restriction conditions in the permission rules are transformed into a first query statement, and the multiple resource extended attributes are added to the query statement to obtain a second query statement; The second query statement is used to match the data in the storage database of the permission management system to obtain a list of target objects with subordinate resource permissions.

10. A device for querying access control data, characterized in that, include: The first determining module is used to determine the target identifier corresponding to the target object using the access control system, wherein the target identifier is a unique identifier of the target object through the authentication of the access control system; The second determining module is used to determine one or more role identifiers from a predefined first relationship set based on the target identifier, and to determine one or more resource identifiers from a predefined second relationship set and a predefined first relationship set based on the target identifier; The permission module is used to input the role identifier, the resource identifier, and the query conditions into the permission model pre-configured in the permission management system when it is determined that the managed object has entered the query conditions in the permission management system, to obtain the permission rules of the target object, and to parse the permission rules to determine the query results of the permission data corresponding to the target object. The permission rules include: the relationship between users and roles; the relationship between roles and permissions; resource paths, resource extended attribute conditions, user extended attribute conditions, and permissions corresponding to allowed operations; The permission model includes multiple sets of permission rule data. One set of permission rule data includes: roles corresponding to one or more role identifiers, resources corresponding to one or more resource identifiers associated with the roles, and a set of restrictions involving target object attributes and resource attributes.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method of any one of claims 1 to 9.

12. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method of any one of claims 1 to 9 through the computer program.

Images