Microservice access control method and apparatus, system, device, medium and product

Abstract

This application discloses a microservice access control method, apparatus, system, device, medium, and product. The method includes: receiving a microservice access request sent by a requester, the microservice access request carrying an authentication token; verifying the authentication token, and generating a valid authorization token corresponding to the microservice access request based on the authentication token; sending the microservice access request and the valid authorization token to the corresponding target microservice; the first service is an internal service of the application and corresponds to a microservice within the application. This access control method, employing external application authentication plus internal access permission authorization, achieves secure access control over the application's internal environment and shields the requester from authorization information and processes. The access control granularity is refined to the access request level; if a security issue occurs in the authorization of a single microservice access request, it will not affect other microservice access requests, thus improving the security of microservice access control.

Description

Technical Field

[0001] This application relates to cloud-native technologies, and more particularly to a microservice access control method, apparatus, system, device, medium, and product. Background Technology

[0002] With the development of cloud-native technologies, microservices have emerged. Microservices divide an application into multiple independent, collaborative microservices, achieving effects such as shortening application development cycles, enhancing elasticity and scalability, and simplifying maintenance based on a distributed deployment architecture. While microservices offer these advantages, they also introduce new security challenges. Applications developed using microservices increase their security exposure, and if a single microservice is compromised, attackers can move laterally between microservices, impacting the security of other microservices and increasing the overall security risk of the application.

[0003] In related technologies, the security of microservices is typically enhanced by setting security boundaries for authenticating and authorizing access requests. For example, current mainstream microservice access control schemes include Role-Based Access Control (RBAC) and Open Authorization (OAuth2). RBAC manages access control in a centralized manner, assigning "roles" to requesters and granting them specific access permissions to control access to microservice resources. OAuth2 returns access permissions as tokens to requesters, who then use these tokens to access the corresponding microservice resources. Specifically, security boundaries are typically set at the application's external boundary or at the boundaries of individual microservices within the application.

[0004] However, if access control is implemented through security boundaries set at the application and external boundaries, there is a lack of secure access control over the application's internal environment. If access control is implemented through security boundaries set at the microservice boundaries, each microservice needs to set up its own authentication and authorization mechanism, which increases the difficulty of microservice deployment. In related technologies, because authentication and authorization are handled centrally, some permissions are exposed to the requester during the authentication and authorization process, posing a risk of unauthorized access. Furthermore, the granularity of access control is at the user or role level, so if unauthorized access occurs in a single microservice, the security risk will immediately affect other microservices. Summary of the Invention

[0005] In view of this, embodiments of this application provide a microservice access control method, apparatus, system, device, medium, and product, aiming to improve the security of microservice access control.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] In a first aspect, embodiments of this application provide a microservice access control method applied to a first service, the method comprising:

[0008] Receive a microservice access request sent by the requester, the microservice access request carrying an authentication token;

[0009] After verifying the authentication token, a valid authorization token corresponding to the microservice access request is generated based on the authentication token.

[0010] Send the microservice access request and the valid authorization token to the corresponding target microservice;

[0011] The first service is an internal service of the application and corresponds to a microservice within the application.

[0012] In the above scheme, generating a valid authorization token corresponding to the microservice access request based on the authentication token includes:

[0013] Based on the identity information of the requester carried by the authentication token, obtain the authorization token corresponding to the cached microservice access request;

[0014] Based on the validity period information carried by the cached authorization token, determine whether the cached authorization token is valid;

[0015] If the cached authorization token is determined to be valid, then the cached authorization token shall be used as the valid authorization token corresponding to the microservice access request;

[0016] If it is determined that the cached authorization token has expired, the cached authorization token is updated based on the current runtime environment parameters of the target microservice, and the updated authorization token is used as the valid authorization token corresponding to the microservice access request.

[0017] The method in the above scheme further includes:

[0018] Obtain the current runtime environment parameters of the target microservice, which include one or more of the following: CPU utilization, memory utilization, I / O frequency, and request access frequency;

[0019] The step of updating the cached authorization token based on the current runtime environment parameters of the target microservice includes:

[0020] Based on the current runtime environment parameters of the target microservice and the weights corresponding to each runtime environment parameter, calculate the incremental permission information of the requester;

[0021] Based on the calculated incremental information of each permission and the permission information carried by the cached hand token, update the cached authorization token;

[0022] The permission information includes at least the validity period information.

[0023] In the above scheme, obtaining the cached authorization token corresponding to the microservice access request based on the identity information of the requester carried by the authentication token includes:

[0024] Based on the identity information of the requester, determine whether to cache the authorization token corresponding to the microservice access request;

[0025] If it is determined that the corresponding authorization token is not cached, an authorization token request is sent to the second service. The authorization token request carries at least the identity information of the requester and the target microservice information.

[0026] Receive and cache the corresponding authorization token sent by the second service;

[0027] The second service is an external service of the application.

[0028] Secondly, embodiments of this application provide a microservice access control method applied to a second service, the method comprising:

[0029] Receive authentication requests sent by the requesting party;

[0030] Based on the authentication request, after confirming that the requester's identity has been successfully authenticated, an authentication token is generated;

[0031] Send the authentication token to the requester;

[0032] The authentication token is used to request access to any microservice within the application; the second service is an external service of the application.

[0033] In the above scheme, the step of generating an authentication token after confirming that the requester's identity authentication is successful includes:

[0034] After confirming that the requester's identity authentication is successful, a preset identity information mapping table is queried based on the user ID of the requester carried in the authentication request;

[0035] Based on the identity information of the requester obtained from the query, an authentication token carrying the identity information is generated.

[0036] In the above scheme, the method further includes:

[0037] Receive an authorization token request sent by the first service, wherein the authorization token request carries at least the identity information of the requester and the target microservice information;

[0038] Based on the identity information of the requester and the target microservice information, a preset access permission table is queried to determine the corresponding permission information and generate an authorization token;

[0039] Send the authorization token to the first service;

[0040] The first service is an internal service of the application and corresponds to a microservice within the application; the authorization token carries at least the permission information.

[0041] Thirdly, embodiments of this application provide a microservice access control device applied to a first service, the microservice access control device comprising:

[0042] The first receiving module is used to receive a microservice access request sent by the requester, wherein the microservice access request carries an authentication token;

[0043] The first generation module is used to verify the authentication token and then obtain a valid authorization token corresponding to the microservice access request based on the authentication token.

[0044] The first sending module is used to send the microservice access request and the valid authorization token to the corresponding target microservice;

[0045] The first service is an internal service of the application and corresponds to a microservice within the application.

[0046] Fourthly, embodiments of this application provide a microservice access control device applied to a second service, the microservice access control device comprising:

[0047] The second receiving module is used to receive authentication requests sent by the requester;

[0048] The second generation module is used to generate an authentication token after determining that the identity authentication of the requester has passed based on the authentication request.

[0049] The second sending module is used to send the authentication token to the requester;

[0050] The authentication token is used to request access to any microservice within the application; the second service is an external service of the application.

[0051] Fifthly, embodiments of this application provide a microservice access control system, including a second service and at least one first service;

[0052] Wherein, the first service is an internal service of the application and corresponds to a microservice within the application, used to perform the steps of the method as described in the first aspect;

[0053] The second service is an external service of the application, used to perform the steps of the method as described in the second aspect.

[0054] In a sixth aspect, embodiments of this application provide a network device, including: a processor and a memory for storing a computer program capable of running on the processor, wherein the processor, when running the computer program, performs the steps of the methods described in the first and second aspects.

[0055] In a seventh aspect, embodiments of this application provide a storage medium storing a computer program, which, when executed by a processor, implements the steps of the methods described in the first and second aspects.

[0056] Eighthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the methods described in the first and second aspects.

[0057] The microservice access control method provided in this application embodiment is applied to a first service. The method includes: receiving a microservice access request sent by a requester, the microservice access request carrying an authentication token; verifying the authentication token, and generating a valid authorization token corresponding to the microservice access request based on the authentication token; sending the microservice access request and the valid authorization token to the corresponding target microservice; wherein the first service is an internal service of the application and corresponds to a microservice within the application. Thus, this application embodiment separates the identity authentication and access permission authorization functions, adopting an access control method that combines external application identity authentication with internal access permission authorization. This achieves secure access control of the application's internal environment and shields the requester from authorization information and processes, effectively preventing unauthorized access attacks. The access control granularity is refined to the access request level, issuing authorization tokens for individual microservice access requests. If a security issue occurs in the authorization of a single microservice access request, it will not affect other microservice access requests, thus improving the security of microservice access control. Attached Figure Description

[0058] Figure 1 This is a schematic diagram of the structure of the microservice access control system according to an embodiment of this application;

[0059] Figure 2 This is a flowchart illustrating a microservice access control method according to an embodiment of this application;

[0060] Figure 3 This is a flowchart illustrating another embodiment of a microservice access control method according to this application;

[0061] Figure 4 This is a schematic diagram of the structure of a microservice access control system in an application example of this application;

[0062] Figure 5 This is a flowchart illustrating a microservice access method in an application example of this application;

[0063] Figure 6 This is a schematic diagram of the structure of a microservice access control device according to an embodiment of this application;

[0064] Figure 7 This is a schematic diagram of the structure of a microservice access control device according to another embodiment of this application;

[0065] Figure 8 This is a schematic diagram of the network device according to an embodiment of this application. Detailed Implementation

[0066] The present application will now be described in further detail with reference to the accompanying drawings and embodiments.

[0067] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0068] Before describing the microservice access control method provided in the embodiments of this application, the microservice control system used to execute the microservice control method will be described in detail first.

[0069] This application provides a microservice access control system, such as... Figure 1 As shown, the system includes a second service 200 and at least one first service 100. The first service 100 is an internal service of the application and corresponds to a microservice within the application. The second service 200 is an external service of the application.

[0070] Here, the application is developed and deployed based on a microservice architecture, with one or more microservices deployed inside the application; the first service 100 is deployed inside the application and corresponds one-to-one with the microservices inside the application, that is, the number of first services 100 deployed inside the application is the same as the number of microservices; the second service 200 is deployed outside the application.

[0071] It should be noted that both the first service 100 and the second service 200 are used for microservice access control. Microservice access control specifically includes requester authentication and access permission authorization. After the microservice access control system determines that the requester's authentication is successful and the access permission is authorized, the requester can access the corresponding microservice. Specifically, in this embodiment, the first service 100 is used to perform access control on requesters and / or microservice access requests to access the corresponding microservice, and the second service 200 performs access control on requesters and / or microservice access requests to access any microservice within the application.

[0072] In this embodiment, the first service 100 specifically refers to all access control services deployed within the application and related to the corresponding microservice. In some embodiments, the first service 100 includes a request management service and a local authorization service. The second service 200 specifically refers to all access control services deployed outside the application and related to the application. In some embodiments, the second service 200 includes an authentication service and a central authorization service. In this embodiment, the internal functional division of the first service 100 and the second service 200 is not specifically limited.

[0073] It's important to note that in related technologies, microservice access control systems are typically set at the boundary between the application and the external environment, employing a centralized approach for access control management. For example, RBAC authenticates the requester, assigns a "role" to the requester, and grants specific access permissions to that "role" to achieve microservice access control. However, this centralized access control approach sets the security boundary at the application's external boundary, lacking secure access control over the application's internal environment. Because authentication and authorization are handled centrally, some permissions are exposed to the requester during the authentication and authorization process, posing a risk of unauthorized access. Attackers can easily bypass the authentication and authorization process and access the application's internal systems. Furthermore, since access control granularity is at the user or role level, if unauthorized access occurs in a single microservice, the security risk will immediately affect other microservices.

[0074] Therefore, to address the aforementioned technical problems, the microservice access control system in this application separates the authentication and access permission authorization functions, employing an access control method that combines external authentication with internal access permission authorization to enhance the security of microservice access control. Specifically, a second service deployed outside the application is used to authenticate the requester, while a first service deployed inside the application is used to authorize access permissions for microservice access requests.

[0075] This application provides a microservice access control method, applied to a first service, such as... Figure 2 As shown, the method includes:

[0076] Step 201: Receive the microservice access request sent by the requester. The microservice access request carries an authentication token.

[0077] Step 202: After verifying the authentication token, generate a valid authorization token corresponding to the microservice access request based on the authentication token.

[0078] Step 203: Send the microservice access request and a valid authorization token to the corresponding target microservice.

[0079] The first service is an internal service of the application and corresponds to a microservice within the application.

[0080] Here, authentication tokens and authorization tokens can be JWTs (JSON Web Tokens). JWTs are self-contained and lightweight, and are commonly used for authentication and authorization. Here, the authentication token signifies that the requester's identity has been successfully authenticated, carrying at least the requester's identity information. Specifically, the authentication token is issued by the second service; that is, after the requester's identity is authenticated by the second service, it sends a microservice access request to the first service corresponding to the target microservice.

[0081] Understandably, after receiving a microservice access request, the first service verifies the validity and integrity of the authentication token carried in the microservice access request. If the verification is successful, it generates a corresponding valid authorization token. The valid authorization token carries at least the permission information corresponding to the microservice access request. The first service then assembles the microservice access request and the valid authorization token and sends them to the target microservice. After receiving the microservice access request, the target microservice verifies the validity of the valid authorization token and responds to the microservice access request if the verification is successful.

[0082] It is understood that, in this embodiment of the application, the microservice access control related service (first service) deployed inside the application is only used to authorize microservice access requests and not to authenticate the requester's identity. The first service is simple to deploy and shields the requester from authorization information and process, effectively preventing unauthorized access attacks. The access control granularity is refined to the access request level, and authorization tokens are issued for individual microservice access requests. When a security problem occurs in the authorization of a single microservice access request, it will not affect other microservice access requests, thus improving the security of microservice access control.

[0083] For example, generating a valid authorization token corresponding to a microservice access request based on an authentication token includes: obtaining a cached authorization token corresponding to the microservice access request based on the requester's identity information carried in the authentication token; determining whether the cached authorization token is valid based on the validity period information carried in the cached authorization token; if the cached authorization token is valid, using it as the valid authorization token for the microservice access request; if the cached authorization token has expired, updating it based on the current runtime environment parameters of the target microservice, and using the updated authorization token as the valid authorization token for the microservice access request. For example, obtaining a cached authorization token corresponding to a microservice access request based on the requester's identity information carried in the authentication token includes: determining whether the authorization token corresponding to the microservice access request is cached based on the requester's identity information; if the corresponding authorization token is not cached, sending an authorization token request to a second service, the authorization token request carrying at least the requester's identity information and the target microservice information; receiving and caching the corresponding authorization token sent by the second service. Here, the second service is an external service of the application.

[0084] Here, the requester's identity information includes at least a user ID and a role ID. The user ID is the unique identifier of the requester, and the role ID is the identity identifier assigned by the microservice access control system when setting different access permissions for the same requester. That is, a user ID can correspond to one or more role IDs. Based on the requester's identity information, the permission information corresponding to the target microservice can be queried.

[0085] Here, the target microservice information can be a unique identifier for the target microservice, such as the target microservice name.

[0086] Understandably, due to the large amount of identity information of the requester, storing the permission information in the first service would greatly increase the difficulty of deploying the first service inside the application. In this embodiment, the microservice access control system stores the request permission information in a second service outside the application. The first service obtains an authorization token carrying the corresponding permission information by sending an authorization token request to the second service. In order to simplify the authorization process, the first service caches the corresponding authorization token obtained and generated based on the identity information of the requester. When the first service receives a microservice access request, if it determines that the corresponding authorization token has been cached based on the identity information of the requester, it directly calls the cached authorization token to generate the corresponding valid authorization token, so as to avoid repeatedly requesting the corresponding authorization token from the second service.

[0087] It should be noted that in related technologies, access permissions for requesters to access microservices are typically set statically. That is, when a microservice access request is received, the microservice access control system calls a preset access permission table to determine the corresponding access permissions for the requester and grant authorization. However, due to the frequent resource consumption and short-term concurrency of microservice operation, if a static access permission setting scheme is adopted, it is difficult to adjust the access permissions accordingly when the microservice environment changes, and it cannot adapt to the rapidly changing lifecycle of the microservice environment. This application embodiment takes into account the needs of microservice operation scenarios and implements dynamic management of access permissions. Specifically, by setting validity period information for authorization tokens to limit the validity of access permissions, and determining that the authorization token expires, the authorization token is updated based on the current operating environment parameters of the target microservice to achieve dynamic management of access permissions. This improves the elasticity and scalability of the microservice access control system, ensures the availability of microservice resources, and reduces the difficulty of access permission management.

[0088] Here, the permission information includes at least the validity period information, which may include the effective time and the expiration time. The valid authorization token is the authorization token that is within the validity period. If the first service determines that the cached authorization token is within the validity period, it determines that the permission information carried by the cached authorization token is applicable to the current running environment of the target microservice. Then, it assembles the cached authorization token with the microservice access request and sends it to the target microservice.

[0089] In some embodiments, the permission information includes, in addition to the validity period information, one or more of the following: the requested operation, the requested object resource, and the valid quota.

[0090] For example, the method further includes: obtaining the current runtime environment parameters of the target microservice, the runtime environment parameters including one or more of the following: CPU utilization, memory utilization, I / O frequency, and request access frequency.

[0091] For example, updating the cached authorization token based on the current runtime environment parameters of the target microservice includes: calculating the requester's permission increment information based on the current runtime environment parameters of the target microservice and the weights corresponding to each runtime environment parameter; and updating the cached authorization token based on the calculated permission increment information and the permission information carried by the cached authorization token.

[0092] Here, the first service generates and stores the weights corresponding to each runtime environment parameter based on the business type of the corresponding microservice; in order to reduce resource consumption, the first service periodically obtains and stores the current runtime environment parameters of the corresponding microservice.

[0093] Understandably, if the first service determines that the cached authorization token has expired, it calculates the incremental information of each permission information based on the current runtime environment parameters of the corresponding microservice, and dynamically adjusts the corresponding permission information based on the incremental information so that the permission information carried by the updated authorization token is adapted to the current runtime environment of the target microservice. The updated authorization token is then assembled with the microservice access request as a valid authorization token and sent to the target microservice.

[0094] Based on the aforementioned microservice access control method applied to the first service, this application embodiment also provides a microservice access control method applied to the second service, such as... Figure 3 As shown, the method includes:

[0095] Step 301: Receive the authentication request sent by the requester.

[0096] Step 302: Based on the authentication request, after confirming that the requester's identity has been successfully authenticated, generate an authentication token.

[0097] Step 303: Send the authentication token to the requester.

[0098] The authentication token is used to request access to any microservice within the application; the second service is an external service of the application.

[0099] Here, in this embodiment of the application, the microservice access control related service (second service) deployed outside the application is used to authenticate the identity of the requester, but not to authorize the microservice access request. In a decentralized manner, the authorization security boundary is set inside the application, expanding the scope of secure access control from the application boundary to the entire application. Moreover, the authorization information and process are shielded from the requester, effectively preventing unauthorized access attacks.

[0100] Here, the authentication token is used to request access to any microservice within the application. Specifically, the requester sends a microservice access request carrying the authentication token to the target microservice, and the target microservice authorizes the microservice access request after verifying the authentication token.

[0101] For example, after confirming that the requester's identity has been successfully authenticated, an authentication token is generated, including: after confirming that the requester's identity has been successfully authenticated, querying a preset identity information mapping table based on the requester's user ID carried in the authentication request; and generating an authentication token carrying the identity information based on the queried requester's identity information.

[0102] Here, the identity information includes at least a user ID and a role ID. The identity information mapping table records all role IDs corresponding to the user ID of each requester. The authentication request carries at least the user ID of the requester and other information used to authenticate the identity of the requester, such as a login password. The second service authenticates the identity of the requester based on the user ID and login password carried in the authentication request, and issues an authentication token after confirming that the identity of the requester has been successfully authenticated.

[0103] Understandably, when a requester that has failed authentication sends a microservice access request to the first service without obtaining an authentication token, the microservice access request does not carry an authentication token. Therefore, after the first service verifies the microservice access request, it will not generate a corresponding valid authorization token, and the requester will not be able to access the target microservice.

[0104] Here, in this embodiment of the application, the second service set outside the application is not used for microservice access requests, but is used to store the basic permission information corresponding to each requester for each access target microservice.

[0105] For example, the method further includes: receiving an authorization token request sent by a first service, the authorization token request carrying at least the identity information of the requester and the target microservice information; querying a preset access permission table based on the identity information of the requester and the target microservice information to determine the corresponding permission information and generate an authorization token; sending the authorization token to the first service; wherein the first service is an internal service of the application and corresponds to a microservice within the application; the authorization token carries at least permission information.

[0106] Here, the access permission table records at least the following identity information of the requester: the requester's role ID; the target microservice information recorded includes at least the target microservice name; the permission information recorded includes at least the validity period information; the validity period information may include the effective time and the expiration time; the basic permission information recorded may also include at least one of the following: request operation, request object resource, and valid quota.

[0107] Understandably, after receiving the authorization token request sent by the first service, the second service generates a basic authorization token required by the requester to access the target microservice, and sends the generated authorization token request sent by the first service to the second service to authorize the microservice access request. Since the basic authorization token has an expiration date, if the basic authorization token generated by the second service expires, the first service will continuously update and iterate on the basic authorization token based on the current runtime environment parameters of the corresponding microservice.

[0108] In one application example of this application, a microservice access control system is as follows: Figure 4As shown, the first service 100 includes a request management service 101 and a local authorization service 102. The request management service 101 is used to receive microservice access requests, send a valid authorization token request to the local authorization service 102 based on the authentication information carried in the microservice access request, and send the microservice access request and the valid authorization token to the target microservice after receiving the valid authorization token. The local authorization service 102 is used to generate and cache the valid authorization token after receiving the valid authorization token request. The second service 200 includes an authentication service 201 and a central authorization service 202. The authentication service 201 is used to authenticate the identity of the requester. The central authorization service 202 is used to store the permission information corresponding to each requester for each target microservice.

[0109] Based on the microservice access control system described above, this application example also provides a microservice access method, such as... Figure 5 As shown, the method includes:

[0110] Step 501: The requester sends an authentication request to the authentication service.

[0111] Here, the authentication request must include at least the requester's user ID; the authentication request may also carry a login password to authenticate the requester's identity.

[0112] Step 502: The authentication service authenticates the identity of the requester and, after confirming that the requester's identity has been successfully authenticated, queries the user information mapping table to obtain the requester's identity information.

[0113] Here, the requester's identity information includes the requester's user ID and all role IDs.

[0114] Here, an example of a user information mapping table is shown in Table 1:

[0115] Table 1

[0116]

[0117] Step 503: The authentication service generates an authentication token based on the requester's identity information.

[0118] Here, the authentication token is in JWT format, and its structure is shown in Table 2:

[0119] Table 2

[0120]

[0121] Here, based on the structure of the authentication token shown in Table 2, a specific application example of the authentication token is as follows:

[0122]

[0123]

[0124] Step 504: The authentication service sends an authentication token to the requester.

[0125] Step 505: The requester sends a microservice access request to the request management service.

[0126] Here, the microservice access request must at least carry the authentication token sent by the authentication service.

[0127] Here, the requester sends a microservice access request to the request management service corresponding to the target microservice.

[0128] Step 506: After requesting the management service to verify the authentication token, send a valid authorization token request to the local authorization service.

[0129] Here, the request management service and the local authorization service in step 506 correspond to the same microservice.

[0130] Here, a valid authorization token request must at least carry the identity information of the requester.

[0131] Step 507: The local authorization service generates the corresponding valid authorization token and sends it to the request management service.

[0132] Here, step 507 specifically includes:

[0133] Step 5071: The local authorization service checks whether the corresponding authorization token is cached based on the requester's identity information. If yes, proceed to step 5075; otherwise, proceed to step 5072.

[0134] Step 5072: The local authorization service sends an authorization token request to the central authorization service.

[0135] Here, the authorization token request must carry at least the identity information of the requester and the information of the target microservice.

[0136] Step 5073: The central authorization service queries the basic permission information corresponding to the target microservice accessed by the requesting party, generates and sends a basic authorization token to the local authorization service.

[0137] Here, the basic authorization token carries at least basic permission information.

[0138] Here, the central authorization service queries the corresponding basic permission information based on the permission information table. An example of the permission information table is shown in Table 3:

[0139] Table 3

[0140]

[0141] Here, the authorization token is in JWT format, and the structure of the authentication token is shown in Table 4:

[0142] Table 4

[0143]

[0144] Here, based on the structure of the authorization token shown in Table 4, a specific application example of the authorization token is as follows:

[0145]

[0146]

[0147] Step 5074: The local authorization service sends the basic authorization token to the request management service.

[0148] Step 5075: The local authorization service queries the validity period information of the cached authorization token to determine whether the authorization token is valid. If it is, proceed to step 5076; otherwise, proceed to step 5077.

[0149] Here, the validity period information specifically refers to the token's effective date and expiration date.

[0150] Step 5076: The local authorization service sends the cached authorization token to the request management service.

[0151] Here, the request management service will use the received request management service as a valid authorization token.

[0152] Step 5077: The local authorization service calculates the incremental information of each permission, updates the cached authorization token, and sends the updated authorization token to the request management service.

[0153] Here, the dynamic permission calculation factors used to calculate the incremental information of each permission are shown in Table 5:

[0154] Table 5

[0155] Dynamic permission calculation factor illustrate Range of values <![CDATA[r cpu ]]> CPU utilization 0～1 <![CDATA[r mem ]]> Memory usage 0～1 <![CDATA[r IO ]]> I / O frequency 0～1 <![CDATA[r rate ]]> Access request frequency (in seconds) 0～∞ w Request complexity weight 0～10

[0156] This example also provides a method for calculating incremental information on permission information, as detailed below:

[0157] Δ Auth,i,j =W i,j F i,j

[0158]

[0159] Where, Δ Auth,i,j To request an action ACT i Request microservice resource RSCj The incremental information set includes at least the following: effective time exp, expiration time exp, and incremental information of effective quota Q.

[0160] Here, F i,j To request an action ACT i Request microservice resource RSC j The permission influencing factor, i.e., the current runtime environment parameters of the target microservice, is periodically obtained and cached by the local authorization service. The permission influencing factor F i,j Specifically as follows:

[0161]

[0162] Here, W i,j For ACT i RSC j The weights are as follows:

[0163]

[0164] Among them, w i,j To request an action ACT i Request microservice resource RSC j Request complexity weights correspond to the business type definitions of microservices.

[0165] Step 508: Request the management service to send a microservice access request and a valid authorization token to the target microservice.

[0166] Step 509: After verifying the valid authorization token, the target microservice responds to the microservice access request.

[0167] Here, after the target microservice receives a valid authorization token, it determines whether the same valid authorization token is cached. If it is determined that the same valid authorization token is cached, it directly responds to the microservice access request; if it is determined that the same valid authorization token is not cached, it verifies the validity of the valid authorization token. If the verification is successful, it caches the valid authorization token and responds to the microservice access request.

[0168] To implement the method of the embodiments of this application, the embodiments of this application also provide a microservice access control device, which corresponds to the microservice access control method described above. The steps in the embodiments of the microservice access control method described above are also fully applicable to the embodiments of this device.

[0169] Here, as Figure 6As shown in the illustration, this application provides a microservice access control device applied to a first service. The microservice access control device includes a first receiving module 601, a first generating module 602, and a first sending module 603. The first receiving module 601 receives a microservice access request sent by a requester, the microservice access request carrying an authentication token. The first generating module 602 verifies the authentication token and, based on the authentication token, obtains a valid authorization token corresponding to the microservice access request. The first sending module 603 sends the microservice access request and the valid authorization token to the corresponding target microservice. The first service is an internal service of the application and corresponds to a microservice within the application.

[0170] In some embodiments, the first generation module 602 is specifically used to: obtain the authorization token corresponding to the cached microservice access request based on the identity information of the requester carried by the authentication token; determine whether the cached authorization token is valid based on the validity period information carried by the cached authorization token; if it is determined that the cached authorization token is valid, then use the cached authorization token as the valid authorization token corresponding to the microservice access request; if it is determined that the cached authorization token has expired, then update the cached authorization token based on the current runtime environment parameters of the target microservice, and use the updated authorization token as the valid authorization token corresponding to the microservice access request.

[0171] In some embodiments, the microservice access control device further includes an acquisition module 604, which is used to acquire the current runtime environment parameters of the target microservice. The runtime environment parameters include one or more of the following: CPU utilization, memory utilization, I / O frequency, and request access frequency.

[0172] In some embodiments, the first generation module 602 is specifically used to: calculate the incremental permission information of the requester based on the current runtime environment parameters of the target microservice and the weights corresponding to each runtime environment parameter; update the cached authorization token based on the calculated incremental permission information and the permission information carried by the cached authorization token; wherein the permission information includes at least validity period information.

[0173] The first generation module 602 is specifically used for: obtaining the authorization token corresponding to the cached microservice access request based on the identity information of the requester carried in the authentication token, including: determining whether to cache the authorization token corresponding to the microservice access request based on the identity information of the requester; if it is determined that the corresponding authorization token is not cached, sending an authorization token request to the second service, the authorization token request carrying at least the identity information of the requester and the target microservice information; receiving and caching the corresponding authorization token sent by the second service; wherein, the second service is an external service of the application.

[0174] Here, as Figure 7As shown in the illustration, this application also provides a microservice access control device applied to a second service. The microservice access control device includes a second receiving module 701, a second generating module 702, and a second sending module 703. The second receiving module 701 receives an authentication request sent by a requester; the second generating module 702 generates an authentication token based on the authentication request and after confirming that the requester's identity authentication is successful; the second sending module 703 sends the authentication token to the requester; wherein the authentication token is used to request access to any microservice within the application; the second service is an external service of the application.

[0175] In some embodiments, the second generation module 702 is specifically used to: after determining that the requester's identity authentication is successful, query a preset identity information mapping table based on the requester's user ID carried in the authentication request; and generate an authentication token carrying identity information based on the queried requester's identity information.

[0176] In some embodiments, the microservice access control device further includes a third receiving module 704, a third generating module 705, and a third sending module 706. The third receiving module 704 is used to receive an authorization token request sent by the first service. The authorization token request carries at least the identity information of the requester and the target microservice information. The third generating module 705 is used to query a preset access permission table based on the identity information of the requester and the target microservice information, determine the corresponding permission information, and generate an authorization token. The third sending module 706 is used to send the authorization token to the first service. The first service is an internal service of the application and corresponds to a microservice within the application. The authorization token carries at least permission information.

[0177] It should be noted that the microservice access control device provided in the above embodiments is only illustrated by the division of the above program modules when performing microservice access control. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program modules to complete all or part of the processing described above. In addition, the microservice access control device and the microservice access control method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0178] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide a network device. Figure 8 This is only an exemplary structure of the network device, not the entire structure; implementation is possible as needed. Figure 8 The structure shown may be part or all of the structure.

[0179] like Figure 8As shown, this application embodiment provides a network device 800 including: at least one processor 801, a memory 802, a user interface 803, and at least one network interface 804. The various components in the network device 800 are coupled together via a bus system 805. It can be understood that the bus system 805 is used to implement communication between these components. In addition to a data bus, the bus system 805 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 8 The general labeled all buses as Bus System 805.

[0180] The user interface 803 may include a monitor, keyboard, mouse, trackball, click wheel, buttons, touchpad, or touch screen.

[0181] The memory 802 in this embodiment is used to store various types of data to support the operation of the network device 800. Examples of such data include any computer program used to operate on the network device 800.

[0182] The microservice access control method disclosed in this application can be applied to or implemented by processor 801. Processor 801 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the microservice access control method can be completed by integrated logic circuits in the hardware of processor 801 or by instructions in software form. The processor 801 can be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 801 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can be located in a storage medium, specifically memory 802. Processor 801 reads information from memory 802 and, in conjunction with its hardware, completes the steps of the microservice access control method provided in the embodiments of this application.

[0183] In an exemplary embodiment, the network device 800 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), FPGAs, general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned microservice access control method.

[0184] It is understood that memory 802 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), EEPROM, ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Sync Link Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM). The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memory.

[0185] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 802 storing a computer program. This computer program can be executed by the processor 801 of the network device 800 to complete the steps described in the microservice access control method of this application embodiment. The computer-readable storage medium can be a ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM, etc.

[0186] In an exemplary embodiment, this application also provides a computer program product, including a computer program that can be executed by the processor 801 of a network device 800 to complete the steps described in the method of this application embodiment. It should be noted that terms such as "first" and "second" are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0187] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0188] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A microservice access control method, characterized in that, Applied to the first service, the method includes: Receive a microservice access request sent by the requester, the microservice access request carrying an authentication token; After verifying the authentication token, a valid authorization token corresponding to the microservice access request is generated based on the authentication token. Send the microservice access request and the valid authorization token to the corresponding target microservice; The step of generating a valid authorization token corresponding to the microservice access request based on the authentication token includes: Based on the identity information of the requester carried by the authentication token, determine whether to cache the authorization token corresponding to the microservice access request; If it is determined that the corresponding authorization token is not cached, an authorization token request is sent to the second service. The authorization token request carries at least the identity information of the requester and the target microservice information. The corresponding authorization token sent by the second service is received and cached. If it is determined that the corresponding authorization token is cached, the cached corresponding authorization token is directly invoked. Based on the validity period information carried by the cached authorization token, determine whether the cached authorization token is valid; If the cached authorization token is determined to be valid, then the cached authorization token is used as the valid authorization token corresponding to the microservice access request; if the cached authorization token is determined to be expired, then the cached authorization token is updated based on the current runtime environment parameters of the target microservice, and the updated authorization token is used as the valid authorization token corresponding to the microservice access request. The first service is an internal service of the application and corresponds to a microservice within the application; the second service is an external service of the application.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the current runtime environment parameters of the target microservice, which include one or more of the following: CPU utilization, memory utilization, I / O frequency, and request access frequency; The step of updating the cached authorization token based on the current runtime environment parameters of the target microservice includes: Based on the current runtime environment parameters of the target microservice and the weights corresponding to each runtime environment parameter, calculate the incremental permission information of the requester; Based on the calculated incremental information of each permission and the permission information carried by the cached authorization token, update the cached authorization token; The permission information includes at least the validity period information.

3. A microservice access control method, characterized in that, Applied to a second service, the method includes: Receive authentication requests sent by the requesting party; Based on the authentication request, after confirming that the requester's identity has been successfully authenticated, an authentication token is generated; Send the authentication token to the requester; The authentication token is used to request access to any microservice within the application; the second service is an external service of the application. The method further includes: Receive an authorization token request sent by the first service, wherein the authorization token request carries at least the identity information of the requester and the target microservice information; Based on the identity information of the requester and the target microservice information, a preset access permission table is queried to determine the corresponding permission information and generate an authorization token; Send the authorization token to the first service; Wherein, the first service is an internal service of the application and corresponds to a microservice within the application. It is used to receive a microservice access request carrying the authentication token, and after verifying the authentication token, send the microservice access request and a valid authorization token to the corresponding target microservice. The valid authorization token is generated based on the received authorization token. The authorization token carries at least the permission information.

4. The method according to claim 3, characterized in that, After confirming that the requester's identity authentication is successful, an authentication token is generated, including: After confirming that the requester's identity authentication is successful, a preset identity information mapping table is queried based on the user ID of the requester carried in the authentication request; Based on the identity information of the requester obtained from the query, an authentication token carrying the identity information is generated.

5. A microservice access control device, characterized in that, The microservice access control device, applied to the first service, includes: The first receiving module is used to receive a microservice access request sent by the requester, wherein the microservice access request carries an authentication token; The first generation module is used to verify the authentication token and then obtain a valid authorization token corresponding to the microservice access request based on the authentication token. The first sending module is used to send the microservice access request and the valid authorization token to the corresponding target microservice; Specifically, the first generation module is used to: after verifying the authentication token, determine whether to cache the authorization token corresponding to the microservice access request based on the identity information of the requester carried by the authentication token; If it is determined that the corresponding authorization token is not cached, an authorization token request is sent to the second service. The authorization token request carries at least the identity information of the requester and the target microservice information. The corresponding authorization token sent by the second service is received and cached. If it is determined that the corresponding authorization token is cached, the cached corresponding authorization token is directly invoked. Based on the validity period information carried by the cached authorization token, determine whether the cached authorization token is valid; If the cached authorization token is determined to be valid, then the cached authorization token is used as the valid authorization token corresponding to the microservice access request; if the cached authorization token is determined to be expired, then the cached authorization token is updated based on the current runtime environment parameters of the target microservice, and the updated authorization token is used as the valid authorization token corresponding to the microservice access request. The first service is an internal service of the application and corresponds to a microservice within the application; the second service is an external service of the application.

6. A microservice access control device, characterized in that, The microservice access control device, applied to the second service, includes: The second receiving module is used to receive authentication requests sent by the requester; The second generation module is used to generate an authentication token after determining that the identity authentication of the requester has passed based on the authentication request. The second sending module is used to send the authentication token to the requester; The third receiving module is used to receive the authorization token request sent by the first service. The authorization token request carries at least the identity information of the requester and the target microservice information. The third generation module is used to query a preset access permission table based on the identity information of the requester and the target microservice information, determine the corresponding permission information, and generate an authorization token. The third sending module is used to send the authorization token to the first service; wherein, the authentication token is used to request access to any microservice within the application; the second service is an external service of the application; the first service is an internal service of the application and corresponds to a microservice within the application, and is used to receive a microservice access request carrying the authentication token, and after verifying the authentication token, send the microservice access request and a valid authorization token to the corresponding target microservice, wherein the valid authorization token is generated based on the received authorization token; the authorization token carries at least the permission information.

7. A microservice access control system, characterized in that, Includes a second service and at least one first service; Wherein, the first service is an internal service of the application and corresponds to a microservice within the application, and is used to perform the steps of the method according to any one of claims 1 to 2; The second service is an external service of the application, used to perform the steps of the method according to any one of claims 3 to 4.

8. A network device, characterized in that, include: A processor and a memory for storing a computer program capable of running on the processor, wherein the processor, when running the computer program, performs the steps of the method according to any one of claims 1 to 4.

9. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 4.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

Images