Microservice system access control method, device, equipment and storage medium

Abstract

The embodiment of the present invention provides a microservice system access control method, device, equipment and storage medium, which relates to the field of artificial intelligence technology. The method includes: using a first backend microservice to generate a service authorization code according to a first business request information, and then when the next operation is required, the service authorization code is sent in combination with the second business request information, so that the second backend microservice uses the aforementioned generated service authorization code to directly perform permission verification, avoiding the need for each microservice to complete the entire authorization process of authorization-sending-verification when the same business requires multiple microservices to participate separately, overcoming the problem of easy access timeout, reducing the complexity of permission verification between different microservices, and improving the access efficiency of the microservice system.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a microservice system access control method, device, equipment and storage medium. Background Art

[0002] Microservice architecture is a distributed framework that is mainly used to deploy applications and services in the cloud. Microservice architecture is to develop a single program into a microservice. Each microservice runs in its own process and uses lightweight mechanisms to communicate. These services are divided and built around business capabilities and are independently deployed through a fully automated deployment mechanism. Different microservices can use different programming languages ​​and different data storage technologies to ensure minimal centralized management.

[0003] In the related art, if a user business requires multiple microservices to provide services, it is necessary to perform respective authorization processes between different microservices, otherwise the corresponding business cannot be completed. However, the authorization process between each microservice is independent. If a user business requires the participation of multiple microservices, repeated authorization and permission verification processes are likely to cause business timeouts. Summary of the invention

[0004] The main purpose of the embodiments of the present application is to propose a microservice system access control method, device, equipment and storage medium to reduce the complexity of permission verification between different microservices and improve the access efficiency of the microservice system.

[0005] To achieve the above-mentioned purpose, a first aspect of an embodiment of the present application proposes a microservice system access control method, wherein the microservice system includes at least a first backend microservice and a second backend microservice, and the microservice system is configured so that different backend microservices can generate a service authorization code that can be used to access other backend microservices according to the request information of the requesting entity; the method includes:

[0006] The first backend microservice receives first business request information of the request entity;

[0007] The first backend microservice responds to the first business request information and generates first service response information and a service authorization code; wherein the first service response information is generated by the first backend microservice according to the first business request information; the first backend microservice is used to generate the service authorization code of at least one second backend microservice to the requesting entity;

[0008] The first backend microservice sends the first service response information and the service authorization code to the requesting entity;

[0009] The second backend microservice receives the second business request information generated by the requesting entity based on the service authorization code;

[0010] The second backend microservice performs permission verification on the service authorization code;

[0011] According to the permission verification result, the second backend microservice responds to the second business request information and generates second service response information.

[0012] In one embodiment, the first backend microservice responds to the first business request information and generates first service response information and a service authorization code, including:

[0013] The first backend microservice responds to the first business request information and generates first service response information;

[0014] The service authorization code is generated according to the first service request information by using an authority control module.

[0015] In one embodiment, the first service request information includes an access token, and the use of the permission control module to generate the service authorization code according to the first service request information includes:

[0016] Using the permission control module to determine whether to authorize based on the access token;

[0017] If the judgment result is authorization, the authority control module generates the service authorization code according to a preset authorization code format.

[0018] In one embodiment, the first service request information further includes: requesting user information, operating file information and file permission information; the permission control module generates the service authorization code according to a preset authorization code format, including:

[0019] Generate an authorization code parameter according to the first service request information, the authorization code parameter including: requesting user parameter, operation file parameter and file permission parameter;

[0020] Based on the preset authorization code format, the service authorization code of the authorization code parameter is generated.

[0021] In one embodiment, the operation file information includes: an operation document class name and an operation document number; the service authorization code generated by the authorization code parameter based on the preset authorization code format includes:

[0022] Generate the operation file parameters according to the operation document class name and the operation document number, the operation file parameters include: operation document class parameters and operation document number parameters;

[0023] The operation file parameters are concatenated with the request user parameters to obtain the first authorization code information;

[0024] The service authorization code is obtained by concatenating the file permission parameter with the first authorization code information.

[0025] In one embodiment, after generating the service authorization code of the authorization code parameters based on the preset authorization code format, the method further includes: encrypting the service authorization code using a preset encryption algorithm and a preset key to obtain the encrypted service authorization code.

[0026] In one embodiment, the requested user information is a user session ID.

[0027] In one embodiment, the service authorization code includes at least one of the file permission parameters, and different file permission parameters are generated by separating them using a preset separator.

[0028] In one embodiment, the second backend microservice performs permission verification on the service authorization code, including:

[0029] Extracting the service authorization code from the second service request information, where the service authorization code is located at a preset position in the second service request information;

[0030] Obtain the authorization code parameter in the service authorization code;

[0031] If the authorization code parameters meet the permission verification conditions, the permission verification passes.

[0032] In one embodiment, if the authorization code parameter satisfies the permission verification condition, the permission verification passes, including:

[0033] If the current user is determined to be an authorized user according to the request user parameters, the first permission check is passed;

[0034] If it is determined according to the operation file parameters that the file requested for operation is an authorized file, then the second permission check passes;

[0035] If the file operation permission is determined to be an authorized interface according to the file permission parameter, the third permission check passes;

[0036] If the first permission check passes, the second permission check passes, and the third permission check passes, the permission check passes.

[0037] In one embodiment, the second service request information is http / https request information, and the service authorization code is located in the URL information, request header information or request body information of the http / https request information.

[0038] In one embodiment, sending the service authorization code to the requesting entity includes: sending the service authorization code to the requesting entity by means of parameter transmission.

[0039] To achieve the above-mentioned purpose, a second aspect of an embodiment of the present application proposes a microservice system access control device, wherein the microservice system includes at least a first backend microservice and a second backend microservice, and the microservice system is configured so that different backend microservices can generate a service authorization code that can be used to access other backend microservices according to the request information of the requesting entity; the device includes:

[0040] A first request receiving module, used for the first backend microservice to receive first business request information of a request entity;

[0041] A first request response module, configured for the first backend microservice to respond to the first business request information and generate first service response information and a service authorization code; wherein the first service response information is generated by the first backend microservice according to the first business request information; the first backend microservice is configured to generate the service authorization code of at least one second backend microservice to the requesting entity;

[0042] A service authorization code sending module, used for the first backend microservice to send the first service response information and the service authorization code to the requesting entity;

[0043] A second request receiving module, configured for a second backend microservice to receive second business request information generated by the requesting entity based on the service authorization code;

[0044] An authority verification module is used for the second backend microservice to perform authority verification on the service authorization code;

[0045] The second request response module is used to generate second service response information by the second backend microservice in response to the second business request information according to the permission verification result.

[0046] To achieve the above objectives, a third aspect of an embodiment of the present application proposes an electronic device, which includes a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method described in the first aspect is implemented.

[0047] To achieve the above-mentioned purpose, the fourth aspect of an embodiment of the present application proposes a storage medium, which is a computer-readable storage medium, and the storage medium stores a computer program. When the computer program is executed by a processor, the method described in the first aspect is implemented.

[0048] The microservice system access control method, device, equipment and storage medium proposed in the embodiment of the present application, receives the first business request information of the request entity through the first backend microservice and responds to the first business request information, generates the first service response information and the service authorization code, and then sends the service authorization code to the request entity, and the second backend microservice receives the second business request information generated by the request entity based on the service authorization code; uses the second backend microservice to perform permission verification on the service authorization code, and if the permission verification passes, uses the second backend microservice to respond to the second business request information and generate the second service response information. The embodiment of the present application uses the first backend microservice to generate a service authorization code according to the first business request information, and when subsequent operations are required, the service authorization code is sent in combination with the second business request information, so that the second backend microservice uses the aforementioned generated service authorization code to directly perform permission verification, avoiding the need for each microservice to complete the entire authorization process of authorization-sending-verification when the same business requires multiple microservices to participate separately, overcoming the problem of easy access timeout, reducing the complexity of permission verification between different microservices, and improving the access efficiency of the microservice system. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 It is a schematic diagram of the structure of a microservice system provided by an embodiment of the present invention.

[0050] Figure 2 It is a flow chart of a microservice system access control method provided by an embodiment of the present invention.

[0051] Figure 3 yes Figure 2 Flowchart of step S120 in .

[0052] Figure 4 yes Figure 3 Flowchart of step S122 in .

[0053] Figure 5 yes Figure 4 Flowchart of step S1222 in .

[0054] Figure 6 yes Figure 5 Flowchart of step S1224 in .

[0055] Figure 7 It is a schematic diagram of the encryption process of the microservice system access control method provided by an embodiment of the present invention.

[0056] Figure 8 It is a schematic diagram of the group encryption process of the microservice system access control method provided by an embodiment of the present invention.

[0057] Fig. 9 yes Figure 2 Flowchart of step S150 in .

[0058] Fig.10 yes Fig. 9 Flowchart of step S153 in .

[0059] Fig.11 This is a flowchart of a microservice system access control method provided by another embodiment of the present invention.

[0060] Fig.12 This is a flowchart of a microservice system access control method provided by another embodiment of the present invention.

[0061] Fig.13 This is a flowchart of a microservice system access control method provided by another embodiment of the present invention.

[0062] Fig.14 It is a structural block diagram of a microservice system access control device provided by another embodiment of the present invention.

[0063] Fig.15 It is a schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0064] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0065] It should be noted that although the functional modules are divided in the device schematic and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart.

[0066] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which the present invention belongs. The terms used herein are only for the purpose of describing the embodiments of the present invention and are not intended to limit the present invention.

[0067] Microservice architecture is a distributed framework that is mainly used to deploy applications and services in the cloud. Microservice architecture is to develop a single program into a microservice. Each microservice runs in its own process and uses lightweight mechanisms to communicate. These services are divided and built around business capabilities and are independently deployed through a fully automated deployment mechanism. Different microservices can use different programming languages ​​and different data storage technologies to ensure minimal centralized management.

[0068] The applicant found that in the related art, each service under the microservice architecture runs on an independent Java virtual machine, and its databases, businesses, and permissions are independent of each other. There is no dependency between them except for the defined interfaces. The external data interface of each service is controlled by the permissions of the service. Each service has an independent authentication mechanism. When the front end needs to access a certain interface, the current user must have the permission of the service, otherwise there is no access permission. If a user business requires multiple microservices to provide services separately, the different microservices complete the service process independently at this time, and each microservice needs to perform its own authorization process, otherwise the corresponding business cannot be completed. However, the authorization process between each microservice is independent. If a user business requires the participation of more microservices, repeated authorization and permission verification processes are likely to cause business timeouts.

[0069] Based on this, the embodiments of the present invention provide a microservice system access control method, apparatus, device and storage medium, which uses a first backend microservice to generate a service authorization code according to first business request information, and when the next operation is required, the service authorization code is sent in combination with the second business request information, so that the second backend microservice uses the aforementioned generated service authorization code to directly perform permission verification, avoiding the need for each microservice to complete the entire authorization process of authorization-sending-verification when the same business requires multiple microservices to participate separately, overcoming the problem of easy access timeout, reducing the complexity of permission verification between different microservices, and improving the access efficiency of the microservice system.

[0070] The embodiments of the present invention provide a microservice system access control method, apparatus, device and storage medium, which are specifically described through the following embodiments. First, the microservice system access control method in the embodiments of the present invention is described.

[0071] In order to facilitate understanding of the embodiments of the present application, the microservice system in the embodiments of the present application is first described below.

[0072] Reference Figure 1 , the microservice system 100 includes: multiple microservices 200 (three microservices are used as an example in the figure).

[0073] In one embodiment, a permission control module is provided in each microservice 200. In other embodiments, the permission control module can also be provided independently, and each microservice 200 is connected to the permission control module, and the specific location of the permission control module is not limited here. Among them, the permission control module is used to generate a service authorization code and perform permission verification.

[0074] The first backend microservice and the second backend microservice both belong to Figure 1In the multiple microservices 200, the permission control module can be integrated with the first backend microservice and the second backend microservice, or it can be an independent module, which is not specifically limited in this embodiment.

[0075] In one embodiment, the requesting entity 10 sends a service request to the microservice system 100, and the service request is transmitted to the microservice 200 providing the service. The microservice 200 uses the authority control module to perform an authority check on the service request. If the authority check passes, the microservice 200 providing the service provides the service to the requesting entity and returns the service data. It can be understood that the requesting entity can be a mobile device application or a network application, etc.

[0076] In one embodiment, the microservice system 100 requires more than one microservice 200 to provide services respectively to implement the business request sent by the requesting entity. For example, the business implementation order is: microservice A-microservice B-microservice C, then microservice A first responds to the business request, completes the corresponding part of the content, and then passes the response data to the requesting entity, and then the requesting entity requests service from microservice B, microservice B responds to the business request, completes the corresponding part of the content, and then passes the response data to the requesting entity, and the requesting entity requests service from microservice C again, microservice C responds to the business request, and completes the corresponding part of the content. In this process, each microservice needs to use the permission control module to complete the permission verification process.

[0077] The following describes a microservice system access control method in an embodiment of the present invention.

[0078] Figure 2 is an optional flowchart of the microservice system access control method provided by an embodiment of the present invention. Figure 2 The method in the embodiment may include but is not limited to steps S110 to S170. Figure 2 The order of step S110 to step S170 is not specifically limited, and the order of steps can be adjusted or some steps can be reduced or added according to actual needs.

[0079] Step S110: The first backend microservice receives first business request information from a requesting entity.

[0080] In one embodiment, the microservice system includes at least a first backend microservice and a second backend microservice, and the microservice system is configured so that different backend microservices can generate service authorization codes that can be used to access other backend microservices based on the request information of the requesting entity. In this embodiment, the first backend microservice is the first backend microservice to which the requesting entity sends a request. It can be understood that any backend microservice in the microservice system of this embodiment can be used as the first backend microservice to receive the request information sent by the requesting entity. In other words, rules can be pre-agreed in the microservice system: different backend microservices can authorize each other, and a certain backend microservice can be used as the first backend microservice to receive the first business request information and generate a service authorization code with access to other backend microservices.

[0081] In one embodiment, the service authorization code generated by the first backend microservice may be an access right for accessing one backend microservice, or an access right for accessing multiple different backend microservices.

[0082] In one embodiment, the requesting entity receives the user's operation information through the user interface, and generates the first service request information according to the user's operation information. The first service request information is used to represent the call to the microservice system to complete the corresponding application function, including all backend microservices that complete the corresponding function.

[0083] Step S120: The first backend microservice responds to the first business request information and generates first service response information and a service authorization code.

[0084] In one embodiment, the first backend microservice is used to generate a service authorization code for at least one second backend microservice to the requesting entity. Figure 3 , is a specific implementation flow chart of step S120 shown in an embodiment. In this embodiment, the microservice responds to the first business request information, and step S120 of generating the first service response information and the service authorization code includes:

[0085] Step S121: The first backend microservice responds to the first business request information and generates first service response information.

[0086] In one embodiment, the first service request information includes service information. The microservice system selects one or more microservices to execute the service according to the service information and generates an access sequence. The access token is sent to the first microservice according to the access sequence. The first microservice is the first backend microservice. The first backend microservice responds to the first service request information and generates corresponding first service response information.

[0087] Step S122: Generate a service authorization code according to the first service request information using the authority control module.

[0088] In one embodiment, the first service request information also includes an access token, which represents the user information of the requesting entity. The first backend microservice authenticates the user identity of the requesting entity to the authority control module according to the access token and generates a service authorization code.

[0089] In one embodiment, referring to Figure 4 , is a specific implementation flow chart of step S122 shown in an embodiment. In this embodiment, step S122 of generating a service authorization code according to the first service request information by using the authority control module includes:

[0090] Step S1221: Use the permission control module to determine whether to authorize based on the access token.

[0091] Step S1222: If the judgment result is authorization, the authority control module generates a service authorization code according to a preset authorization code format.

[0092] In one embodiment, the access token contains an application number, represented as App Id, and the permission control module determines whether the requesting entity that sends the first service request information is an authorized requesting entity based on the application number, that is, whether the microservice system can implement the service request of the application. If the judgment result is authorization, the service request of the requesting entity is authorized.

[0093] In one embodiment, when the authority control module determines that the requesting entity needs to be authorized, the authority control module generates a service authorization code according to a preset authorization code format.

[0094] In one embodiment, the service information of the first service request information further includes: requesting user information, operation file information and file authority information.

[0095] The request user information is the session number of the application for which the request entity requests the service. Since HTTP is a stateless protocol, when the request entity sends a service request to the microservice system, the microservice system does not know whether this is the first or nth request of the request entity. Therefore, in this embodiment, the request information is associated through the session number, and the session number can be used as a unique user identifier. For example, in frameworks such as Spring or containers such as Tomcat, the session number can be used to indicate the unique identification information of the same user corresponding to different service requests.

[0096] In one embodiment, the operation file information includes: an operation document class name and an operation document number, that is, in this embodiment, the business request sent by the requesting entity is related to the file operation. The operation file information is used to represent the document name corresponding to the requested data when requesting the corresponding service, and is combined with the "operation document number" to represent the data item content of the permission granted when performing permission verification. For example, if you need to download configuration file 1, the operation document class name can be: configuration file, and the operation document number can be: "1".

[0097] In one embodiment, the file permission information indicates the permission of the user to operate the configuration file 1. For example, the file permission information includes: editing permission, viewing permission or deletion permission, etc. The permission can be selected according to actual needs, and this embodiment does not limit this. It can be understood that the file permission information indicates that the requesting entity can not only access the files in the backend microservice, but also edit, delete and other operations on them.

[0098] In one embodiment, referring to Figure 5 , is a specific implementation flow chart of step S1222 shown in an embodiment. In this embodiment, step S1222 in which the authority control module generates a service authorization code according to a preset authorization code format includes:

[0099] Step S1223: Generate an authorization code parameter according to the first service request information.

[0100] Step S1224: Generate a service authorization code for the authorization code parameters based on the preset authorization code format.

[0101] In one embodiment, corresponding to the requesting user information, operating file information and file permission information of the first service request information, the corresponding authorization code parameters include: requesting user parameters (expressed as sessionId), operating file parameters and file permission parameters (expressed as file permissions). It can be understood that the authorization code parameters are parameterized requesting user information, operating file information and file permission information, which is a format conversion, converting requesting user information, operating file information and file permission information into a character format that can be operated by the system.

[0102] In one embodiment, referring to Figure 6 , is a specific implementation flow chart of step S1224 shown in an embodiment. In this embodiment, step S1224 of generating a service authorization code of the authorization code parameter based on a preset authorization code format includes:

[0103] Step S1225: Generate operation file parameters according to the operation document class name and the operation document number.

[0104] In one embodiment, since the operation file information includes: an operation document class name and an operation document number, the operation file parameter includes: an operation document class parameter (expressed as a document class name) and an operation document number parameter (expressed as a document ID).

[0105] Step S1226: concatenate the operation file parameters with the request user parameters to obtain the first authorization code information.

[0106] Step S1227: concatenate the file permission parameter with the first authorization code information to obtain a service authorization code.

[0107] In one embodiment, the preset authorization code format of the service authorization code is: "requesting user parameters; operation document class parameters#operation document number parameters; file permission parameters", expressed as: "sessionId; document class name#document ID; file permissions".

[0108] In one embodiment, the service authorization code includes at least one file permission parameter, that is, the service requested by the user includes multiple permissions for file operations, such as editing and deletion, so different file permission parameters are separated by a preset separator. The preset separator can be: " / ", "-", "&" and other symbols, as long as different file permission parameters can be distinguished.

[0109] From the above, it can be seen that the embodiment of the present application arranges the requesting user parameters, the operating file parameters and the file permission parameters according to the format of the preset authorization code.

[0110] In one embodiment, for security reasons, the service authorization code obtained above is encrypted. For example, the service authorization code is encrypted using a preset encryption algorithm and a preset key to obtain an encrypted service authorization code.

[0111] It is understandable that in order to avoid the problem that the length of the generated ciphertext service authorization code string is long and increases with the number of permissions, the embodiment of the present application can selectively encrypt the authorization code parameters.

[0112] In one embodiment, the preset encryption algorithm is the AES encryption algorithm. The AES encryption algorithm is also called the Advanced Encryption Standard (AES), which is a symmetric encryption algorithm. The meaning of a symmetric encryption algorithm is that the encryption process and the decryption process use the same preset key. Specifically, this embodiment uses the ECB encryption mode of the AES encryption algorithm, which divides the entire plaintext into several identical small segments, and then encrypts each small segment.

[0113] Reference Figure 7 , which is a schematic diagram of the encryption process of an embodiment of the present application.

[0114] The encryption party (such as the permission control module) uses the AES encryption function and the preset key K to encrypt the plaintext service authorization code P to obtain the encrypted ciphertext service authorization code C. If the subsequent decryption party (such as a microservice) needs to decrypt the ciphertext service authorization code C, the ciphertext service authorization code C is decrypted using the AES decryption function and the same preset key K as the encryption process to obtain the plaintext service authorization code P. Furthermore, according to the format of the preset authorization code, the request user parameters, operation file parameters, and file permission parameters are obtained from the plaintext service authorization code.

[0115] In one embodiment, the service authorization code is encrypted using a block encryption process. Figure 8 In the block encryption process, the plaintext service authorization code P is first divided into multiple independent plaintext blocks Pi according to the preset segmentation length, and then each plaintext block Pi is encrypted using the AES encryption function and the preset key K to generate the corresponding ciphertext block Ci. All ciphertext blocks Ci are spliced ​​together in the segmentation order to obtain the ciphertext service authorization code C. The preset segmentation length can be 128 bits.

[0116] In one embodiment, if the length of a plaintext block obtained after the plaintext service authorization code P is split according to the preset split length is less than the preset split length, the plaintext block is padded. For example, the length of the plaintext service authorization code P is 192 bits, and the preset split length is 128 bits. If it is split into one plaintext block of 128 bits, the second plaintext block is only 64 bits, which is less than 128 bits, so it is necessary to fill in the second plaintext block. The filling method of this embodiment is PKCS5. This filling method is: if the number of bytes missing in the plaintext block is less than 16 bytes (128 bits), the corresponding number of characters are added at the end of the plaintext block, and the value of each byte is equal to the number of missing characters. It can be understood that decryption needs to be performed according to the filling method used in the encryption process.

[0117] It is understandable that the encryption key of the embodiment of the present application can be freely defined or obtained in a configuration file.

[0118] From the above, it can be seen that the embodiment of the present application arranges the requesting user parameters, operation file parameters and file permission parameters according to the format of the preset authorization code to obtain a plaintext service authorization code, and then generates an encrypted service authorization code according to the preset encryption method and preset key.

[0119] Step S130: Send the first service response information and the service authorization code to the requesting entity.

[0120] In one embodiment, the microservice system calls the first backend microservice to respond to the first business request information, generates corresponding first service response information, and sends the first service response information and the service authorization code to the requesting entity at the same time.

[0121] In one embodiment, the first backend microservice of the microservice system sends the service authorization code to the requesting entity by means of parameter transmission, that is, the service authorization code is converted into a URL parameter and sent to the requesting entity.

[0122] Step S140: The second backend microservice receives the second business request information generated by the requesting entity based on the service authorization code.

[0123] In one embodiment, after receiving the service authorization code and the first service response information, the requesting entity generates second service request information, wherein the second service request information is generated based on the first service response information and includes the service authorization code.

[0124] Step S150: Use the second backend microservice to perform permission verification on the service authorization code.

[0125] In one embodiment, the microservice system selects a microservice that executes the business request according to the second business request information as the second backend microservice. Before executing the second business request information, the second backend microservice needs to perform a permission check to ensure security.

[0126] In one embodiment, referring to Fig. 9 , is a specific implementation flow chart of step S150 shown in an embodiment. In this embodiment, step S150 of using the second backend microservice to perform permission verification on the service authorization code includes:

[0127] Step S151: extracting a service authorization code from the second service request information, where the service authorization code is located at a preset position in the second service request information.

[0128] In one embodiment, the second service request information is http / https request information, and the service authorization code is located in the second service request information. For example, it can be located in the URL information of the http / https request information, in the request header information, or in the request body information, and the location of the service authorization code is not limited here.

[0129] Step S152: Obtain the authorization code parameters in the service authorization code.

[0130] In one embodiment, after obtaining the service authorization code as described above, the following are obtained from the service authorization code according to a preset authorization code format: requesting user parameters, operation file parameters and file permission parameters, wherein the operation file parameters include: operation document class parameters and operation document number parameters.

[0131] Step S153: If the authorization code parameters meet the permission verification conditions, the permission verification passes.

[0132] In one embodiment, referring to Fig.10 , is a specific implementation flow chart of step S153 shown in an embodiment. In this embodiment, step S153 of using the second backend microservice to perform permission verification on the service authorization code includes:

[0133] Step S1531: If the current user is determined to be an authorized user based on the requesting user parameters, the first permission check is passed.

[0134] In one embodiment, the user identity must first be determined, that is, whether the current user is an authorized user is determined based on the request user parameters. If the current user is an authorized user, the first permission check is passed.

[0135] Step S1532: Determine, based on the operation file parameters, whether the file for which the operation is requested is an authorized file, and the second permission check passes.

[0136] In one embodiment, under the premise that the user identity is legal, it is determined whether the file requested for operation is an authorized file based on the operation file parameters, that is, files outside the operation authority cannot be operated. If it is an authorized file, the second permission check passes.

[0137] Step S1533: judging that the file operation permission is an authorized interface according to the file permission parameters, the third permission check passes.

[0138] In one embodiment, corresponding to the multiple permissions of file operations, the authorization interface includes: viewing interface, editing interface or deletion interface, etc. Under the premise of requesting the authorization file, it is determined whether the file operation permission is an authorization interface according to the file permission parameters. If the operation permission range interface is consistent, the third permission check is passed.

[0139] Step S1534: If the first permission check passes, the second permission check passes, and the third permission check passes, the permission check passes.

[0140] From the above, it can be seen that the permission check is passed only when the first permission check passes, the second permission check passes and the third permission check passes, and all three permission checks pass.

[0141] Step S160: According to the permission verification result, the second backend microservice responds to the second business request information and generates second service response information.

[0142] In one embodiment, if the permission check passes, the microservice system uses the second backend microservice to respond to the second business request information and generate second service response information.

[0143] From the above, it can be seen that the embodiment of the present application uses the first backend microservice to generate a service authorization code based on the first business request information. When the next step is required, the service authorization code is sent in combination with the second business request information, so that the second backend microservice uses the aforementioned generated service authorization code to directly perform permission verification, avoiding the need for each microservice to complete the entire authorization process of authorization-send-verification when the same business requires multiple microservices to participate separately, overcoming the problem of easy access timeout, reducing the complexity of permission verification between different microservices, and improving the access efficiency of the microservice system.

[0144] The service authorization code of the embodiment of the present application does not need to be stored, avoiding remote access or data storage during the authorization and authentication process, which leads to the problem of easy timeout. And the service authorization code can be appended or superimposed in different permission authorizations of the same document, that is, the permission is appended after decryption at any code position of a single request, and the usage scenario of the extended file authorization is extended. At the same time, the service authorization code of the embodiment of the present application is transmitted through the front end, and the authorization code is presented when requesting the service of other microservices. After other microservices use the same encryption key for decoding, the various authorization code parameter information can be verified, and it is determined whether the authorized user matches the current user, whether the authorized document is the document requested this time, and whether the authorized authority meets the interface authority of this request, thereby improving the task processing efficiency. Further, since the requesting user information is the session number of the application of the requesting entity requesting the service, when the user logs out or the current session times out, this service authorization code is automatically invalidated, thereby improving the security of the service authorization code. And the encrypted content can be flexibly adjusted according to actual needs, such as when there is no need to distinguish the authorized authority, the authority part is not required.

[0145] The following describes the specific process of the microservice system access control method in the embodiment of the present application through a specific embodiment.

[0146] In this embodiment, the microservice system needs two microservices to implement the business request sent by the requesting entity. The business implementation order is: microservice A (first backend microservice)-microservice B (first backend microservice). There may be no correlation between microservice A and microservice B, and they can complete the service process independently. Microservice A first responds to the business request and completes the corresponding part of the content, and then passes the response data and authorization code to microservice B. Microservice B responds to the business request and completes the corresponding part of the content. In this process, each microservice needs to use the permission control module to complete the permission verification process.

[0147] Reference Fig.11 , which is a schematic diagram of the first backend microservice processing flow of the microservice system access control method in an embodiment of the present application.

[0148] Since the first business request information of the requesting entity needs to be processed by the first backend microservice, step S1110 obtains the first business request information from the user interface of the requesting entity. The first business request information includes business information. The microservice system selects the first backend microservice to execute the business according to the business information, so the main entrance of the first business request information is connected to the first backend microservice.

[0149] In this embodiment, the first service request information also includes an access token, and the access token represents the user information of the requesting entity. In step S1120, the first backend microservice authenticates the user identity of the requesting entity to the authority control module according to the access token. In step S1130, the authority control module determines whether to authorize according to the access token. If the judgment result is yes, step S1140 performs authorization, and the authority control module generates a service authorization code according to the preset authorization code format; otherwise, step S150 refuses authorization and returns the result of this authorization request to the first backend microservice.

[0150] In this embodiment, step S1140 performs authorization, and the process in which the authority control module generates a service authorization code according to a preset authorization code format is specifically as follows:

[0151] The business information of the first business request information also includes: requesting user information, operating file information and file permission information. The corresponding authorization code parameters obtained corresponding to the first business request information include: requesting user parameters (expressed as sessionId), operating file parameters and file permission parameters (expressed as file permissions). Since the operating file information includes: operating document class name and operating document number, the operating file parameters include: operating document class parameters (expressed as document class name) and operating document number parameters (expressed as document ID). The authorization code parameters are parameterized by requesting user information, operating file information and file permission information.

[0152] The preset authorization code format of the service authorization code is: "request user parameters; operation document class parameters#operation document number parameters; file permission parameters", expressed as: "sessionId; document class name#document ID; file permissions".

[0153] In this embodiment, the encryption and decryption algorithm of the service authorization code is the AES encryption algorithm, the working mode is ECB encryption mode, the filling method is PKCS5, and the encrypted ciphertext service authorization code is converted by Base64.encodeBase64URLSafeString conversion. The purpose of the conversion is to convert the ciphertext service authorization code into the URL parameter form, and no transcoding is required in the subsequent processing process.

[0154] The first service response information and service authorization code generated by the first backend microservice according to the first business request information are obtained, the first service response information and service authorization code are sent to the requesting entity, and the second business request information generated by the requesting entity is obtained.

[0155] Reference Fig.12 , which is a schematic diagram of the second backend microservice processing flow of the microservice system access control method in an embodiment of the present application.

[0156] Since the second business request information of the requesting entity needs to be processed by the second backend microservice (different from the first backend microservice). Step S1210 obtains the second business request information from the user interface of the requesting entity. The second business request information is generated based on the first service response information and includes a service authorization code. In step S1220, the second backend microservice performs a permission check on the service authorization code. If the permission check passes, step S1230 uses the second backend microservice to respond to the second business request information. Step S1240 returns the generated second service response information. If the permission check fails, the second service response information is unauthorized.

[0157] In this embodiment, in step S1220, the process of the second backend microservice performing permission verification on the service authorization code is as follows: extracting the service authorization code from the second business request information, and then obtaining the authorization code parameters in the service authorization code using the same decryption method as the encryption method. If the authorization code parameters meet the permission verification conditions, the permission verification passes.

[0158] The verification process is:

[0159] First, based on the request user parameter ("SessionId"), it is determined that the current user is an authorized user, and the first permission check passes; then based on the operation file parameters ("Document ID" and "Document Class Name"), it is determined that the file requested for operation is an authorized file, and the second permission check passes; based on the file permission parameters ("Document Permission"), it is determined that the file operation permission is an authorized interface, and the third permission check passes. If the first permission check passes, the second permission check passes, and the third permission check passes, then the permission check passes. From the above, it can be seen that only when the first permission check passes, the second permission check passes, and the third permission check pass, and all three permission checks pass, the permission check passes. Once the permission check passes, the "Document ID" and "Document Class Name" can be used to process data, such as querying.

[0160] Reference Fig.13 , the specific process of the microservice system access control method of another embodiment of the present application.

[0161] The figure includes a request entity, a first backend microservice and a second backend microservice, wherein the request entity is the business module front end, the first backend microservice is the business module back end, and the second backend microservice is the attachment backend service.

[0162] Among them, the first backend microservice and the second backend microservice are both integrated with permission control modules. Therefore, the first backend microservice includes a business execution module and a permission control module, which respectively perform business operations and permission control. Similarly, the second backend microservice also includes a business execution module and a permission control module, which respectively perform business operations and permission control.

[0163] First, the requesting entity sends the first business request information through the viewing page (i.e., the user interface), calls the first backend microservice, and sends the first business request information to the first backend microservice. The business processing module of the first backend microservice applies to the authority control module for user identity authentication of the requesting entity based on the first business request information. The authority control module authorizes based on the access token. If the authorization is successful, a service authorization code is generated and returned to the first backend microservice. The first backend microservice returns the first service response information and the service authorization code to the requesting entity.

[0164] Then the requesting entity generates a second service request message based on the first service response message, calls the interface of the second backend microservice, and sends the second service request message to the second backend microservice. The second service request message includes a service authorization code. The business execution module of the second backend microservice sends the service authorization code to the permission control module, and obtains the authorization code parameter in the service authorization code using the same decryption method as the encryption method. If the authorization code parameter meets the permission verification condition, the permission verification passes. The permission control module sends the result of the permission verification to the second backend microservice. The second backend microservice generates a second service response message based on the second service request message. For example, the second backend microservice can provide a microservice for attachment services for the requesting entity. Correspondingly, the second service response message can be a microservice that allows the requesting entity to download attachments.

[0165] In this embodiment, the authorization code parameter is expressed as:

[0166] Request user parameters (sessionId):

[0167] MGUyOTA5NzMtYTcyZC00ZmMzLTkzM2YtNWQ0YWI3NDVlNGU0;

[0168] Operation document class parameters (document class name):

[0169] com.landray.sys.xform.core.entity.official.SysXFormOfficial;

[0170] Operation document number parameter (document ID): 1g6v5lf07w572w4adw3p08js1slobm02ciw0;

[0171] File permission parameters (file permissions): attachGetAll;

[0172] The default key is:

[0173] {-122,47,-49,-55,-14,-99,-51,-69,-2,124,-80,45,27,76,-17,93}

[0174] The plain text service authorization code is generated by the above parameters according to the preset authorization code format "sessionId; document class name#document ID; file permissions", and then encrypted based on the AES encryption method. The cipher text service authorization code obtained using the above preset key is expressed as:

[0175] TpfpROYGLURxadEn1CHgxvcgQPw_YrBDA6H9kdWZc0ldBaGbEOF5r0szxvwv4CJzAOhi5NghDaafTRfDyZt1pq0yzaTMi1WBoJ0rrgnP5ms B2PEjOeu0hsugAmAYwEUVe193GL7Y-BMNw34VSbU0BMmw3HCJt3xBMg6psbbghYxIa57dUHnlzr7ReFSQmZ5pFMYQXOZrqJd-6Lo6fz32TA

[0176] Since the attachment download request protocol is HTTPS, the encrypted service authorization code generated above is passed to the requesting entity by means of parameter passing (mechAuthToken). The second service request information generated by the requesting entity based on the first service response information is expressed as:

[0177] https: / / test.ywork.me / data / sys-attach / checkDownload / 1g6v5l3tuw57lwg7dwfpspnbnlcpbp2bjiw0mechAuthToken=TpfpROYGLURxadEn1CHgxvcgQPw_YrBDA6H9kdWZc0ldBaGbEOF5r0szxvwv4CJzAOhi5NghDaafTRfDyZt1pq0yzaTMi1WBoJ0rrgnP5msB2PEjOeu0hsugAmAYwEUVe193GL7Y-BMNw34VSbU0BMmw3HCJt3xBMg6psbbghYxIa57dUHnlzr7ReFSQmZ5pFMYQXOZrqJd-6Lo6fz32TA

[0178] It can be seen from the “mechAuthToken” part of the second service request information that the second service request information includes a ciphertext service authorization code, and the service authorization code is located in the URL information.

[0179] At the same time, the "X-AUTH-TOKEN" information of the second service request information indicates the user identity information in the non-state state, which can be used to verify the authorization code in the next step, where:

[0180] X-AUTH-TOKEN =1gf7sauasw89w4eqws9bjnp16h15ork0jbw0

[0181] The ciphertext service authorization code is decrypted using the preset key and the same decryption algorithm to obtain the authorization code parameters in the service authorization code. If the authorization code parameters meet the permission verification conditions, the permission is verified.

[0182] The request user parameter ("SessionId") is compared with the current user identity information, which is the user identity information X-AUTH-TOKEN carried in the header information. It is compared with the SessionId obtained by decrypting the service authorization code to determine whether the current user is an authorized user. The first permission check is passed. Then, based on the operation file parameters ("document ID" and "document class name"), it is determined whether the file requested for operation is a file existing in the second backend microservice. If so, the second permission check is passed. Based on the file permission parameters ("document permission"), it is determined whether the file operation permission is consistent with the file permission. If they are consistent, the third permission check is passed. If the first permission check passes, the second permission check passes, and the third permission check passes, the permission check passes, and operations such as document download, query, modification, or deletion can be performed.

[0183] It can be understood that the above embodiment is illustrated with a second backend microservice. In practice, if after the second backend microservice is processed, an independent third backend microservice needs to be called, the service authorization code generated by the first backend microservice can be added to the business request information of the third backend microservice during the session time. The third backend microservice verifies the service authorization code in the same way as the second backend microservice, and so on, it can be used in the independent processing flow of multiple backend microservices.

[0184] For example, when the content in the same user interface is independently provided by multiple different microservices, the authorization method of the embodiment of the present application does not require a dependency relationship between the two services. From a performance perspective, there is no need to store data in a database or data storage service such as redis, nor is there a need to call interfaces with each other. This authorization is temporary and confidential, and will automatically expire after a period of time. When a user sends an access link to another unauthorized user, the unauthorized user is still inaccessible.

[0185] The microservice system access control method proposed in the embodiment of the present application receives the first business request information of the requesting entity through the first backend microservice and responds to the first business request information, generates first service response information and a service authorization code, and then sends the service authorization code to the requesting entity, and the second backend microservice receives the second business request information generated by the requesting entity based on the service authorization code; uses the second backend microservice to perform permission verification on the service authorization code, and if the permission verification passes, uses the second backend microservice to respond to the second business request information and generate second service response information.

[0186] The embodiment of the present application utilizes the first backend microservice to generate a service authorization code according to the first business request information. When the next operation is required, the service authorization code is sent in combination with the second business request information, so that the second backend microservice uses the aforementioned generated service authorization code to directly perform permission verification, avoiding the need for each microservice to complete the entire authorization process of authorization-sending-verification when the same business requires multiple microservices to participate separately, overcoming the problem of easy access timeout, reducing the complexity of permission verification between different microservices, and improving the access efficiency of the microservice system.

[0187] The embodiment of the present invention also provides a microservice system access control device, which can implement the above-mentioned microservice system access control method, wherein the microservice system includes at least a first backend microservice and a second backend microservice, and the microservice system is configured so that different backend microservices can generate service authorization codes that can be used to access other backend microservices according to the request information of the requesting entity, referring to Fig.14 , the device comprises:

[0188] The first request receiving module 1410 is used for the first backend microservice to receive the first business request information of the request entity.

[0189] The first request response module 1420 is used for the first backend microservice to respond to the first business request information and generate first service response information and a service authorization code; wherein the first service response information is generated by the first backend microservice according to the first business request information; the first backend microservice is used to generate the service authorization code of at least one second backend microservice for the requesting entity.

[0190] The service authorization code sending module 1430 is used for the first backend microservice to send the first service response information and the service authorization code to the requesting entity.

[0191] The second request receiving module 1440 is used for the second backend microservice to receive the second business request information generated by the requesting entity based on the service authorization code.

[0192] The permission verification module 1450 is used for the second backend microservice to perform permission verification on the service authorization code.

[0193] The second request response module 1460 is used to generate second service response information by the second backend microservice in response to the second business request information according to the permission verification result.

[0194] The specific implementation of the microservice system access control device of this embodiment is basically the same as the specific implementation of the above-mentioned microservice system access control method, which will not be repeated here.

[0195] An embodiment of the present invention further provides an electronic device, including:

[0196] at least one memory;

[0197] at least one processor;

[0198] at least one program;

[0199] The program is stored in the memory, and the processor executes the at least one program to implement the microservice system access control method of the present invention. The electronic device can be any intelligent terminal including a mobile phone, a tablet computer, a personal digital assistant (PDA), a car computer, etc.

[0200] See also Fig.15 , Fig.15 The hardware structure of an electronic device of another embodiment is illustrated, and the electronic device includes:

[0201] The processor 1501 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present invention;

[0202] The memory 1502 can be implemented in the form of ROM (Read Only Memory), static storage device, dynamic storage device or RAM (Random Access Memory). The memory 1502 can store operating systems and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program codes are stored in the memory 1502, and the processor 1501 calls and executes the microservice system access control method of the embodiment of the present invention;

[0203] Input / output interface 1503, used to implement information input and output;

[0204] Communication interface 1504, used to realize communication interaction between the device and other devices, which can be realized through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.); and

[0205] A bus 1505 that transmits information between various components of the device (e.g., the processor 1501, the memory 1502, the input / output interface 1503, and the communication interface 1504);

[0206] The processor 1501 , the memory 1502 , the input / output interface 1503 and the communication interface 1504 are connected to each other in communication within the device via the bus 1505 .

[0207] An embodiment of the present application also provides a storage medium, which is a computer-readable storage medium. The storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned microservice system access control method is implemented.

[0208] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely disposed relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0209] The microservice system access control method, microservice system access control device, electronic device, and storage medium proposed in the embodiment of the present invention receive the first business request information of the request entity through the first backend microservice and respond to the first business request information, generate the first service response information and the service authorization code, and then send the service authorization code to the request entity, the second backend microservice receives the second business request information generated by the request entity based on the service authorization code; the service authorization code is verified by the second backend microservice, and if the verification passes, the second backend microservice is used to respond to the second business request information and generate the second service response information. The embodiment of the present application uses the first backend microservice to generate a service authorization code according to the first business request information, and when the next operation is required, the service authorization code is sent in combination with the second business request information, so that the second backend microservice uses the aforementioned generated service authorization code to directly verify the permissions, avoiding the need for each microservice to complete the entire authorization process of authorization-sending-verification when the same business requires multiple microservices to participate separately, overcoming the problem of easy access timeout, reducing the complexity of permission verification between different microservices, and improving the access efficiency of the microservice system.

[0210] The embodiments described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0211] Those skilled in the art will appreciate that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0212] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0213] Those skilled in the art will appreciate that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0214] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0215] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0216] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the above units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0217] The units described above as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0218] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0219] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including multiple instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store programs.

[0220] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but the scope of the rights of the present invention is not limited thereto. Any modification, equivalent substitution and improvement made by a person skilled in the art without departing from the scope and essence of the present invention should be within the scope of the rights of the present invention.

Claims

1. A microservice system access control method, characterized in that: The microservice system includes at least a first backend microservice and a second backend microservice, and the microservice system is configured so that different backend microservices can generate a service authorization code that can be used to access other backend microservices according to the request information of the requesting entity; The method comprises: The first backend microservice receives first business request information of the requesting entity, where the first business request information includes: requesting user information, operation file information, and file permission information; The first backend microservice responds to the first business request information and generates first service response information and a service authorization code; wherein the first service response information is generated by the first backend microservice according to the first business request information; the first backend microservice is used to generate the service authorization code of at least one second backend microservice to the requesting entity; The first backend microservice sends the first service response information and the service authorization code to the requesting entity; The second backend microservice receives the second business request information generated by the requesting entity based on the service authorization code; The second backend microservice performs permission verification on the service authorization code; According to the permission verification result, the second backend microservice responds to the second business request information and generates second service response information; The first backend microservice responds to the first business request information and generates first service response information and a service authorization code, including: The first backend microservice responds to the first business request information and generates first service response information; Using the authority control module to generate the service authorization code according to the first service request information; The first service request information also includes an access token, and the use of the permission control module to generate the service authorization code according to the first service request information includes: Using the permission control module to determine whether to authorize based on the access token; If the judgment result is authorization, the authority control module generates the service authorization code according to the preset authorization code format; The authority control module generates the service authorization code according to a preset authorization code format, including: Generate an authorization code parameter according to the first service request information, the authorization code parameter including: requesting user parameter, operation file parameter and file permission parameter; Based on the preset authorization code format, generate the service authorization code of the authorization code parameter; The second backend microservice performs permission verification on the service authorization code, including: Extracting the service authorization code from the second service request information, where the service authorization code is located at a preset position in the second service request information; Obtain the authorization code parameter in the service authorization code; If the authorization code parameters meet the permission verification conditions, the permission verification passes; If the authorization code parameter satisfies the permission verification condition, the permission verification is passed, including: If the current user is determined to be an authorized user according to the request user parameters, the first permission check is passed; If it is determined according to the operation file parameters that the file requested for operation is an authorized file, then the second permission check passes; If the file operation permission is determined to be an authorized interface according to the file permission parameter, the third permission check passes; If the first permission check passes, the second permission check passes, and the third permission check passes, the permission check passes.

2. A microservice system access control method according to claim 1, characterized in that: The operation file information includes: the operation document class name and the operation document number; the service authorization code generated by the authorization code parameter based on the preset authorization code format includes: Generate the operation file parameters according to the operation document class name and the operation document number, the operation file parameters include: operation document class parameters and operation document number parameters; The operation file parameters are concatenated with the request user parameters to obtain the first authorization code information; The service authorization code is obtained by concatenating the file permission parameter with the first authorization code information.

3. A microservice system access control method according to claim 1, characterized in that: After generating the service authorization code of the authorization code parameters based on the preset authorization code format, the method further includes: encrypting the service authorization code by using a preset encryption algorithm and a preset key to obtain the encrypted service authorization code.

4. A microservice system access control method according to claim 1, characterized in that: The request user information is a user session number.

5. A microservice system access control method according to claim 1, characterized in that: The service authorization code includes at least one of the file permission parameters, and different file permission parameters are generated by separating them using a preset separator.

6. A microservice system access control method according to claim 1, characterized in that: The second service request information is http / https request information, and the service authorization code is located in the URL information, request header information or request body information of the http / https request information.

7. A microservice system access control method according to claim 1, characterized in that: The sending the service authorization code to the requesting entity includes: sending the service authorization code to the requesting entity by means of parameter transmission.

8. A microservice system access control device, characterized in that: The microservice system includes at least a first backend microservice and a second backend microservice, and the microservice system is configured so that different backend microservices can generate a service authorization code that can be used to access other backend microservices according to the request information of the requesting entity; The device comprises: A first request receiving module, configured to receive first business request information of a requesting entity by a first backend microservice, wherein the first business request information includes: requesting user information, operation file information, and file permission information; A first request response module, configured for the first backend microservice to respond to the first business request information and generate first service response information and a service authorization code; wherein the first service response information is generated by the first backend microservice according to the first business request information; the first backend microservice is configured to generate the service authorization code of at least one second backend microservice to the requesting entity; A service authorization code sending module, used for the first backend microservice to send the first service response information and the service authorization code to the requesting entity; A second request receiving module, configured for a second backend microservice to receive second business request information generated by the requesting entity based on the service authorization code; An authority verification module is used for the second backend microservice to perform authority verification on the service authorization code; A second request response module, configured to generate second service response information by the second backend microservice in response to the second business request information according to the permission verification result; The first backend microservice responds to the first business request information and generates first service response information and a service authorization code, including: The first backend microservice responds to the first business request information and generates first service response information; Using the authority control module to generate the service authorization code according to the first service request information; The first service request information also includes an access token, and the use of the permission control module to generate the service authorization code according to the first service request information includes: Using the permission control module to determine whether to authorize based on the access token; If the judgment result is authorization, the authority control module generates the service authorization code according to the preset authorization code format; The authority control module generates the service authorization code according to a preset authorization code format, including: Generate an authorization code parameter according to the first service request information, the authorization code parameter including: requesting user parameter, operation file parameter and file permission parameter; Based on the preset authorization code format, generate the service authorization code of the authorization code parameter; The second backend microservice performs permission verification on the service authorization code, including: Extracting the service authorization code from the second service request information, where the service authorization code is located at a preset position in the second service request information; Obtain the authorization code parameter in the service authorization code; If the authorization code parameters meet the permission verification conditions, the permission verification passes; If the authorization code parameter satisfies the permission verification condition, the permission verification is passed, including: If the current user is determined to be an authorized user according to the request user parameters, the first permission check is passed; If it is determined according to the operation file parameters that the file requested for operation is an authorized file, then the second permission check passes; If the file operation permission is determined to be an authorized interface according to the file permission parameter, the third permission check passes; If the first permission check passes, the second permission check passes, and the third permission check passes, the permission check passes.

9. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the microservice system access control method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the microservice system access control method described in any one of claims 1 to 7 is implemented.

Images