Methods, apparatus, electronic devices and readable storage media for generating authentication requests

Abstract

This disclosure provides a method, apparatus, electronic device, and readable storage medium for generating authentication requests, relating to the field of computer technology, and particularly to the field of cloud computing technology. The specific implementation scheme is as follows: In response to receiving a resource access request for a target resource, the system obtains account information of a first account and a second account carried in the resource access request, where the first account is the account initiating the resource request, and the second account is the account to which the target resource belongs; based on the account information of the first account, the system determines the first root account to which the first account belongs, and based on the account information of the second account, the system determines the second root account to which the second account belongs; based on the first and second root accounts, the system determines the cross-root account access status of the resource access request; based on the cross-root account access status, the system generates an authentication request for the resource access request. This scheme can generate corresponding authentication requests based on cross-root account access status, which helps to achieve effective management of cross-cloud account resource access.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to the field of cloud computing technology. Specifically, this disclosure relates to a method, apparatus, electronic device, and readable storage medium for generating authentication requests. Background Technology

[0002] With the rise of cloud computing, more and more users are starting to use the services provided by intelligent cloud.

[0003] Resources under different cloud accounts on the intelligent cloud are isolated from each other. However, in reality, there may be a need to access resources across cloud accounts. Therefore, how to effectively manage resource access across cloud accounts has become an important technical problem in the field of cloud computing. Summary of the Invention

[0004] To address at least one of the aforementioned deficiencies, this disclosure provides a method, apparatus, electronic device, and readable storage medium for generating authentication requests.

[0005] According to a first aspect of this disclosure, a method for generating an authentication request is provided, the method comprising:

[0006] In response to receiving a resource access request for a target resource, the system obtains the account information of the first account and the account information of the second account carried in the resource access request. The first account is the account that initiated the resource request, and the second account is the account to which the target resource belongs.

[0007] Based on the account information of the first account, determine the first root account to which the first account belongs, and based on the account information of the second account, determine the second root account to which the second account belongs;

[0008] Based on the first root account and the second root account, determine the cross-root account access status of resource access requests;

[0009] Based on cross-root account access, an authentication request is generated for resource access requests.

[0010] According to a second aspect of this disclosure, an authentication request generation apparatus is provided, the apparatus comprising:

[0011] The account information acquisition module is used to respond to a resource access request for a target resource by acquiring the account information of a first account and a second account carried in the resource access request. The first account is the account that initiated the resource request, and the second account is the account to which the target resource belongs.

[0012] The root account determination module is used to determine the first root account to which the first account belongs based on the account information of the first account, and to determine the second root account to which the second account belongs based on the account information of the second account.

[0013] The cross-root account access determination module is used to determine the cross-root account access status of resource access requests based on the first root account and the second root account.

[0014] The authentication request generation module is used to generate authentication requests for resource access requests based on cross-root account access information.

[0015] According to a third aspect of this disclosure, an electronic device is provided, the electronic device comprising:

[0016] At least one processor; and

[0017] A memory communicatively connected to at least one of the aforementioned processors; wherein,

[0018] The memory stores instructions that can be executed by at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the authentication request generation method.

[0019] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause a computer to execute the above-described method for generating an authentication request.

[0020] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described method for generating an authentication request.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0022] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0023] Figure 1 This is a flowchart illustrating a method for generating an authentication request according to an embodiment of this disclosure;

[0024] Figure 2 This is a schematic diagram of the process of matching authentication parameters with the permissions of entries in the ACL, provided by an embodiment of this disclosure.

[0025] Figure 3 This is a schematic diagram of a process for processing authentication requests provided in an embodiment of this disclosure;

[0026] Figure 4 This is a schematic diagram of a tag-based permission policy creation process provided in an embodiment of this disclosure;

[0027] Figure 5 This is a schematic diagram of a process for binding resources to tags provided in an embodiment of this disclosure;

[0028] Figure 6 This is a schematic diagram of an authentication process based on a tag-based permission policy provided in an embodiment of this disclosure;

[0029] Figure 7 This is a schematic diagram of a permission policy creation process based on resource groups provided in an embodiment of this disclosure;

[0030] Figure 8 This is a schematic diagram of a resource creation process provided in an embodiment of this disclosure.

[0031] Figure 9 This is a schematic diagram of an authentication process based on a resource group permission policy provided in an embodiment of this disclosure;

[0032] Figure 10 This is a schematic diagram of the structure of an authentication request generation device provided in an embodiment of this disclosure;

[0033] Figure 11 This is a block diagram of an electronic device used to implement the authentication request generation method of the embodiments of this disclosure. Detailed Implementation

[0034] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0035] First, let's introduce and explain several terms used in this application:

[0036] Multi-user access control (IAM) addresses the issues of identity management for cloud accounts and access control for cloud resources. Essentially, it's a security management service used to manage access permissions to resources.

[0037] An access control list (ACL) is a list of permissions that is attached to a user role or resource. An ACL is a list consisting of one or more entries.

[0038] Resources under different cloud accounts on an intelligent cloud are isolated from each other. However, in reality, there may be a need to access resources across cloud accounts. For example, resources under cloud account A and cloud account B are independent of each other, but cloud account A may need to access resources under cloud account B. How to effectively manage cloud account A's access to resources under cloud account B has a significant impact on the security of those resources. Therefore, how to effectively manage cross-cloud account resource access has become a crucial technical problem in the field of cloud computing.

[0039] The authentication request generation method, apparatus, electronic device, and readable storage medium provided in this disclosure are intended to solve at least one of the above-mentioned technical problems of the prior art.

[0040] Figure 1 This illustration shows a flowchart of a method for generating an authentication request according to an embodiment of the present disclosure, as shown below. Figure 1 As shown, the method can mainly include:

[0041] Step S110: In response to receiving a resource access request for the target resource, obtain the account information of the first account and the account information of the second account carried in the resource access request. The first account is the account that initiated the resource request, and the second account is the account to which the target resource belongs.

[0042] Step S120: Based on the account information of the first account, determine the first root account to which the first account belongs, and based on the account information of the second account, determine the second root account to which the second account belongs;

[0043] Step S130: Based on the first root account and the second root account, determine the cross-root account access status of the resource access request;

[0044] Step S140: Based on cross-root account access information, generate an authentication request for the resource access request.

[0045] The target resource can be a cloud resource on the intelligent cloud. An account on the intelligent cloud can isolate the cloud resources within that account.

[0046] The intelligent cloud platform has a master account and sub-accounts. The master account has management permissions for all resources within it. Under the management of the master account, sub-accounts can share or collaborate on cloud resources.

[0047] The first and second accounts can be the main accounts on the intelligent cloud.

[0048] The first account can be a sub-account under the first root account or the first root account itself; the second account can be a sub-account under the second account or the second account itself.

[0049] In this embodiment of the disclosure, when the first account has an access requirement for the target resource, it can initiate a resource access request for the target resource. The resource access request generally carries the account information of the requesting account (i.e., the account information of the first account) and the account information of the resource owner account (i.e., the account information of the second account).

[0050] In intelligent cloud, a list of accounts and the relationships between them are typically stored. Therefore, based on the account information of the first account, the first root account to which the first account belongs can be determined, and based on the account information of the second account, the second root account to which the second account belongs can be determined.

[0051] As an example, account information can be an account identifier (ID).

[0052] After identifying the first and second root accounts, the root accounts of the request initiating account and the resource owner account are determined. Based on the first and second root accounts, the cross-root account access situation of the resource access request can be determined.

[0053] Resource access requests can be categorized into two types: cross-root account access and non-cross-root account access. Cross-root account access occurs when the resource requested is not under the root account of the requesting account, but under a different root account. Non-cross-root account access occurs when the resource requested is under the same root account as the requesting account.

[0054] In this embodiment of the disclosure, a corresponding authentication request can be generated based on the cross-root account access situation, so that an appropriate authentication processing method can be adopted for the authentication request, thus providing a basis for effective authentication when accessing resources across root accounts.

[0055] The method provided in this disclosure, upon receiving a resource access request for a target resource, obtains account information of a first account and a second account carried in the resource access request. The first account is the account initiating the resource request, and the second account is the account to which the target resource belongs. Based on the account information of the first account, the first root account to which the first account belongs is determined, and based on the account information of the second account, the second root account to which the second account belongs is determined. Based on the first and second root accounts, the cross-root account access status of the resource access request is determined. Based on the cross-root account access status, an authentication request for the resource access request is generated. Based on this solution, a corresponding authentication request can be generated according to the cross-root account access status, providing a foundation for subsequent effective authentication based on the authentication request, and facilitating effective management of cross-cloud account resource access.

[0056] In one alternative embodiment of this disclosure, after generating the authentication request for the resource access request, the method further includes:

[0057] Process the authentication request and determine the authentication result.

[0058] In this embodiment of the disclosure, after generating the authentication request, the authentication request can be processed to obtain the authentication result, thereby determining the first account's permissions to the target resource.

[0059] Specifically, the permission policy corresponding to the first account can be obtained, and the authentication request can be processed based on the permission policy.

[0060] In this embodiment of the disclosure, authentication services can be provided based on multi-user access control (Identity and Access Management, IAM) to process authentication requests.

[0061] In one optional approach of this disclosure, an authentication request for resource access is generated based on cross-root account access information, including:

[0062] Based on the authentication parameters carried in the resource access request, an initial authentication request is generated, which includes placeholders.

[0063] The initial authentication request is processed based on cross-root account access information to obtain the authentication request for resource access.

[0064] In this embodiment of the disclosure, the resource access request may carry authentication parameters, and an authentication request is generated based on the authentication parameters, so that authentication can be achieved based on the authentication parameters when processing the authentication request.

[0065] Authentication parameters can be used for fine-grained control over permissions. As an example, authentication parameters may include, but are not limited to, cloud service type, permission type, resource identifier, and related condition parameters. Related condition parameters may include, but are not limited to, the time the access was initiated, the Internet Protocol (IP) address used to initiate the access, whether a virtual network was used, and whether Hypertext Transfer Protocol Secure (HTTPS) or Secure Sockets Layer (SSL) was used.

[0066] Resource access requests can be categorized into two types: cross-root account access and cross-root account access. The fields in the authentication request may differ between these two scenarios. By providing placeholders in the initial authentication request, appropriate fields can be added based on the different cross-root account access scenarios, thus meeting the actual needs of the authentication request in both scenarios.

[0067] In this embodiment of the disclosure, by providing placeholders, the authentication request statements for both cross-root account access scenarios can be written using only one set of syntax. This eliminates the need for developers to design two separate syntaxes for the request statements in each scenario, thus improving development efficiency. Furthermore, providing a single syntax facilitates the parsing of the authentication request statements, improving the processing efficiency of subsequent authentication steps.

[0068] In one optional approach of this disclosure, in response to the fact that the first root account and the second root account are not the same account, and cross-root account access is detected, the initial authentication request is processed based on the cross-root account access situation to obtain an authentication request for the resource access request, including:

[0069] Obtain the real account information of the second root account;

[0070] Add the real account information to the placeholders of the initial authentication request to obtain the authentication request for resource access.

[0071] In this embodiment of the disclosure, when the first root account and the second root account are not the same account, the resource access request cross-root account access situation is considered to have cross-root account access.

[0072] In this embodiment of the disclosure, when processing authentication requests, it is necessary to obtain the permission policy. The permission policy is configured for sub-accounts by the root account. The permission policy is generally stored in association with the account information of the root account that configured it. Therefore, based on the account information of the root account, the permission policy configured by that root account can be retrieved for processing authentication requests. For example, root account C configures permission policies c1 and c2 for sub-account c. Permission policies c1 and c2 are stored in association with the account identifier of root account C, and permission policies c1 and c2 can be retrieved based on the account identifier of root account C.

[0073] When a resource access request involves cross-root account access, although the initial authentication request includes the resource owner's account information (i.e., the second account's account information), due to the independence of each root account in the intelligent cloud, the resource owner's account information in the resource access request initiated by the first account may not be the actual account information of the resource owner. Since the permission policy is generally stored in association with the actual account information of the root account that configures the permission policy, the actual account information of the second root account can be obtained and added to the placeholder position to obtain the authentication request for the resource access request. At this time, the authentication request contains the actual account information of the second account, which makes it convenient to obtain the permission policy based on the actual account information of the second account to realize the processing of the authentication request.

[0074] As an example, the intelligent cloud can provide a query interface for resource owners, which can query the real account information of the second root account based on the resource identifier of the target resource.

[0075] In one optional approach disclosed herein, processing the authentication request and determining the authentication result includes:

[0076] Based on the real account information carried in the authentication request, query the permission policy of the second cross-root account corresponding to the second root account;

[0077] The authentication result is determined based on the second cross-root account permission policy.

[0078] In this embodiment of the disclosure, when a resource access request involves cross-root account access, the generated authentication request carries the real account information of the second root account.

[0079] The master account can be used to configure permission policies for sub-accounts, so that user permissions to resources can be determined based on the permission policies.

[0080] In scenarios involving cross-root account resource access, the resource-owning account can configure cross-root account permission policies for sub-users of other root accounts to control access permissions when sub-users of other root accounts access resources under this root account.

[0081] In this embodiment of the disclosure, the second cross-root account permission policy can be a cross-root account permission policy configured through the second root account.

[0082] Account permission policies can be stored in a database and are associated with the real account information of the main account. Therefore, based on the real account information of the second root account, the permission policy of the second cross-root account corresponding to the second root account can be queried, and the authentication result can be determined based on the permission policy of the second cross-root account.

[0083] In one optional approach of this disclosure, in response to the first root account having a corresponding first cross-root account permission policy, the authentication result is determined based on the second cross-root account permission policy, including:

[0084] The authentication result is determined based on the second cross-root account permission policy and the first cross-root account permission policy.

[0085] In this embodiment of the disclosure, for cross-root account resource access scenarios, the main account can also configure cross-root account permission policies for its sub-accounts to access resources under other root accounts. The first cross-root account permission policy is the cross-root account permission policy configured through the first root account.

[0086] In this embodiment of the disclosure, when both the root account to which the request initiating account belongs (i.e., the first root account) and the root account of the resource holder (i.e., the second root account) are configured with cross-root account permission policies for the first account, sub-authentication results can be determined based on the second cross-root account permission policy and the first cross-root account permission policy, respectively, and then the final authentication result can be determined based on the two sub-authentication results.

[0087] As an example, the first account has access to the target resource only when the sub-authentication result based on the second cross-root account permission policy is that the user has access rights, and the sub-authentication result based on the first cross-root account permission policy is also that the user has access rights.

[0088] In scenarios involving cross-root account resource access, where resource security requirements are high, ensuring that the first account only has access to the target resource when both sub-authentication results are valid for access rights can better guarantee resource security.

[0089] As an example, permission policies can exist in the form of ACLs, with each permission policy corresponding to one ACL.

[0090] ACLs include user-based ACLs and resource-based ACLs.

[0091] User-based ACLs are used to add accounts or account groups to specific permission policies, specifying the permissions this role has for different resources. When a request arrives, authentication is performed by iterating through the list of permissions attached to the account or account group.

[0092] Resource-based ACLs are used to specify the applicable permission policy when a resource is created, and to specify the permissions for different users in the permission policy description. When a user requests a resource, the permission policy associated with the resource is obtained, and the permission descriptions in the permission policy are traversed for authentication.

[0093] In this embodiment of the disclosure, the second cross-root account permission policy can be a Resource-based ACL, and the first cross-root account permission policy can be a User-based ACL.

[0094] In one optional approach of this disclosure, in response to the first root account and the second root account being the same account, and the cross-root account access situation being that there is no cross-root account access, the initial authentication request is processed based on the cross-root account access situation to obtain an authentication request for the resource access request, including:

[0095] The initial authentication request is defined as an authentication request for resource access.

[0096] In this embodiment of the disclosure, when the first root account and the second root account are the same account, the resource access request cross-root account access situation is that there is no cross-root account access, that is, resource access under the same root account.

[0097] Since resources are accessed under the same root account, the account information of the resource owner account included in the initial authentication request (i.e., the account information of the second account) is the real account information. Therefore, the initial authentication request can be left unprocessed, and the placeholders can be retained. In this case, the initial authentication request is determined to be the authentication request.

[0098] In one optional approach disclosed herein, processing the authentication request and determining the authentication result includes:

[0099] Query the permission policies of the same root account corresponding to the first root account;

[0100] The authentication result is determined based on the same root account permission policy.

[0101] In this embodiment of the disclosure, the root account permission policy is the permission policy configured by the resource owner account for its sub-users, so as to realize permission control when the sub-users access resources under the root account.

[0102] Account permission policies can be stored in a database and are associated with the real account information of the main account. Therefore, based on the account information of the first root account, the permission policy of the corresponding root account can be queried, and the authentication result can be determined based on the permission policy of the root account.

[0103] In this embodiment of the disclosure, the root account permission policy may be either a User-based ACL or a Resource-based ACL. When both User-based ACL and Resource-based ACL coexist, sub-authentication results can be determined based on the User-based ACL and Resource-based ACL respectively, and then the final authentication result can be determined based on the two sub-authentication results.

[0104] As an example, if either the sub-authentication result based on User-based ACL or the sub-authentication result based on Resource-based ACL indicates that the user has access rights, then it can be determined that the first account has access rights to the target resource.

[0105] In one alternative embodiment of this disclosure, after determining the authentication result, the above method further includes:

[0106] In response to the authentication result indicating that the first account has access to the target resource, determine at least one parent resource of the target resource;

[0107] Grant the first account access rights to the parent resource.

[0108] In this embodiment of the disclosure, cloud resources in the intelligent cloud can exist in the form of resource groups, and there is a hierarchical relationship within the resource groups. Specifically, the resource group is a tree structure, where the parent node is the parent resource and the child nodes are the child resources.

[0109] In this embodiment of the disclosure, the implementation of the sub-resource may depend on the parent resource. When the first account has access to the target resource, in order to ensure the successful invocation of the target resource by the first account, the parent resources at all levels of the target resource can be authorized to the first account.

[0110] In one alternative approach of this disclosure, determining at least one parent resource of the target resource includes:

[0111] Obtain the complete resource path of the target resource carried in the authentication request, the complete resource path including the resource identifier of at least one parent resource of the target resource;

[0112] Determine at least one parent resource of the target resource based on the complete resource path.

[0113] In this embodiment of the disclosure, to facilitate the identification of the target resource's parent resources, the complete resource path of the target resource can be carried in the authentication request, thereby determining the parent resources at each level of the target resource based on the complete resource path. The complete resource path is the complete link from the root group in the resource group to the group to which the target resource belongs.

[0114] As an example, the complete resource path of the target resource is: x / y / z, where x, y, and z are all resource identifiers. The resource identifier of the target resource is z. The complete resource path shows the resource identifiers of the parent resources of the target resource as y and x, respectively. Therefore, the parent resources at each level of the target resource can be determined based on the complete resource path.

[0115] As an example, this disclosure provides an intelligent cloud resource access control system, which includes:

[0116] The Create Permission Policy module is used to create permission policies. The created permission policies can include custom permission policies based on policy syntax, tag permission policies, and resource group permission policies.

[0117] The policy storage and parsing module is used to cache and persist permission policies.

[0118] The authentication module of the permission policy is used to provide an authentication interface and process authentication requests.

[0119] This example demonstrates how to develop a permission policy syntax for writing ACL entries. The permission policy creation module in this example provides four modes for creating permission policies: 1. Create by policy generator, 2. Create by tag, 3. Create by resource group, and 4. Create by policy syntax.

[0120] The permission policy creation module in this example can provide a policy generator. An example of creating a permission policy based on the policy generator is as follows: (1) Select cloud service from the drop-down list; (2) Provide a policy generator mode according to the cloud service type, select check mode, or edit policy file form, handwritten mode; (3) Then select permission effectiveness; (4) Then select permission type; (5) Select resource, you can select specific resources or all resources; (6) Finally select filter conditions, the filter conditions include the time of access, the IP address of the access, the source of the access, whether to enable HTTPS / SSL protocol, and whether to use virtual network.

[0121] In this example, when creating a strategy based on tags, you can select tags to manage permissions for a group of resources.

[0122] By having the main user group resources by tags in advance, and then creating corresponding tag authorizations for each resource group, new resources can be tagged when they are created later.

[0123] In this example, when creating a policy based on tags, you can select resource groups to manage the permissions of a group of resources. Resource groups are tree-structured, and resources at child nodes in the authorization tree automatically inherit the policies of resources at parent nodes.

[0124] Resources can be grouped using the main account, and then corresponding resource group authorizations can be created for each resource group. When creating new resources later, new resources can be added to the resource groups.

[0125] Creating policies using policy syntax, which means writing your own permission policies according to the permission policy syntax, is a very flexible way to create policies.

[0126] In the policy storage and parsing module, the created permission policies and the permission policies that users are authorized to use can be stored in the database.

[0127] The authentication process in the authentication module of the permission policy can mainly include: the cloud service receives a resource access request for the target resource, obtains authentication parameters from the context of the resource access request (i.e., the request body), generates an authentication request based on the authentication parameters, and sends the authentication request to IAM.

[0128] IAM performs authentication, retrieves the list of authorized ACLs previously configured for the requesting account, matches it with the authentication parameters, and obtains and returns the authentication result and user identity information.

[0129] Cloud product services decide whether to execute the user's requested operation based on the authentication result.

[0130] Authentication parameters can include authentication information and the context of the resource access request.

[0131] The authentication information specifically includes the token or authorization character for the resource access request, as well as the request content. The authentication information is used to authenticate the security of the interface.

[0132] The context of a resource access request includes the following parts:

[0133] The service field identifies the requested service.

[0134] Region field: Identifies the geographic region of the requested service.

[0135] Resource field: Used to identify the path of a resource within the service.

[0136] The resource_owner field identifies the resource owner account of the requested resource. This field contains placeholders to be added to the actual resource owner account when accessing resources across root accounts.

[0137] The permission field identifies the list of operation permissions corresponding to the resource access request.

[0138] Context field: Used to identify other contexts, including the request source IP, requester, resource tag, resource group information, virtual network identifier, etc.

[0139] When performing tag-based authentication, the authentication request should include the tag information of the resource. Specifically, a tag object is added to the context part of the authentication request. The tag object can be in the form of a key-value (KV) pair. If there are multiple pairs, they can be added separately.

[0140] When authenticating resource groups, the authentication request should include the resource group information. This resource group information can be the complete link from the root group to the group to which the resource belongs. During resource group authorization, once a resource in a subgroup is authorized, authorization can be automatically routed to its parent groups.

[0141] The overall authentication process provided in this example is as follows: For each authentication request of a service, IAM obtains the authentication parameters in the authentication request, matches them with all entries in the ACL, and obtains the final authentication result by combining the matching results.

[0142] Matching authentication parameters with permissions in an ACL entry can result in three outcomes: explicit denial (expl ici t deny), allow access (al low), and default denial (defaul t deny). The matching priority is: explicit denial > all low, and all low > default denial.

[0143] As an example, Figure 2 The diagram illustrates a process for matching authentication parameters with permissions of entries in an ACL, as provided in an embodiment of this disclosure.

[0144] like Figure 2 As shown, the policy is matched against the request, that is, the entries in the ACL are matched against the authentication parameters in the authentication request. If `expl ici t deny` exists in the matching results, `expl ici t deny` can be returned directly, and the authentication result is access denied. If `expl ici t deny` does not exist in the matching results, matching can be performed again to determine if `al low` exists in the matching results. If it exists, `al low` can be returned directly, and the authentication result is access allowed. If `al low` does not exist in the matching results, matching can be performed again. If no entry matches successfully, `defaul t deny` can be returned directly, and the request is denied by default.

[0145] As an example, Figure 3 The diagram illustrates a flowchart of an authentication request processing method provided by an embodiment of this disclosure.

[0146] like Figure 3 As shown, the user acquisition strategy, i.e. the user authorization strategy, is used to match the authentication parameters.

[0147] The authentication process checks whether the service matches the cloud product, specifically by matching the service field in the authentication parameters with the service field of the cloud service in the authorization policy. If no match is found, the authentication process stops and access is denied. If a match is found, subsequent matching processes can proceed.

[0148] The authentication process checks if the region matches the geographic area; that is, it matches the region field in the authentication parameters with the region field in the authorization policy. If no match is found, the authentication process stops and access is denied. If a match is found, the subsequent matching process can proceed.

[0149] The authentication process checks whether the resource matches the resource information, that is, it matches the resource field in the authentication parameters with the resource field in the authorization policy. If no match is found, the authentication process stops and access is denied. If a match is found, the subsequent matching process can proceed.

[0150] The authentication process checks whether the permission information matches the authorization information, specifically by matching the permission field in the authentication parameters with the permission field in the authorization policy. If no match is found, the authentication process stops, and access is denied. If a match is found, subsequent matching processes can proceed.

[0151] The authentication process checks whether the grantees contain user authorization information, which involves matching the grantees field in the authentication parameters with the grantees field in the authorization policy. If no match is found, the authentication process stops and access is denied. If a match is found, the subsequent matching process can proceed.

[0152] The authentication process validates conditions, including tags, time, IP address, and resource group information. Specifically, it matches the conditions field in the authentication parameters against the conditions field in the authorization policy. This includes matching tags, access time, access IP address, and resource group. If no match is found, the authentication process stops and access is denied. If a match is found, authentication is considered successful.

[0153] As an example, there may be a situation where both resource ACLs and user ACLs exist in the permission policy. In this example, the IAM authentication policy is that for resource access requests under the same root account, access is allowed as long as either ACL or user ACL is approved.

[0154] For resource access requests that cross root accounts, access will only be granted if the root account of the initiating account (via user ACL) grants permission, and the root account of the resource (via resource ACL) also grants access.

[0155] As an example, Figure 4 This is a schematic diagram of a tag-based permission policy creation process provided in this embodiment of the disclosure.

[0156] like Figure 4 As shown, the product console, or cloud product console provided by the intelligent cloud, is used to control cloud services. The business backend refers to the owner of the resources.

[0157] The primary account administrator can select tags and authorize them (i.e., create tag permission policies) through the IAM console. The IAM console can list tags through the tag service. After completing the tag authorization, the tag permission policy can be stored in the IAM backend.

[0158] As an example, Figure 5 This is a schematic diagram of a process for binding resources to tags, provided as an embodiment of the present disclosure.

[0159] like Figure 5 As shown, a sub-user can request the creation of a resource from the product console, specifying the resource's tag. The business backend sends the created resource's tag to the IAM backend for authentication. If authentication is successful, the business backend can process the resource and actually bind the resource to the tag through the tag service.

[0160] As an example, Figure 6 This is a schematic diagram of an authentication process based on a tag-based permission policy, provided as an embodiment of the present disclosure.

[0161] like Figure 6 As shown, sub-users can initiate resource requests through the product console. The product console sends the request to the business backend, which queries the tag service for tags and initiates authentication with IAM along with the tags.

[0162] As an example, Figure 7 This is a schematic diagram of a permission policy creation process based on resource groups, provided in an embodiment of this disclosure.

[0163] like Figure 7As shown, the primary account can configure resource groups through the resource console and store the resource groups in the resource group backend. The IAM console can select resource group authorization, that is, create the permission policy for the resource group, and then save the permission policy of the resource group to the IAM backend.

[0164] As an example, Figure 8 This is a schematic diagram illustrating a resource creation process provided in an embodiment of this disclosure.

[0165] like Figure 8 As shown, a sub-user can request the creation of a resource from the product console and specify the resource group to which the resource belongs. The product console can then request the product backend to create the resource. The product backend can then authenticate with IAM by sending the resource group information. If authentication is successful, the product backend can create the resource and bind it to the resource group.

[0166] As an example, Figure 9 This is a schematic diagram of an authentication process based on a resource group permission policy, provided as an embodiment of the present disclosure.

[0167] like Figure 9 As shown, the sub-user initiates an operation request for the resource to the product backend through the product console. The product backend queries the resource group to which the resource belongs, and then sends the resource group information to IAM for authentication.

[0168] This embodiment also supports high-performance authentication. A vast number of permission policies may exist on the intelligent cloud, resulting in a huge volume of authentication requests. The IAM in this example can support authentication with extremely high traffic.

[0169] In this example, IAM stores all ACLs in a remote dictionary server (Redis). When an ACL is updated, the cache can be proactively invalidated. ACLs are divided into different geographic regions for separate caching, and the updated ACLs are delivered to all geographic regions via a message queue. In this example, the `redis->mGET` command can be used to request cached data in batches. For certain target accounts, the context information needed for authentication can be cached in the in-process Least Recently Used (LRU) cache for faster response times.

[0170] This public implementation provides tag-based authentication and resource group authentication, enabling flexible and adaptive authentication. This significantly improves the convenience and flexibility of cloud tenants managing resource permissions, while also offering high-performance authentication capable of supporting authentication across extremely high traffic volumes. Details are as follows:

[0171] Tags and resource groups allow for the management of authorization for a type of resource, such as virtual machines (VMs), their required virtual networks, public IP addresses, and cloud storage disks. These resources typically expire simultaneously and require unified management. Tags and resource groups enable unified authorization and management. After enterprise tenants authorize tags and resource groups, they only need to add the resources to the tags and resource groups to automatically obtain permissions.

[0172] By leveraging multi-level caching capabilities and designing cache data structures, the authentication performance of cloud products can be significantly improved, thereby supporting authentication requests for billions of requests.

[0173] Based on and Figure 1 The method shown follows the same principle. Figure 10 A schematic diagram of an authentication request generation apparatus provided in an embodiment of this disclosure is shown, as follows: Figure 10 As shown, the authentication request generation device 1000 may include:

[0174] The account information acquisition module 1010 is used to respond to receiving a resource access request for a target resource, and to acquire the account information of the first account and the account information of the second account carried in the resource access request. The first account is the account that initiated the resource request, and the second account is the account to which the target resource belongs.

[0175] The root account determination module 1020 is used to determine the first root account to which the first account belongs based on the account information of the first account, and to determine the second root account to which the second account belongs based on the account information of the second account.

[0176] The cross-root account access determination module 1030 is used to determine the cross-root account access status of resource access requests based on the first root account and the second root account.

[0177] The authentication request generation module 1040 is used to generate authentication requests for resource access requests based on cross-root account access information.

[0178] The apparatus provided in this disclosure, upon receiving a resource access request for a target resource, obtains account information of a first account and a second account carried in the resource access request. The first account is the account initiating the resource request, and the second account is the account to which the target resource belongs. Based on the account information of the first account, it determines the first root account to which the first account belongs, and based on the account information of the second account, it determines the second root account to which the second account belongs. Based on the first and second root accounts, it determines the cross-root account access status of the resource access request. Based on the cross-root account access status, it generates an authentication request for the resource access request. Based on this scheme, it can generate corresponding authentication requests according to the cross-root account access status, providing a foundation for subsequent effective authentication based on the authentication requests, and facilitating effective management of cross-cloud account resource access.

[0179] Optionally, the above-mentioned device further includes:

[0180] The authentication result determination module is used to process the authentication request after generating the authentication request for resource access and determine the authentication result.

[0181] Optionally, the authentication request generation module is specifically used for:

[0182] Based on the authentication parameters carried in the resource access request, an initial authentication request is generated, which includes placeholders.

[0183] The initial authentication request is processed based on cross-root account access information to obtain the authentication request for resource access.

[0184] Optionally, in response to the first root account and the second root account not being the same account, indicating cross-root account access, the authentication request generation module, when processing the initial authentication request based on the cross-root account access situation to obtain the authentication request for the resource access request, specifically uses the following:

[0185] Obtain the real account information of the second root account;

[0186] Add the real account information to the placeholders of the initial authentication request to obtain the authentication request for resource access.

[0187] Optionally, the authentication result determination module is specifically used for:

[0188] Based on the real account information carried in the authentication request, query the permission policy of the second cross-root account corresponding to the second root account;

[0189] The authentication result is determined based on the second cross-root account permission policy.

[0190] Optionally, in response to the first root account having a corresponding first cross-root account permission policy, the authentication result determination module, when determining the authentication result based on the second cross-root account permission policy, specifically performs the following:

[0191] The authentication result is determined based on the second cross-root account permission policy and the target first cross-root account permission policy.

[0192] Optionally, if the first root account and the second root account are the same account, and cross-root account access is not possible, the authentication request generation module, when processing the initial authentication request based on the cross-root account access situation to obtain the authentication request for the resource access request, is specifically used for:

[0193] The initial authentication request is defined as an authentication request for resource access.

[0194] Optionally, the authentication result determination module is specifically used for:

[0195] The authentication request is processed, and the authentication result is determined, including:

[0196] Query the permission policies of the same root account corresponding to the first root account;

[0197] The authentication result is determined based on the same root account permission policy.

[0198] Optionally, the above apparatus further includes a parent resource licensing module, which is used for:

[0199] After determining the authentication result, in response to the authentication result indicating that the first account has access to the target resource, determine at least one parent resource of the target resource;

[0200] Grant the first account access rights to the parent resource.

[0201] Optionally, when determining at least one level parent resource of the target resource, the parent resource authorization module is specifically used for:

[0202] Obtain the complete resource path of the target resource carried in the authentication request, the complete resource path including the resource identifier of at least one parent resource of the target resource;

[0203] Determine at least one parent resource of the target resource based on the complete resource path.

[0204] It is understood that the above-described modules of the authentication request generation apparatus in the embodiments of this disclosure have the ability to implement... Figure 1The embodiments shown illustrate the functionality of the corresponding steps in the authentication request generation method. This functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described functionality. These modules can be software and / or hardware, and each module can be implemented individually or integrated from multiple modules. For a detailed description of the functionality of each module in the authentication request generation device, please refer to [link to relevant documentation]. Figure 1 The corresponding description of the authentication request generation method in the illustrated embodiments will not be repeated here.

[0205] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0206] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0207] The electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform an authentication request generation method as provided in the embodiments of this disclosure.

[0208] Compared with existing technologies, this electronic device, upon receiving a resource access request for a target resource, obtains account information of a first account and a second account carried in the resource access request. The first account is the account initiating the resource request, and the second account is the account to which the target resource belongs. Based on the account information of the first account, it determines the first root account to which the first account belongs, and based on the account information of the second account, it determines the second root account to which the second account belongs. Based on the first and second root accounts, it determines the cross-root account access status of the resource access request. Based on the cross-root account access status, it generates an authentication request for the resource access request. This solution can generate corresponding authentication requests based on cross-root account access status, providing a foundation for subsequent effective authentication based on the authentication requests, and facilitating effective management of cross-cloud account resource access.

[0209] The readable storage medium is a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the authentication request generation method provided in the embodiments of this disclosure.

[0210] Compared with existing technologies, this readable storage medium, in response to a received resource access request for a target resource, obtains account information of a first account and a second account carried in the resource access request. The first account is the account initiating the resource request, and the second account is the account to which the target resource belongs. Based on the account information of the first account, it determines the first root account to which the first account belongs, and based on the account information of the second account, it determines the second root account to which the second account belongs. Based on the first and second root accounts, it determines the cross-root account access status of the resource access request. Based on the cross-root account access status, it generates an authentication request for the resource access request. This solution can generate corresponding authentication requests based on cross-root account access status, providing a foundation for subsequent effective authentication based on the authentication requests, and facilitating effective management of cross-cloud account resource access.

[0211] The computer program product includes a computer program that, when executed by a processor, implements a method for generating authentication requests as provided in embodiments of this disclosure.

[0212] Compared with existing technologies, this computer program product, upon receiving a resource access request for a target resource, obtains account information of a first account and a second account carried in the resource access request. The first account is the account initiating the resource request, and the second account is the account to which the target resource belongs. Based on the account information of the first account, it determines the first root account to which the first account belongs, and based on the account information of the second account, it determines the second root account to which the second account belongs. Based on the first and second root accounts, it determines the cross-root account access status of the resource access request. Based on the cross-root account access status, it generates an authentication request for the resource access request. This solution can generate corresponding authentication requests based on cross-root account access status, providing a foundation for subsequent effective authentication based on the authentication requests, and facilitating effective management of cross-cloud account resource access.

[0213] Figure 11 A schematic block diagram of an example electronic device 1100 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0214] like Figure 11As shown, the electronic device 1100 includes a computing unit 1110, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 1120 or a computer program loaded from a storage unit 1180 into a random access memory (RAM) 1130. The RAM 1130 may also store various programs and data required for the operation of the device 1100. The computing unit 1110, ROM 1120, and RAM 1130 are interconnected via a bus 1140. An input / output (I / O) interface 1150 is also connected to the bus 1140.

[0215] Multiple components in device 1100 are connected to I / O interface 1150, including: input unit 1160, such as keyboard, mouse, etc.; output unit 1170, such as various types of monitors, speakers, etc.; storage unit 1180, such as disk, optical disk, etc.; and communication unit 1190, such as network card, modem, wireless transceiver, etc. Communication unit 1190 allows device 1100 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0216] The computing unit 1110 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1110 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1110 executes the authentication request generation method provided in the embodiments of this disclosure. For example, in some embodiments, executing the authentication request generation method provided in the embodiments of this disclosure can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 1180. In some embodiments, part or all of the computer program can be loaded and / or installed on device 1100 via ROM 1120 and / or communication unit 1190. When the computer program is loaded into RAM 1130 and executed by the computing unit 1110, one or more steps of the authentication request generation method provided in the embodiments of this disclosure can be performed. Alternatively, in other embodiments, the computing unit 1110 may be configured by any other suitable means (e.g., by means of firmware) to perform the authentication request generation method provided in the embodiments of this disclosure.

[0217] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0218] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0219] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0220] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0221] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0222] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0223] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0224] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for generating an authentication request, comprising: in response to receiving a resource access request for a target resource, obtaining account information of a first account and account information of a second account carried by the resource access request, the first account being an account initiating the resource access request, and the second account being an account to which the target resource belongs; determining a first root account to which the first account belongs based on the account information of the first account, and determining a second root account to which the second account belongs based on the account information of the second account; determining a cross-root account access condition of the resource access request based on the first root account and the second root account; generating an authentication request for the resource access request based on the cross-root account access condition, comprising: generating an initial authentication request based on an authentication parameter carried in the resource access request, the initial authentication request including a placeholder; in response to the first root account and the second root account not being the same account, the cross-root account access condition being cross-root account access, obtaining real account information of the second root account; adding the real account information to the placeholder of the initial authentication request to obtain the authentication request for the resource access request.

2. The method of claim 1, wherein, After the authentication request for the resource access request is generated, the method further comprises: processing the authentication request to determine an authentication result.

3. The method of claim 2, wherein, Processing the authentication request to determine an authentication result, comprising: querying a second cross-root account permission policy corresponding to the second root account based on the real account information carried in the authentication request; determining an authentication result based on the second cross-root account permission policy.

4. The method of claim 3, wherein, In response to the first root account being preconfigured with a corresponding first cross-root account permission policy, determining an authentication result based on the second cross-root account permission policy, comprising: determining an authentication result based on the second cross-root account permission policy and the first cross-root account permission policy.

5. The method of any one of claims 2-4, after determining an authentication result, the method further comprising: in response to the authentication result being that the first account has access permission to the target resource, determining at least one parent resource of the target resource; authorizing the first account with access permission to the parent resource.

6. The method of claim 5, wherein, The determination of at least one parent resource of the target resource, comprising: obtaining a complete resource path of the target resource carried in the authentication request, the complete resource path including resource identifiers of at least one parent resource of the target resource; determining at least one parent resource of the target resource based on the complete resource path.

7. An apparatus for generating an authentication request, comprising: an account information obtaining module configured to, in response to receiving a resource access request for a target resource, obtain account information of a first account and account information of a second account carried by the resource access request, the first account being an account initiating the resource access request, and the second account being an account to which the target resource belongs; a root account determination module, configured to determine a first root account to which the first account belongs based on account information of the first account, and determine a second root account to which the second account belongs based on account information of the second account; a cross-root account access condition determination module, configured to determine a cross-root account access condition of the resource access request based on the first root account and the second root account; an authentication request generation module, configured to generate an authentication request for the resource access request based on the cross-root account access condition; wherein the authentication request generation module is specifically configured to: generate an initial authentication request based on an authentication parameter carried in the resource access request, the initial authentication request including a placeholder; in response to the first root account and the second root account not being the same account, the cross-root account access condition being cross-root account access existing, obtain real account information of the second root account; add the real account information to the placeholder of the initial authentication request to obtain the authentication request for the resource access request.

8. The apparatus of claim 7, further comprising: an authentication result determination module, configured to, after the authentication request for the resource access request is generated, process the authentication request to determine an authentication result.

9. The apparatus of claim 8, wherein, The authentication result determination module is specifically configured to: query a second cross-root account permission policy corresponding to the second root account based on real account information carried in the authentication request; determine an authentication result based on the second cross-root account permission policy.

10. The apparatus of claim 9, wherein, In response to the first root account being preconfigured with a corresponding first cross-root account permission policy, the authentication result determination module, when determining the authentication result based on the second cross-root account permission policy, is specifically configured to: determine the authentication result based on the second cross-root account permission policy and the first cross-root account permission policy.

11. An electronic device, comprising: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

12. A non-transitory computer readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable the computer to perform the method of any one of claims 1-6.

13. A computer program product comprising a computer program which, when executed by a processor, implements the method of any one of claims 1-6.

Images