Resource Access Control Method, Device, Electronic Device, Storage Medium and Product

Abstract

The present application provides a resource access control method, apparatus, electronic device, storage medium and product. The method includes: receiving an access request of a target user for a target resource, where the access request includes a user identifier of the target user, determining a user group corresponding to the target user according to the user identifier, determining an access right of the target user according to the user group, and in response to the access right of the target user being able to access the target resource, returning information of the target resource corresponding to the access right of the target user. The efficient management of user permissions in a project management system can be achieved by a method of managing user access rights based on user groups.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a resource access control method, device, electronic device, storage medium and product. Background Art

[0002] Permission control is an important part of project management system access control and data security. It can effectively prevent unauthorized users from accessing or operating the system, thereby preventing security threats such as data leakage, tampering or destruction.

[0003] For enterprises with more business content, different users (for example, enterprise employees) in the project management system need to have different permissions. How to manage user permissions is a technical problem that needs to be solved urgently. Summary of the invention

[0004] In view of this, the purpose of the present application is to propose a resource access control method, device, electronic device, storage medium and product to solve or partially solve the above-mentioned problems.

[0005] Based on the above objectives, in a first aspect, the present application provides a resource access control method, including:

[0006] Receiving an access request from a target user for a target resource, the access request including a user identifier of the target user;

[0007] Determining a user group corresponding to the target user according to the user identifier;

[0008] Determining access rights of the target user according to the user group;

[0009] In response to the target user's access authority being able to access the target resource, information of the target resource corresponding to the target user's access authority is returned.

[0010] In a second aspect of the present application, a resource access control device is provided, comprising:

[0011] A receiving module, configured to receive an access request from a target user for a target resource, wherein the access request includes a user identifier of the target user;

[0012] A first determination module is configured to determine a user group corresponding to the target user according to the user identifier;

[0013] A second determination module is configured to determine the access rights of the target user according to the user group;

[0014] A return module, configured to be able to access the target resource in response to the access permission of the target user, and return information of the target resource corresponding to the access permission of the target user.

[0015] In a third aspect of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the method described in the first aspect is implemented.

[0016] In a fourth aspect of the present application, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium stores computer instructions for causing a computer to execute the method described in the first aspect.

[0017] In a fifth aspect of the present application, a computer program product is provided, including computer program instructions. When the computer program instructions run on a computer, the computer is caused to execute the method described in the first aspect.

[0018] As can be seen from the above, a resource access control method, device, electronic device, storage medium, and product provided by the present application are provided. The method includes: receiving an access request of a target user for a target resource, where the access request includes a user identifier of the target user, determining a user group corresponding to the target user according to the user identifier, determining an access permission of the target user according to the user group, and in response to the access permission of the target user being able to access the target resource, returning information of the target resource corresponding to the access permission of the target user. Efficient management of user permissions in a project management system can be achieved by a method of managing user access permissions based on user groups. Description of the Drawings

[0019] In order to more clearly illustrate the technical solutions in the present application or related technologies, the following will briefly introduce the drawings required for use in the embodiments or related technology descriptions. Obviously, the drawings in the following description are only embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0020] Figure 1 A schematic diagram of an exemplary system according to an embodiment of the present application is shown.

[0021] Figure 2A A schematic diagram of an exemplary permission model according to an embodiment of the present application is shown.

[0022] Figure 2B A flowchart of a method for constructing an exemplary permission model according to an embodiment of the present application is shown.

[0023] Figure 2C The flowchart shows an exemplary permission management method according to an embodiment of the present application.

[0024] Figure 3A The schematic diagram shows an exemplary permission model according to an embodiment of the present application.

[0025] Figure 3B The schematic diagram shows another exemplary permission model according to an embodiment of the present application.

[0026] Figure 4 The flowchart shows an exemplary permission granting method according to an embodiment of the present application.

[0027] Figure 5 The flowchart shows an exemplary resource access control method according to an embodiment of the present application.

[0028] Figure 6 The flowchart shows an exemplary resource access control method according to an embodiment of the present application.

[0029] Figure 7 The schematic diagram shows an exemplary resource access control device according to an embodiment of the present application.

[0030] Figure 8 The schematic diagram shows an exemplary electronic device according to an embodiment of the present application. Detailed Embodiments

[0031] To make the objectives, technical solutions, and advantages of the present application more clear and understandable, the following further describes the present application in detail with reference to specific embodiments and the accompanying drawings.

[0032] It should be noted that unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should have the ordinary meanings understood by those of ordinary skill in the art to which the present application belongs. The terms "first", "second", and similar terms used in the embodiments of the present application do not denote any order, quantity, or importance, but are only used to distinguish different components. The terms "including", "comprising", or similar terms mean that the elements or items appearing before the term cover the elements or items listed after the term and their equivalents, without excluding other elements or items. The terms "connected" or "coupled" do not limit to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The terms "upper", "lower", "left", "right", etc. are only used to represent relative positional relationships, and when the absolute position of the object being described changes, the relative positional relationship may also change accordingly.

[0033] It is understandable that before using the technical solutions of the various embodiments of the present application, the types, usage scopes, usage scenarios, etc. of the personal information involved will be informed to the user in an appropriate manner, and the user's authorization will be obtained.

[0034] For example, when responding to receiving an active request from the user, a prompt message is sent to the user to clearly prompt the user that the operation requested by the user will require obtaining and using the user's personal information. Thus, the user can autonomously choose whether to provide personal information to software or hardware such as an electronic device, an application program, a server, or a storage medium that executes the operation of the technical solution of the present application according to the prompt message.

[0035] As an optional but non-limiting implementation manner, the manner of sending a prompt message to the user in response to receiving an active request from the user can be, for example, in the form of a pop-up window, and the prompt message can be presented in text in the pop-up window. In addition, the pop-up window can also carry a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0036] It is understandable that the above process of notifying and obtaining the user's authorization is only illustrative and does not limit the implementation manner of the present application, and other manners that comply with relevant laws and regulations can also be applied to the implementation manner of the present application.

[0037] Access control technology is an important part of information technology security. Using access control technology can protect resources and prevent unauthorized access to the resources, thus bringing security risks. In practical applications, a permission model can be used to manage the permissions of access subjects. An access subject with permissions can access the resources, and an access subject without permissions cannot access the resources. The access subject can include users, electronic devices, etc. The permission can refer to the right to access resources. The resources can include data, pictures, etc. The access can include querying, deleting, inserting, modifying, etc.

[0038] The permission model may include permission models such as the RBAC (Role-Based Access Control) model and the ABAC (Attribute-Based Access Control) model. The RBAC model introduces the concept of roles between the access subject and permissions. An access subject can be associated with one or more roles, and a role can be associated with one or more permissions. By assigning a role to an access subject, permissions can be granted to the access subject. The ABAC model introduces the concept of attribute information. Whether to grant permissions to an access subject is determined according to the control policy of the attribute information and permissions. The attribute information may include access subject attribute information, resource attribute information, and environmental attribute information, etc. The access subject attribute information may include the user's identity, age, position, length of service, etc. The resource attribute information may include the size of the resource, the security level of the resource, the sensitivity of the resource, etc. The environmental attribute information may include time, location (such as IP address, etc.), device identifier (such as the model of the device, etc.).

[0039] In the RBAC model, roles are relatively fixed and not flexible enough to perform fine-grained permission management on access subjects. In the ABAC model, the design and maintenance of permission control policies are relatively complex, resulting in a relatively high cost of permission management.

[0040] In view of this, the present application proposes a resource access control method, device, electronic device, storage medium and product. The method includes: receiving an access request of a target user for a target resource, the access request including the user identifier of the target user, determining the user group corresponding to the target user according to the user identifier, determining the access permission of the target user according to the user group, and returning the information of the target resource corresponding to the access permission of the target user in response to the access permission of the target user being able to access the target resource. Efficient management of user permissions in a project management system can be achieved by means of the method of managing user access permissions based on user groups.

[0041] Figure 1 FIG. shows a schematic diagram of an exemplary system 100 according to an embodiment of the present application.

[0042] As Figure 1As shown, the system 100 may include a user terminal 102. The user terminal 102 may be a device for the user 104 (e.g., an employee of an enterprise), including but not limited to a smart phone, a tablet electronic device, a portable computer, a desktop computer, etc. The user terminal 102 may be used to initiate a permission application request and / or a resource access request. For example, the user 104 may send a permission application request and / or a resource access request to the permission management server through the user terminal 102.

[0043] The system 100 may further include a permission management server 106. The permission management server 106 may be a single server, a server cluster composed of multiple servers, or a server deployed in the cloud. The permission management server 106 may manage permissions according to a permission model.

[0044] The system 100 may further include a database 118. The database 118 may store data tables for constructing a permission model. The permission management server 106 may manage permissions by looking up corresponding data in the database 118. For example, the permission management server 106 may determine whether a user has access permission to a resource by looking up in the database 118 whether there is a resource identifier that matches the user identifier.

[0045] The system 100 may further include a resource management server 108. The resource management server 108 may be a single server, a server cluster composed of multiple servers, or a server deployed in the cloud. The resource management server 108 may be used to manage resources.

[0046] The system 100 may further include an authentication terminal 110. The authentication terminal 110 may be a device for the permission verification personnel 112 (e.g., a department leader of an enterprise), including but not limited to a smart phone, a tablet electronic device, a portable computer, a desktop computer, etc. The authentication terminal 110 may be used to verify the permissions of the user 104.

[0047] The system 100 may further include a management terminal 114. The management terminal 114 may be a device for the permission management personnel 116 (e.g., a human resources personnel of an enterprise), including but not limited to a smart phone, a tablet electronic device, a portable computer, a desktop computer, etc. The management terminal 114 may be used to initiate a permission application request to apply for permissions for the user 104. For example, the management personnel 116 may send a permission application request to the permission management server 106 through the management terminal 114, and the permission management server 106 may grant permissions to the user 104 according to the permission model.

[0048] In an exemplary application scenario, user 104 can be an employee of an enterprise. After an enterprise employee starts work, in order to be able to carry out work, some basic permissions need to be obtained. For this purpose, the human resources personnel of the enterprise (user 116) can apply for basic permissions for the employee after the employee starts work. Specifically, after an employee starts work, an employee identifier can be assigned to the employee. The employee identifier can be, for example, the employee's account, the employee's work number, or the employee's nickname, etc. User 104 and / or user 116 can send a permission application request to the permission management server 106 through the user terminal 102. The permission application request can include the employee identifier.

[0049] The permission management server 106 can grant permissions to user 104 according to the permission model and send the permission application result to the user terminal 102 and / or the management terminal 114. The user terminal 102 and / or the management terminal 114 can receive the permission application result. In this way, the permission management server 106 can assign basic permissions to newly hired employees.

[0050] Figure 2A FIG. shows a schematic diagram of an exemplary permission model 200 according to an embodiment of the present application. In some embodiments, the permission model 200 can be a model constructed from metadata.

[0051] As Figure 2A shown, the permission model 200 can include an entity domain 202, an authorization relationship domain 204, a rule domain 206, and an entity group domain 208. Among them, the elements in the entity domain 202 can include the entities of the permission model 200 (for example, subjects, objects), object operations, and operation associations. The elements in the authorization relationship domain 204 can include the authorization relationships between the main and object entities. The elements in the rule domain 206 can include the diffusion rules of entities (for example, users and user groups), the combination relationships of the diffusion rules, and the merging rules of the authorization paths (for example, passing if any one passes or passing only if all pass). The elements in the entity group domain 208 can include the diffusion data of entities (for example, users and user groups, departments and user groups). By abstracting the relationships between entities as diffusion rules, the difficulty of constructing entity relationships is reduced. In this way, when new entity relationships need to be added, only the processing of the corresponding relationships needs to be written; when the entity relationships change, only the processing logic of the corresponding rules needs to be adjusted. In addition, the diffusion rules can be combined arbitrarily, which improves the reuse degree of the rules and also improves the construction speed of new permission points.

[0052] It should be noted that an entity can be an element of the permission model, used to identify each object type in the system, for example, users, departments, spaces, work item instances, etc.

[0053] Elements in the entity domain 202 can be stored in the data table in the form of a data table. The data table in the entity domain 202 may include an entity operation relationship table 2022, an entity operation table 2024, and an entity type table 2026. In some embodiments, the entity type table 2026 may be an alias of an object type, and the object type may be an object type that requires permission control. Exemplarily, the entity type table 2026 may include users, departments, spaces, work item instances, etc. In some embodiments, the operation types supported by the entity may be defined in the entity operation table 2024. For example, the access permission of a space, the view permission of a work item instance, etc. In some embodiments, the entity operation relationship table 2022 can be used to reflect the combination relationship of operations and reduce the complexity of establishing authorization relationships. For example, the management permission of a space automatically obtains the access permission of the space. Exemplarily, when user A obtains the space management permission, the relationship between user A's access permission to the space does not need to be reflected at the storage level.

[0054] The data in the entity type table 2026 can be stored in the form of an identifier (id), an entity type code (code), and a type description (description). For example, the identifier is 1001, the entity type code is User, and the type description is employee.

[0055] The data in the entity operation table 2024 can be stored in the form of an identifier (id), an operation type code (code), and an entity type identifier (entity_type_id). For example, the identifier is 2001, the operation type code is WorkItemView, and the entity type identifier is WorkItem.

[0056] Elements in the authorization relationship domain 204 can be stored in a data table in the form of a data table. The data table in the authorization relationship domain 204 may include an entity authorization data table 2042, an entity type authorization wide table 2044, an authorized association rule table 2046, and an entity type authorization table 2048. In some embodiments, the entity type authorization table 2048 is used to define, for example, that subject A has the operation permission C for object B. Exemplarily, a spatial member user group (subject A) has the access permission (operation permission C) for a space (object B). In some embodiments, the authorized association rule table 2046 can be used to define which authorization relationships the entity diffusion rule can apply to. For example, the diffusion rule that subordinate C of user B belongs to user group A, where user group A has both space access permissions and data permissions and operation permissions. However, since the permission level of subordinate C is lower than that of user B, this diffusion rule does not apply to [the space access permission of user group A], but applies to [the data permission and operation permission of user group A], that is, subordinate C can have data permission and operation permission, but cannot have space access permission. In some embodiments, the entity type authorization wide table 2044 can be used to define what authorization paths exist for the operation from the subject to the object. For example, the space access permission of a user may include the following authorization paths:

[0057] User B → Tenant administrator (group) E → Access permission for space D;

[0058] User B → User group A → Access permission for space D;

[0059] User B → Department C → User group A → Access permission for space D.

[0060] In some embodiments, the entity authorization data table 2042 can be used to define that subject A has the operation permission C for object B. For example, a spatial member user group A has the access permission for space B.

[0061] Among them, the data in the entity type authorization table 2048 can be stored in the form of an identifier (id), code, subject type (subject_entity_type_id), object type (object_entity_type_id), operation (action_id), effect, and calculation type (mode). For example, the identifier is 6001, the code is UserGroup_Auth_WorkItemCollectionView, the subject type is UserGroup, the object type is WorkItemCollection, the operation is WorkItemCollectionView, the effect is allow (or deny), and the calculation type is 1. Among them, a calculation type of 1 means starting from the subject for calculation, and a calculation type of 2 means starting from the object for calculation.

[0062] Elements in the rule domain 206 can be stored in a data table in the form of a data table. The data tables in the rule domain 206 may include a rule table 2062, a rule relationship table 2064, and an authorized effective rule table 2066. In some embodiments, the rule table 2062 can be used to define the abstraction of system rules. For example, the diffusion rules between entities. Exemplarily, the diffusion rule between entities: when user group A obtains the access right to a space, member user B of user group A automatically obtains the access right to the space. At this time, the relationship from user B to user group A belongs to a kind of entity diffusion rule. In some embodiments, the rule relationship table 2064 can be used to reflect the combination relationship between rules to improve the reuse of rules. Exemplarily, the diffusion rules from user to user group can include the following two types:

[0063] User → User Group: User B is directly added to user group A;

[0064] User → Department → User Group: User B belongs to the superior department C, and department C is directly added to the user group. This rule belongs to a kind of combined rule, and this combined rule can include two sub - rules:

[0065] User → Department: In the list of superior departments of user B, there is department C;

[0066] Department → User Group: Department C is directly added to user group A.

[0067] In some embodiments, the authorized effective rule table 2066 can be used to define how to determine authentication when there are multiple authorization paths for the operation from the subject to the object. The determination methods can include the following two types:

[0068] OR: It means that if any one of the authorization paths is determined to pass, then this request is determined to pass;

[0069] AND: It means that only when all authorization paths are determined to pass, this request is determined to pass.

[0070] Exemplarily, when determining whether user B has the access right to space A, there may be multiple authorization paths:

[0071] User B → Tenant Administrator (Group) E → Access right to space A;

[0072] User B → User Group A → Access right to space A;

[0073] User B → Department C → User Group A → Access right to space A.

[0074] When the effective rule is [OR], that is, if any one of the above - mentioned authorization paths passes, it is determined that the user has the access right to space A.

[0075] The data in the rule table 2062 can be stored in the form of an identifier (id), rule type code (code), source entity (source_entity_type_id), target entity (target_entity_type_id), rule type (type), rule information (expression), and description (description). For example, the identifier is 3003, the rule type code is User_UserGroup, the source entity is User, the target entity is UserGroup, the rule type is entity group, the rule information is UserGroup, and the description is user->user group.

[0076] The data in the rule relationship table 2064 can be stored in the form of an identifier (id), parent rule (parent_rule_id), child rule (sub_rule_id), and sorting of the child rule (sub_order). For example, the identifier is 4001, the parent rule is User_Department_UserGroup, the child rule is User_Department, and the sorting of the child rule is 1.

[0077] The elements in the entity group domain 208 can be stored in a database in the form of a data table. The data tables in the entity group domain 208 can include an entity group table 2082, an entity group business attribute table 2084, and an entity group member table 2086. In some embodiments, the entity group table 2082 can be used to combine a batch of entities into a new entity type and distinguish different entity types by type. For example, users and departments can be combined into a user group: user group (user / department). In some embodiments, the entity group business attribute table 2084 can store the business attributes of the entity group that are not involved in permission calculation. The business attributes of the entity group, for example, can be the name of the user group. In some embodiments, the entity group member table 2086 can include the member list of the entity group. For example, the members of the entity group that is a user group include users and departments.

[0078] By using metadata to construct the permission model 200 and configure the control logic of the permission model 200, the permission control requirements of different systems can be adapted. In this way, different systems can reuse the permission model 200, avoiding the problem of duplicate development of the permission model.

[0079] Figure 2B The flowchart of the construction method 210 of the exemplary permission model 200 according to an embodiment of the present application is shown. Taking the construction of the permission model for [users to view work item instances] as an example, as Figure 2B shown, the method 210 may include the following steps.

[0080] In step 212, an entity type table 2026 can be created. The entity types stored in the entity type table 2026 can include employees, work item instance data, work item instance data sets, user groups, spaces, departments, and space administrator user groups.

[0081] In step 214, an entity operation table 2024 can be created. The data stored in the entity operation table 2024 can include operation types corresponding to the entity types. For example, the operation type corresponding to work item instance data can be a work item instance data viewing operation, the operation type corresponding to a space can be a space management operation, and the work item instance data set can be a work item instance data set viewing operation.

[0082] In step 216, an entity operation relationship table 2022 can be created. The data stored in the entity operation relationship table 2022 can include the correspondence between parent operations and child operations. For example, the parent operation can be a management operation, and the corresponding child operation of the management operation can be a viewing operation. The parent operation can be a work item instance data set viewing operation, and the corresponding child operation of the work item instance data set viewing operation can be a work item instance data viewing operation.

[0083] In step 218, a rule table 2062 can be created. The rule types stored in the rule table 2062 can include entity groups, rule sequences, BQL rules (a kind of circumscription rule based on entity attributes), preset rules, combination rules, and impact rules. The rule information in the rule table 2062 can be used to describe the user group types of entity user groups.

[0084] In step 220, a rule relationship table 2064 can be created. The data stored in the rule relationship table 2064 can include the combination relationships of the rules in the rule table 2062. For example, a user can be directly added to a user group, and a user can also be added to a department first, and then the department can be directly added to the user group.

[0085] In step 222, an entity type authorization table 2048 can be created. The data stored in the entity type authorization table 2048 can include that the user group has the viewing operation of the work item instance data set, and the space administrator user group has the management operation of the space.

[0086] In step 224, an authorized association rule table 2046 can be created. The data stored in the authorized association rule table 2046 can include that when the subject is a user group, the subject has the viewing operation of the work item instance data set; when the subject is a space administrator user group, the subject has the management operation of the space; when the object is work item instance data, the object has the viewing operation of the work item instance data set.

[0087] In step 226, the system can automatically derive the entity type authorization wide table 2044. For example, when the subject is a user and the object is work item instance data, the user has the viewing operation of the work item instance data set. The user can find the user group to which the user belongs according to the subject rule, and the work item instance data set can find the work item instance data according to the object rule.

[0088] In the permission model 200, since the permission relationship between the subject and the object, as well as the object operation and operation association, are defined in the entity type table 2026 in the entity domain 202, when a new user needs to be added (for example, adding permissions for a newly hired employee), the permission manager 116 only needs to create a user group for the user in the entity group domain 208 and add the user identifier to the user group. The permission management server 106 can find the access permissions owned by the user group according to the permission model 200. The permission manager 116 grants the user the target access permission in the found access permissions. In this way, when granting permissions to a new user, the permissions that can be granted can be automatically matched through the permission model 200, saving the operation of the permission manager 116.

[0089] Figure 2C The flowchart of an exemplary permission management method 230 according to an embodiment of the present application is shown.

[0090] As Figure 2C shown, when the permission manager 116 grants permissions to a user, in some embodiments, the management terminal 114 can receive a permission application request sent by the user (for example, the user to whom permissions are to be granted). The permission application request may include the user identifier. The permission manager 116 can create an entity group table for the user through the management terminal 114. The entity group table can define the entity group identifier and the entity group to which the entity group identifier belongs. For example, it can be defined that the entity group identifiers with fields UserGroup1 and UserGroup2 belong to the entity group with the field UserGroup.

[0091] In some embodiments, the permission manager 116 can create an entity group business attribute table through the management terminal 114, and the Chinese name of the entity group identifier can be defined in the entity group business attribute table. For example, it can be defined that the Chinese name corresponding to the entity group identifier with the field UserGroup1 is user group 1, and the Chinese name corresponding to the entity group identifier with the field UserGroup2 is user group 2.

[0092] After creating the entity group table and the entity group business attribute table, in some embodiments, the permission manager 116 may, through the management terminal 114, add entity group members in the entity group member table according to the user identifier. For example, the user identifier may be added to the entity group identifiers with fields UserGroup1 and UserGroup2. In this way, the user can obtain the access permissions corresponding to the entity group identifiers with fields UserGroup1 and UserGroup2.

[0093] In this way, the entity group domain 208 can abstract the aggregation relationship of entities into entity groups, thereby reducing the complexity of granting permissions to users. For example, when a new user needs to be added, only the metadata model of the entity group of the user needs to be added for permission management.

[0094] Figure 3A FIG. shows a schematic diagram of an exemplary permission model 300 according to an embodiment of the present application. The permission model 300 may be the permission model 200.

[0095] As Figure 3A shown, in some embodiments, the object 1 may be the resource to be accessed by the subject 1, and the object 2 may be the resource to be accessed by the subject 2. Among them, the subject (for example, the subject 1 and the subject 2) may be an element of the permission model 300, which can be both a specific visitor (such as a user) during authentication and a set of authorized visitors (such as a department / user group) during authorization; the object (for example, the object 1 and the object 2) may be an element of the permission model 300, which can be both a specific resource (such as a space, a work item instance, etc.) during authentication and a set of resources defined during authorization (such as a space / work item instances defined by a BQL rule, etc.).

[0096] It should be noted that a user may be a person using the system, for example, an employee of an enterprise. A department may be, for example, a group of employees aggregated in a certain way to form an organizational unit that is easy to manage and is a basic unit of enterprise management. A user group may be a role in permission management, for example, a group of employees / departments aggregated in a certain way and is a basic unit of permission management. A work item instance may represent a piece of work. A space may be a data isolation dimension of work item instances, and a group of work item instances are aggregated in a certain way.

[0097] The authorization path may be the path of a certain operation type from the subject to the object. For example, there are multiple authorization paths for a user to be granted access permissions to a space:

[0098] Authorization path 1: User → Tenant administrator (group) → Access permission to the space;

[0099] Authorization path 2: User → User group → Access permission to the space;

[0100] Authorization path 3: Access rights for users → departments → user groups → spaces;

[0101] Among them, the tenant administrator can be a role in permission management, aggregating a group of employees in a certain way, and this role has the permission to perform any operation within the tenant.

[0102] In the permission model 300, the authorization path for subject 1 to be granted access rights to object 1 can include:

[0103] Authorization path 1: Subject 1 is granted operation 1 on object 1;

[0104] Authorization path 2: Subject 1 obtains subject 2 through the subject circumscription rule. Since subject 2 is granted operation 2 on object 2, subject 1 is granted operation 2 on object 2. When operation 2 obtains operation 1 through operation association and object 2 obtains object 1 through the object circumscription rule, subject 1 is granted operation 1 on object 1.

[0105] Figure 3B Shows a schematic diagram of another exemplary permission model 300 according to an embodiment of the present application.

[0106] Taking the example that a user needs to be granted access rights to work item instance data, as Figure 3B shown, the subjects in the permission model 300 can include users, departments, custom user groups, and space management user groups. The objects can include spaces, work item instance data sets, and work item instance data.

[0107] As Figure 3B shown, in some embodiments, a user can directly join a custom user group through subject diffusion rule 1. As an alternative embodiment, a user can also join a custom user group through subject diffusion rule 2 via the department where the user is located. In some embodiments, a user can join a department through subject diffusion rule 2-1 and then add the department to a custom user group through subject diffusion rule 2-2. When the user is a manager with a higher permission level, as Figure 3B shown, in some embodiments, a user can join the space management user group through subject diffusion rule 3.

[0108] As Figure 3B shown, in some embodiments, when the data stored in the entity type authorization table 2048 includes that the space management user group has the management operation of the space and the custom user group has the viewing operation of the work item instance data set, the users who join the custom user group can have the viewing permission of the work item instance data set, and the users who join the space management user group can have the management permission of the space.

[0109] As Figure 3BAs shown, in some embodiments, when the data stored in the entity operation relationship table 2022 includes having the [management operation of the space] and automatically having the [view operation of the work item instance data], the users added to the space management user group can have the management permission of the space and the view permission of the work item instance data. When the data stored in the entity operation relationship table 2022 includes having the [view operation of the work item instance data set], automatically having the [view operation of the work item instance data], and at the same time, through the object diffusion rule: a batch of work item instance data is demarcated by the BQL rule, the users added to the custom user group can have the view permission of the work item instance data set and can also have the view permission of the work item instance data demarcated by the BQL rule.

[0110] In this way, the authorization path for a user to be granted the access permission to the space can include:

[0111] Authorization path 1: User → Space management user group → Access permission to the space.

[0112] The authorization path for a user to be granted the access permission to the work item instance data can include:

[0113] Authorization path 1: User → Custom user group → Access permission to the work item instance data;

[0114] Authorization path 2: User → Department → Custom user group → Access permission to the work item instance data;

[0115] Authorization path 3: User → Space management user group → Access permission to the work item instance data.

[0116] Figure 4 The flowchart shows an exemplary permission granting method 400 according to an embodiment of the present application.

[0117] As Figure 4 shown, after adding the user identifier to the entity group, in some embodiments, the permission manager 116 can define the permissions to be granted to the entity group through the management terminal 114. For example, the custom user group identifier is granted the view permission of the work item instance data set, and the space management user group identifier is granted the management permission of the space.

[0118] In some embodiments, the management terminal 114 may receive a permission application request sent by a user. The permission manager 116 may send information about the permissions that need to be granted to an entity group, which is defined through the authorization interface of the permission service provided by the management terminal 114, to the permission management server 106. The permission management server 106 may obtain entity type authorization information according to the permission model 200. For example, the entity type authorization information may include an authorization path between a subject and an object related to an entity group identifier. For example, authorization path 1: Space management user group → Management permissions for the space; authorization path 2: Custom user group → Viewing permissions for the work item instance data set.

[0119] In some embodiments, after the permission management server 106 determines, according to the permission model 200, that there is an authorization path that can achieve authorization, it may write entity authorization data to the database 118.

[0120] In some embodiments, since the permission model 200 is constructed through metadata, after the permission manager 116 adds a user to an entity group, the management terminal 114 may display a Figure 3B permission relationship diagram as shown. By presenting the permission relationship in a visual manner, the permission manager 116 can know the permission scope corresponding to the entity group, so that the permission manager 116 can clearly know which permissions can be granted to the user.

[0121] Using the permission model 200, when the permission manager grants permissions to a user, by adding the user identifier to a user group, the permission management server 106 can determine the permission operations that the user group has according to the control logic in the permission model 200, and thus can determine the permissions that can be granted to the user. In this way, efficient management of user permissions by the permission manager is achieved.

[0122] Figure 5 FIG. shows a schematic flowchart of an exemplary resource access control method 500 according to an embodiment of the present application. The resource access control method 500 may be executed by the authentication terminal 110.

[0123] User 104 can send an access request for a target resource. The access request may include information such as the user identification of User 104, the target operation, the resource identification corresponding to the target resource, and the permission level identification. Taking User 104 as a manager as an example, after the authentication terminal 110 receives the access request sent by User 104 for the target resource, in some embodiments, it may determine the associated operation of the target operation according to the entity operation relationship table 2022 in the permission model 200 and the target operation, and determine the user group corresponding to the target user according to the associated operation. For example, the target operation may be a work item instance data viewing operation, and the authentication terminal 110 may determine the work item instance data set viewing operation and the space management operation associated with the viewing operation according to the entity operation relationship table 2022 in the permission model 200.

[0124] In some embodiments, the authentication terminal 110 may determine the access path according to the entity type authorization table 2048 in the permission model 200 and according to the associated operation. For example, the following access paths may be included:

[0125] Access path 1: The user group is granted the viewing permission for the work item instance data set;

[0126] Access path 2: The space management group is granted the management permission for the space;

[0127] Access path 3: The user joins the user group through the department, and the user group is granted the viewing permission for the work item instance data set.

[0128] Among them, the entity group type identification is included in the access path.

[0129] In this way, by determining the complete access path according to the permission model, the permission control logic of the entire system can be managed, and the problem of repeated authentication can be avoided. In addition, the access path determined from the permission model provides a basis for authentication. When data that does not belong to the access path appears during the authentication process of the authentication terminal, the data can be intercepted in a timely manner to avoid data security risks.

[0130] After determining the access path, in some embodiments, the authentication terminal 110 may, according to the access path and the user identifier, search in the permission data written back to the database for the entity group corresponding to the entity group type identifier in the access path. For example, the entity group type identifiers may be the user group type UserGroup and the space management group type ProjectAdminUserGroup. The authentication terminal 110 may find the user groups UserGroup1 and UserGroup2 corresponding to the user group type in the permission data, and may find the space management group ProjectAdminUserGroup1 corresponding to the space management group type. In this way, the authentication terminal 110 may determine the user group corresponding to the target user according to the access path and the user identifier.

[0131] When the user group is obtained by creating a target user group and a target department, adding the user identifier to the target department, and adding the target department to the target user group, the authentication terminal 110 may further, according to the access path 3, determine the department where the user identifier is located according to the user identifier, and determine the user group where the department is located, so as to determine all user groups according to the access path determined by the permission model 200, so as to avoid the risk of authentication failure caused by information omission.

[0132] After determining the user group, in some embodiments, the authentication terminal 110 may determine the access permission of the user group in the permission data in the database. The access permission of the user group includes the resource identifier that allows the user group to access. For example, the user group is granted the view operation of the work item instance data set, and the space management group is granted the management operation of the space. When the user group is not granted the access permission of the resource, the resource identifier corresponding to the user group cannot be determined in the permission data in the database.

[0133] According to the diffusion rule of the object, in some embodiments, the authentication terminal 110 may determine whether the resource identifier in the permission data in the database includes the resource identifier of the target resource, so as to determine the access permission of the target user. The resources granted permissions to user 104 may include multiple. After the authentication terminal 110 determines multiple accessible resources according to the resource identifier, it returns the resource corresponding to the identifier to the user terminal 102 according to the resource identifier of the target resource, so that user 104 can access the resources that the user needs to access.

[0134] When the merge rule of the authorization path (for example, pass if any passes or pass only if all pass) is defined in the rule domain 206, in some embodiments, the authentication terminal 110 may determine the target access path of the target resource according to the target operation, the resource identifier of the target resource, and the user identifier, and in response to the existence of multiple target access paths, determine whether the access permission of the target user can access the target resource according to the access policy (for example, the merge rule of the authorization path).

[0135] For example, when the access policy is defined as the first access policy (e.g., pass if any passes), in some embodiments, the authentication terminal 110 may determine whether the access permission of the target user can access the target resource according to the first access policy. In response to the access permission of the target user being that any one of multiple target access paths can access the target resource, the authentication terminal 110 may determine that the access permission of the target user can access the target resource.

[0136] When the access policy is defined as the second access policy (e.g., pass only if all pass), in some embodiments, the authentication terminal 110 may determine whether the access permission of the target user can access the target resource according to the second access policy. In response to the access permission of the target user being that each of multiple target access paths can access the target resource, the authentication terminal 110 may determine that the access permission of the target user can access the target resource.

[0137] In some embodiments, the access permission of the target user is obtained by creating a user group, adding the user identifier to the user group, obtaining an authorization path, and based on the user group and the authorization path.

[0138] The authentication terminal uses the permission model 200 for permission management. The authentication terminal can determine the permission operations owned by the user group according to the control logic in the permission model 200, so as to determine whether there is the permission data of the user to be authenticated in the permission data written in the database. This realizes the efficient management of permissions by the authentication terminal. At the same time, according to the access path determined in the permission model, the authentication terminal can intercept the data that does not belong to this access path in a timely manner, improving the security and stability of the system.

[0139] Figure 6 FIG. shows a schematic flowchart of an exemplary resource access control method 600 according to an embodiment of the present application. The method 600 may be implemented by the system 100 (e.g., Figure 1 the system 100 in Figure 1 ). More specifically, the method 600 may be executed by the authentication terminal 110 (e.g.,

[0140] In step 602, receive an access request of a target user (e.g., Figure 1 the user 104 in

[0141] for a target resource, where the access request includes the user identifier of the target user.

[0142] In some embodiments, the user group is obtained by creating a target user group and a target department, adding the user identifier to the target department, and adding the target department to the target user group.

[0143] In some embodiments, the access request further includes a target operation. Determining the user group corresponding to the target user includes: determining an associated operation of the target operation; and determining the user group corresponding to the target user according to the associated operation and the user identifier.

[0144] In some embodiments, determining the user group corresponding to the target user according to the associated operation includes: determining an access path according to the associated operation; and determining the user group corresponding to the target user according to the access path and the user identifier.

[0145] In some embodiments, further determining the user group corresponding to the target user according to the access path and the user identifier includes: determining the department or team corresponding to the target user according to the access path and the user identifier; and determining the user group corresponding to the target user according to the department or the team. This can determine all user groups according to the access path and avoid the risk of authentication failure caused by information omission.

[0146] In step 606, determine the access permission of the target user according to the user group.

[0147] In some embodiments, further determining the access permission of the target user according to the user group includes: determining the access permission of the user group, where the access permission of the user group includes a resource identifier that allows the user group to access; and determining whether the resource identifier includes the resource identifier of the target resource to determine the access permission of the target user.

[0148] In step 608, in response to the access permission of the target user being able to access the target resource, return the information of the target resource corresponding to the access permission of the target user.

[0149] In some embodiments, the method further includes: determining a target access path of the target resource according to the target operation, the resource identifier of the target resource, and the user identifier; and in response to there being multiple target access paths, determining whether the access permission of the target user can access the target resource according to an access policy.

[0150] In some embodiments, the access policy includes a first access policy. Further, determining whether the access permission of the target user can access the target resource according to the access policy includes: in response to the first access policy, determining whether the access permission of the target user can access the target resource according to the first access policy; and in response to the access permission of the target user being able to access the target resource through any one of the multiple target access paths, determining that the access permission of the target user can access the target resource.

[0151] In some embodiments, the access policy includes a second access policy. Further, determining whether the access permission of the target user can access the target resource according to the access policy includes: in response to the second access policy, determining whether the access permission of the target user can access the target resource according to the second access policy; and in response to the access permission of the target user being able to access the target resource through each of the multiple target access paths, determining that the access permission of the target user can access the target resource.

[0152] In some embodiments, the access permission of the target user is obtained by creating a user group, adding the user identifier to the user group, and obtaining an authorization path, and based on the user group and the authorization path.

[0153] In some embodiments, the access permission of the target user is controlled by a permission model. The permission model includes an entity domain, an authorization relationship domain, a rule domain, and an entity group domain. Among them, the entity domain is used to define the entities, object operations, and operation associations of the permission model; the authorization relationship model is used to define the authorization relationships between the main and object entities of the permission model; the rule domain is used to define the diffusion rules of the entities of the permission model; the entity group domain is used to define the diffusion data of the entities of the permission model. By constructing a permission model using metadata and configuring the control logic of the permission model, the permission control requirements of different systems can be adapted. In this way, different systems can reuse the permission model, avoiding the problem of repeated development of the permission model.

[0154] In some embodiments, the entity domain includes an entity type table, an entity operation table, and an entity operation relationship table, the rule domain includes a rule table and a rule relationship table, the authorization relationship domain includes an entity type authorization table, an authorized association rule table, and an entity type authorization wide table, and the permission model is obtained based on the entity type table, the entity operation table, the entity operation relationship table, the rule table, the rule relationship table, the entity type authorization table, the authorized association rule table, and the entity type authorization wide table. By using metadata to construct a permission model and configure the control logic of the permission model, the permission control requirements of different systems can be met. In this way, different systems can reuse the permission model, avoiding the problem of duplicate development of the permission model.

[0155] In some embodiments, the entity group domain includes an entity group table and an entity group service attribute table, and the target user access permission is obtained based on the user identifier and the permission model, where the permission model is obtained based on the entity group table and the entity group service attribute table. In this way, the entity group domain can abstract the aggregation relationship of entities into entity groups, thereby reducing the complexity of granting permissions to users. For example, when a new user needs to be added, only the metadata model of the entity group of the user needs to be added for permission management.

[0156] A resource access control method, device, electronic device, storage medium, and product provided by the present application. The method includes: receiving an access request of a target user for a target resource, where the access request includes the user identifier of the target user, determining the user group corresponding to the target user according to the user identifier, determining the access permission of the target user according to the user group, and in response to the access permission of the target user being able to access the target resource, returning the information of the target resource corresponding to the access permission of the target user. The efficient management of user permissions in a project management system can be achieved by the method of managing user access permissions based on user groups.

[0157] It should be noted that the method of the embodiments of the present application can be executed by a single device, such as a computer or a server. The method of this embodiment can also be applied to a distributed scenario and completed by multiple devices cooperating with each other. In the case of such a distributed scenario, one of the multiple devices can only execute one or more steps of the method of the embodiments of the present application, and these multiple devices will interact with each other to complete the described method.

[0158] It should be noted that some embodiments of the present application have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the above embodiments and still achieve the desired results. Additionally, the processes depicted in the figures do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0159] Based on the same inventive concept, corresponding to any of the above-described method embodiments, the present application further provides a resource access control device 700.

[0160] Referring to Figure 7 , the resource access control device 700 includes:

[0161] A receiving module 702, configured to receive an access request from a target user for a target resource, where the access request includes a user identifier of the target user.

[0162] A first determination module 704, configured to determine a user group corresponding to the target user according to the user identifier.

[0163] Wherein, the user group is obtained by creating a target user group and a target department, adding the user identifier to the target department, and adding the target department to the target user group.

[0164] The access request further includes a target operation. The first determination module 704 is further configured to determine an associated operation of the target operation; and determine a user group corresponding to the target user according to the associated operation and the user identifier.

[0165] The first determination module 704 is further configured to determine an access path according to the associated operation; and determine a user group corresponding to the target user according to the access path and the user identifier.

[0166] The first determination module 704 is further configured to determine a department or team corresponding to the target user according to the access path and the user identifier; and determine a user group corresponding to the target user according to the department or the team.

[0167] A second determination module 706, configured to determine an access permission of the target user according to the user group.

[0168] The second determination module 706 is further configured to determine an access permission of the user group, where the access permission of the user group includes a resource identifier that allows the user group to access; and determine whether the resource identifier includes the resource identifier of the target resource to determine the access permission of the target user.

[0169] A return module 708, configured to return information about the target resource corresponding to the access permission of the target user in response to the access permission of the target user being able to access the target resource.

[0170] The apparatus 700 may further include a determination module, configured to determine a target access path of the target resource according to the target operation, a resource identifier of the target resource, and the user identifier; and in response to there being multiple target access paths, determine whether the access permission of the target user can access the target resource according to an access policy.

[0171] The access policy includes a first access policy, and the determination module is further configured to, in response to the first access policy, determine whether the access permission of the target user can access the target resource according to the first access policy; and in response to the access permission of the target user being able to access the target resource through any one of the multiple target access paths, determine that the access permission of the target user can access the target resource.

[0172] The access policy includes a second access policy, and the determination module is further configured to, in response to the second access policy, determine whether the access permission of the target user can access the target resource according to the second access policy; and in response to the access permission of the target user being able to access the target resource through each of the multiple target access paths, determine that the access permission of the target user can access the target resource.

[0173] Wherein, the access permission of the target user is obtained by creating a user group, adding the user identifier to the user group, obtaining an authorization path, and according to the user group and the authorization path.

[0174] Wherein, the access permission of the target user is controlled by a permission model, and the permission model includes an entity domain, an authorization relationship domain, a rule domain, and an entity group domain; wherein, the entity domain is used to define entities, object operations, and operation associations of the permission model; the authorization relationship model is used to define the authorization relationship between the main and object entities of the permission model; the rule domain is used to define the diffusion rules of the entities of the permission model; and the entity group domain is used to define the diffusion data of the entities of the permission model.

[0175] Among them, the entity domain includes an entity type table, an entity operation table, and an entity operation relationship table; the rule domain includes a rule table and a rule relationship table; the authorization relationship domain includes an entity type authorization table, an authorized association rule table, and an entity type authorization wide table; and the permission model is obtained based on the entity type table, the entity operation table, the entity operation relationship table, the rule table, the rule relationship table, the entity type authorization table, the authorized association rule table, and the entity type authorization wide table.

[0176] Among them, the entity group domain includes an entity group table and an entity group service attribute table; the target user access permission is obtained based on a user identifier and the permission model; and the permission model is obtained based on the entity group table and the entity group service attribute table.

[0177] For the sake of convenience of description, when describing the above device, various modules are separately described according to their functions. Of course, when implementing the present application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0178] The device in the above embodiment is used to implement the corresponding method 600 in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be elaborated herein.

[0179] Based on the same technical concept, corresponding to the method in any of the above embodiments, the present application further provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, it implements the method 600 described in any of the above embodiments.

[0180] Figure 8 The figure shows a schematic diagram of an exemplary electronic device according to an embodiment of the present application. The device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. Among them, the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are communicatively connected to each other inside the device through the bus 1050.

[0181] The processor 1010 may be implemented in a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, etc., and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present specification.

[0182] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, etc. The memory 1020 can store an operating system and other application programs. When implementing the technical solutions provided in the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 1020 and called and executed by the processor 1010.

[0183] The input / output interface 1030 is used to connect to the input / output module to achieve information input and output. The input / output module can be configured as a component in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Among them, the input devices can include keyboards, mice, touchscreens, microphones, various sensors, etc., and the output devices can include displays, speakers, vibrators, indicator lights, etc.

[0184] The communication interface 1040 is used to connect to the communication module (not shown in the figure) to achieve communication interaction between this device and other devices. Among them, the communication module can achieve communication through wired means (such as USB, network cable, etc.) or through wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0185] The bus 1050 includes a path for transmitting information between the various components of the device (such as the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040).

[0186] It should be noted that although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, this device may also include other components necessary for normal operation. In addition, those skilled in the art can understand that the above device may also only include the components necessary to implement the solutions of the embodiments of this specification, and do not necessarily include all the components shown in the figure.

[0187] The electronic device in the above embodiment is used to implement the corresponding method 600 in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0188] Based on the same technical concept, corresponding to the method in any of the above embodiments, the present application also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the method 600 as described in any of the foregoing embodiments.

[0189] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device.

[0190] The computer instructions stored in the storage medium of the above embodiment are used to cause the computer to execute the method 600 described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0191] Based on the same inventive concept, corresponding to the method 600 described in any of the above embodiments, the present application also provides a computer program product, including computer program instructions, which when run on a computer, cause the computer to execute the method 600 described in any of the above embodiments. In some embodiments, the computer program instructions can be executed by one or more processors of the computer to cause the computer and / or the processor to execute the method 600. Corresponding to the execution subjects corresponding to the respective steps in the method 600, the processors executing the corresponding steps can belong to the corresponding execution subjects.

[0192] The computer program product of the above embodiment is used to cause the computer and / or the processor to execute the method 600 described in any of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0193] Those of ordinary skill in the art should understand that: the discussion of any of the above embodiments is only exemplary and is not intended to imply that the scope of the present application (including the claims) is limited to these examples; under the concept of the present application, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations in different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of brevity.

[0194] In addition, for simplicity of explanation and discussion, and in order not to make the embodiments of the present application difficult to understand, well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Further, the devices may be shown in block diagram form in order to avoid making the embodiments of the present application difficult to understand, and this also takes into account the fact that details of the implementation of these block diagram devices are highly dependent on the platform on which the embodiments of the present application are to be implemented (i.e., these details should be entirely within the understanding of those skilled in the art). In cases where specific details (such as circuits) are set forth to describe exemplary embodiments of the present application, it will be apparent to those skilled in the art that the embodiments of the present application may be practiced without these specific details or with variations of these specific details. Accordingly, these descriptions should be considered illustrative rather than restrictive.

[0195] Although the present application has been described in connection with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures (such as dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0196] Embodiments of the present application are intended to cover all such alternatives, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the embodiments of the present application shall be included within the protection scope of the present application.

Claims

1. A resource access control method, comprising: Receiving an access request from a target user for a target resource, the access request including a user identifier of the target user; Determining a user group corresponding to the target user according to the user identifier; Determining access rights of the target user according to the user group; In response to the target user's access rights being able to access the target resource, returning information about the target resource corresponding to the target user's access rights; The target user's access rights are controlled by a rights model, the rights model includes an entity group field, the entity group field includes an entity group table and an entity group business attribute table, the target user's access rights are obtained according to a user identifier and the rights model, wherein the rights model is obtained according to the entity group table and the entity group business attribute table; The entity group table defines an entity group identifier and the entity group to which the entity group identifier belongs, and the entity group business attribute table defines the Chinese name of the entity group identifier.

2. The method of claim 1, wherein: The access request also includes a target operation, and the determining the user group corresponding to the target user includes: Determining an associated operation of the target operation; A user group corresponding to the target user is determined according to the association operation and the user identifier.

3. The method of claim 2, wherein: Determining, according to the association operation, a user group corresponding to the target user, including: Determine an access path according to the association operation; A user group corresponding to the target user is determined according to the access path and the user identifier.

4. The method of claim 3, wherein: The determining the user group corresponding to the target user according to the access path and the user identifier further comprises: Determine the department or team corresponding to the target user according to the access path and the user identifier; According to the department or the team, a user group corresponding to the target user is determined.

5. The method of claim 1, wherein: Determining the access rights of the target user according to the user group further includes: Determining the access rights of the user group, wherein the access rights of the user group include resource identifiers that the user group is allowed to access; It is determined whether the resource identifier includes the resource identifier of the target resource to determine the access rights of the target user.

6. The method of claim 2, wherein: The method further comprises: Determining a target access path for the target resource according to the target operation, the resource identifier of the target resource and the user identifier; In response to the existence of a plurality of target access paths, it is determined according to an access policy whether the target user's access rights can access the target resource.

7. The method of claim 6, wherein: The access policy includes a first access policy, and determining whether the target user's access rights can access the target resource according to the access policy further includes: In response to the first access policy, determining whether the target user's access rights are sufficient to access the target resource according to the first access policy; In response to the target user's access permission being able to access the target resource through any one of the plurality of target access paths, it is determined that the target user's access permission is able to access the target resource.

8. The method of claim 6, wherein: The access policy includes a second access policy, and determining whether the target user's access rights can access the target resource according to the access policy further includes: In response to the second access policy, determining whether the target user's access rights are sufficient to access the target resource according to the second access policy; In response to the target user's access rights being able to access the target resource through each of the plurality of target access paths, it is determined that the target user's access rights are able to access the target resource.

9. The method of claim 1, wherein: The access rights of the target user are obtained by creating a user group and adding the user identifier to the user group, obtaining an authorization path, and obtaining the authorization path based on the user group and the authorization path.

10. The method of claim 1, wherein: The user group is obtained by creating a target user group and a target department, adding the user identifier to the target department, and adding the target department to the target user group.

11. The method of claim 1, wherein: The permission model also includes an entity field, an authorization relationship field and a rule field; Wherein, the entity domain is used to define the entity, object operation and operation association of the permission model; The authorization relationship model is used to define the authorization relationship between the subject and object of the permission model; The rule field is used to define the diffusion rules of the entities of the permission model; The entity group field is used to define the diffusion data of the entities of the permission model.

12. The method of claim 11, wherein: The entity domain includes an entity type table, an entity operation table and an entity operation relationship table, the rule domain includes a rule table and a rule relationship table, the authorization relationship domain includes an entity type authorization table, an authorization association rule table and an entity type authorization wide table, and the permission model is obtained based on the entity type table, the entity operation table, the entity operation relationship table, the rule table, the rule relationship table, the entity type authorization table, the authorization association rule table and the entity type authorization wide table.

13. A resource access control device, comprising: A receiving module, configured to receive an access request from a target user for a target resource, wherein the access request includes a user identifier of the target user; A first determination module is configured to determine a user group corresponding to the target user according to the user identifier; A second determination module is configured to determine the access rights of the target user according to the user group; A returning module, configured to return information of the target resource corresponding to the access rights of the target user in response to the target user being able to access the target resource with the access rights of the target user; The target user's access rights are controlled by a rights model, the rights model includes an entity group field, the entity group field includes an entity group table and an entity group business attribute table, the target user's access rights are obtained according to a user identifier and the rights model, wherein the rights model is obtained according to the entity group table and the entity group business attribute table; The entity group table defines an entity group identifier and the entity group to which the entity group identifier belongs, and the entity group business attribute table defines the Chinese name of the entity group identifier.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the method according to any one of claims 1 to 12 is implemented.

15. A non-transitory computer-readable storage medium storing computer instructions, wherein: The computer instructions are used to make a computer execute the method according to any one of claims 1 to 12.

16. A computer program product, wherein: The method comprises computer program instructions, which, when executed on a computer, cause the computer to execute the method according to any one of claims 1 to 12.

Images