Middleware service authorization method and device, electronic equipment and storage medium

Abstract

The application provides a kind of middle platform microservice authorization method, device, electronic equipment and storage medium, method includes: receiving the request call target middle platform microservice's calling request sent by first client;Based on the authentication credential carried by calling request, and the authorization strategy, protocol type and subscription relationship of target middle platform microservice, the first client is authenticated;In the case where authentication is passed, based on the protocol type of target middle platform microservice, calling request is forwarded to the application programming interface of target middle platform microservice.The middle platform microservice authorization method, device, electronic equipment and storage medium provided by the application are authenticated based on the authentication credential carried by calling request, and the authorization strategy, protocol type and subscription relationship of target middle platform microservice, the first client is authenticated, can realize the authentication and authorization of middle platform microservice in the middle platform microservice sharing scene, applicable to the security protection in the middle platform microservice sharing scene.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for authorizing microservices in a middleware platform. Background Technology

[0002] Currently, enterprise IT systems based on the middle platform concept are being used more and more widely.

[0003] The core technology of a middle platform is the reuse and sharing of microservices. This means that middle platform microservices can be invoked simultaneously by multiple clients, and are not limited to clients within the system to which they belong. During the reuse or sharing of middle platform microservices, client authentication is required to ensure the security of the call. Existing microservice authentication methods are typically designed for single-client microservice calls, a scenario characterized by a closed system, a single system provider, a consistent user permission system, and microservice calls within the same system. Microservice authentication in this scenario mainly involves integrating a microservice supporting a fixed authentication method (such as OAuth2, JWT, or session-based methods) on a gateway that supports the HTTP protocol, verifying the legitimacy of the requesting user to determine whether to forward the request.

[0004] Since microservices in middleware platforms are widely used in scenarios involving multiple protocols and open sharing, the authorization mechanism for microservices in middleware platforms is an issue that urgently needs to be addressed in this field. Summary of the Invention

[0005] This invention provides a method, apparatus, electronic device, and storage medium for authorizing microservices in a middleware platform, thereby overcoming the shortcomings of existing technologies in achieving authorization of microservices in a middleware platform and realizing authorization of microservices in a middleware platform.

[0006] In a first aspect, the present invention provides a method for authorizing microservices in a middleware platform, comprising:

[0007] Receive the request from the first client to invoke the target microservice in the middle platform;

[0008] The first client is authenticated based on the authentication credentials carried in the call request, as well as the authorization policy, protocol type, and subscription relationship of the target platform microservice.

[0009] If authentication is successful, the call request is forwarded to the application programming interface of the target platform microservice based on the protocol type of the target platform microservice.

[0010] In one embodiment, the protocol type of the target platform microservice includes HTTP or TCP.

[0011] In one embodiment, the authorization strategy of the target platform microservice includes application authentication, user authentication, or platform authentication.

[0012] In one embodiment, authenticating the first client based on the authentication credentials carried in the call request, and the authorization policy, protocol type, and subscription relationship of the target platform microservice, specifically includes:

[0013] When the protocol type of the target platform microservice is TCP, the authentication credentials carried in the call request are obtained based on the authorization policy of the target platform microservice, the secure transport layer protocol, and the server name indication.

[0014] The first client is authenticated based on the authentication credentials and the subscription relationship of the target platform microservice.

[0015] In one embodiment, before receiving the request from the first client to invoke the target microservice, the method further includes:

[0016] Receive a registration request sent by an electronic device that provides the target platform microservice;

[0017] In response to the registration request, the target key is sent to the electronic device, and the interface information of the target middleware microservice is published;

[0018] The registration request carries the authorization policy and protocol type of the target middleware microservice; the interface information includes the authorization policy, protocol type, and corresponding identifier of the target middleware microservice.

[0019] In one embodiment, after responding to the registration request and publishing the interface information of the target platform microservice, the method further includes:

[0020] Receive subscription requests sent by the second client;

[0021] In response to the subscription request, update the subscription relationship of the target platform microservice.

[0022] The subscription request is used to subscribe to the target middleware microservice.

[0023] In one embodiment, after forwarding the call request to the application programming interface of the target platform microservice based on the protocol type of the target platform microservice upon successful authentication, the method further includes:

[0024] The response data of the call request returned by the application programming interface of the target middleware microservice is forwarded to the first client;

[0025] The response data is generated by the electronic device providing the target platform microservice after determining that the authentication credential is valid.

[0026] Secondly, the present invention provides a middleware microservice authorization device, comprising:

[0027] The receiving module is used to receive the request sent by the first client to invoke the target microservice in the middle platform;

[0028] The authorization module is used to authenticate the first client based on the authentication credentials carried in the call request, as well as the authorization policy, protocol type, and subscription relationship of the target middleware microservice;

[0029] The forwarding module is used to forward the call request to the application programming interface of the target platform microservice based on the protocol type of the target platform microservice when authentication is successful.

[0030] Thirdly, the present invention provides an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the computer program to implement the steps of any of the above-described microservice authorization methods.

[0031] Fourthly, the present invention provides a processor-readable storage medium storing a computer program for causing the processor to execute the steps of any of the above-described microservice authorization methods.

[0032] The present invention provides a method, apparatus, electronic device, and storage medium for authorizing microservices in a middleware platform. Based on the authentication credentials carried in the call request, as well as the authorization policy, protocol type, and subscription relationship of the target middleware platform microservice, it authenticates the first client. It can realize the authentication and authorization of middleware platform microservices in the middleware platform microservice sharing scenario. It is suitable for security protection in the middleware platform microservice sharing scenario, especially for microservice sharing in the complex business middleware construction scenario where the capability builder and consumer are from different contractors. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0034] Figure 1 This is a flowchart illustrating the microservice authorization method for the middle platform provided by the present invention;

[0035] Figure 2This is a schematic diagram of the association model provided by the present invention;

[0036] Figure 3 This is one of the schematic diagrams of the microservice authorization process provided by the present invention;

[0037] Figure 4 This is a schematic diagram illustrating the implementation of the TLS mechanism provided by this invention;

[0038] Figure 5 This is a flowchart illustrating the registration process of the target middleware microservice provided by the present invention;

[0039] Figure 6 This is a schematic diagram of the transparent transmission channel provided by the present invention;

[0040] Figure 7 This is the second schematic diagram of the authorization process for the microservices in the middle platform provided by the present invention;

[0041] Figure 8 This is a flowchart illustrating the authentication and forwarding steps provided by the present invention;

[0042] Figure 9 This is a schematic diagram of the protocol type identification process provided by the present invention;

[0043] Figure 10 This is a signaling diagram of the authorization process for a middleware microservice based on the HTTP protocol provided by this invention;

[0044] Figure 11 This is one of the structural schematic diagrams of the microservice authorization device for the middle platform provided by the present invention;

[0045] Figure 12 This is the second structural schematic diagram of the microservice authorization device for the middle platform provided by the present invention;

[0046] Figure 13 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0048] The following is combined Figures 1-13 The present invention describes a method, apparatus, electronic device, and storage medium for authorizing microservices in a middleware platform.

[0049] Figure 1This is a flowchart illustrating the microservice authorization method for the middle platform provided by this invention. The following is a combination of... Figure 1 This application describes the microservice authorization method for the middleware platform provided in its embodiments. For example... Figure 1 As shown, the method includes: step 101, receiving a request from the first client to invoke the target middleware microservice.

[0050] Specifically, the execution entity of the microservice authorization method for the middle platform provided in this embodiment of the invention is the microservice authorization device for the middle platform provided by this invention. In this embodiment of the invention, the client is the capability consumer of the microservice, and the electronic device providing the target middle platform microservice is the capability provider of the microservice. The microservice authorization device for the middle platform has at least the function of a gateway, and can realize functions such as data forwarding between the client and the electronic device providing the target middle platform microservice.

[0051] The middleware microservice authorization device typically serves as the unified entry and exit point for providing services to the outside world within an enterprise's business middleware platform. All requests are routed and forwarded through this gateway. Preferably, the middleware microservice authorization device can be used to centrally manage registration information, subscription relationship information, application service association information, and authentication credential information.

[0052] Capability providers are responsible for identifying, refining, and releasing capabilities, and are generally composed of various backend systems after being microservice-based.

[0053] Capability consumers are typically electronic devices running front-end applications. These front-end applications can be simple web pages, mobile apps, desktop clients, or other services responsible for subscribing to and invoking capabilities.

[0054] Essentially, the middle platform is an "enterprise-level capability reuse platform." The middle platform digitizes and accumulates the core capabilities of an enterprise as its business continues to develop. It abstracts the common needs of enterprises and builds them into platform-based and component-based system capabilities. This forms an operational system centered on services and built from business, data, and technology in a closed loop. This enables enterprises to quickly and flexibly call resources to build solutions for specific problems, empowering business innovation and iteration.

[0055] The core technology of the middle platform is capability reuse and sharing. It is a future-oriented IT architecture system. By accumulating common capabilities of business, data and technology, it forms basic enterprise capability "building blocks". Through standardized interface opening, it uses limited "building blocks" to build unlimited possibilities. Through continuous iteration and optimization, it effectively supports intelligent operation.

[0056] When the first client needs to invoke the target platform microservice, it sends an invocation request to the platform microservice authorization device. This invocation request is a request to invoke the target platform microservice.

[0057] The middleware microservice authorization device can receive this call request.

[0058] Enterprise middleware microservices can be shared in a variety of ways, including traditional HTTP-based RESTful, Webservice, and Websocket interfaces, as well as TCP-based SOCKET long-connection interfaces.

[0059] In this embodiment of the invention, the association model shown in Figure 2 is an application-service-endpoint-version association model.

[0060] In this invention, the application (short for application program) serves as the subject of microservice sharing or capability consumption, the owner of managed resources, and the primary authentication target of the microservice authorization method and apparatus of the middle platform. The application in this embodiment is a middle platform application.

[0061] A middle-platform application can be decomposed into at least one middle-platform microservice. A middle-platform microservice (which may be simply referred to as a "service" in various embodiments of this invention) is a unified logical name for one or more identical microservice processes (service instances). The middle-platform microservice is uniformly published by the application.

[0062] An endpoint (i.e., an API, or Application Programming Interface) is a logical abstraction of a microservice. An endpoint defines what capabilities are shared externally and how they are presented; endpoints are published uniformly by the application.

[0063] Version refers to the instance version of an endpoint. Different services provide services for the same endpoint, thus forming multiple versions of the endpoint. Different versions can define a traffic distribution scheme for consuming the shared service according to the policy.

[0064] like Figure 2 As shown, all existing endpoints (APIs) will be converged into RESTful endpoints, while three types of endpoints will be expanded: WebSocket, Webservice, and TCP.

[0065] Since Restful, Webservice, and WebSocket can all be considered specific manifestations or upgrades of the HTTP protocol, they can be extended to support microservice gateways.

[0066] By establishing an "application-service-endpoint-version" association model, the interface types of shared microservices are expanded, which can support the automatic expansion of the authentication process in the form of plug-ins.

[0067] Optionally, the source of authentication information can be expanded: from obtaining it only from the request header to obtaining it from the request header or query parameters, in order to support authentication, authorization, flow control and other functions before the WebSocket handshake.

[0068] Optionally, additional WSDL requests can be supported for the Webservice extension to ensure the correctness of the access address when generating client code based on the WSDL.

[0069] Furthermore, an interface for creating and editing WebSocket and Webservice endpoints can be added.

[0070] Step 102: Authenticate the first client based on the authentication credentials carried in the call request, as well as the authorization policy, protocol type, and subscription relationship of the target middleware microservice.

[0071] Specifically, the authentication credential can carry information about the first client and the target platform microservice. The authentication credential corresponds to the authorization policy and protocol type of the target platform microservice. Different combinations of protocol types and authorization policies correspond to different authentication credentials.

[0072] The middleware microservice authorization device can support multiple authentication methods to meet different security sharing requirements. The authorization policy is one of the multiple authentication methods.

[0073] The present invention does not specifically limit the protocol type of the target platform microservice. For example, the protocol type of the target platform microservice can be any one of the following: HTTP-based RESTful, Webservice, and WebSocket interfaces, or TCP-based SOCKET long-connection interfaces. The protocol type of the target platform microservice can also be any extended protocol of HTTP or TCP.

[0074] The middleware microservice authorization device can extract authentication credentials from the call request based on the protocol type and authorization policy of the target middleware microservice.

[0075] Based on authentication credentials and subscription relationships, the first client is authenticated to determine whether the call request is a legitimate request, i.e., whether it has the authority to request and call the target platform microservice.

[0076] The first client calls the target platform microservice through the first application. The second application refers to the application corresponding to the target platform microservice. The target platform microservice is obtained by splitting the second application.

[0077] The subscription relationship of the target platform microservice includes information about the first application subscribing to the target platform microservice. If the first application successfully subscribes to the target platform microservice, it has the permission to call the target platform microservice. Requests from clients running the first application to call the target platform microservice are legitimate and authentication passes. Requests from clients running third applications that have not subscribed to the target platform microservice are illegitimate and authentication fails.

[0078] Step 103: If authentication is successful, forward the call request to the application programming interface of the target microservice based on the protocol type of the target microservice.

[0079] Specifically, if authentication is successful, the call request can be forwarded to the application programming interface (API, which may be referred to as interface or endpoint in various embodiments of the present invention) of the target middleware microservice through the gateway corresponding to the protocol type of the target middleware microservice, thereby authorizing the first client to call the target middleware microservice.

[0080] After receiving the call request, the middleware microservice authorization device verifies the legitimacy of the capability consumer application and forwards the call after performing a second service signature.

[0081] During the process of forwarding a call request by the middleware microservice authorization device, the call request can be double-signed, and the double-signed call request can be forwarded to the application programming interface of the target middleware microservice.

[0082] Optionally, performing secondary signature may include secondary signature based on user ID, so that the secondary signature call request carries the user ID.

[0083] This invention, based on the authentication credentials carried in the call request, as well as the authorization policy, protocol type, and subscription relationship of the target microservice, authenticates the first client. It can realize the authentication and authorization of microservices in the microservice sharing scenario, and is suitable for security protection in the microservice sharing scenario, especially in the microservice sharing scenario of complex business microservice construction where the capability builder and consumer are from different contractors.

[0084] Based on any of the above embodiments, the protocol type of the target platform microservice includes HTTP protocol or TCP protocol.

[0085] Specifically, the middleware microservice authorization device can support multiple communication protocols. These protocols include both HTTP and TCP protocols.

[0086] Accordingly, the platform microservice authorization device can be divided into multiple types of gateways based on different interface protocol types. The platform microservice authorization device can include HTTP gateways and TCP gateways. HTTP gateways are used to authorize HTTP traffic, while TCP gateways are used to authorize TCP traffic. The TCP gateway is a gateway added in this embodiment of the invention.

[0087] When the target microservice uses the HTTP protocol, the authentication credentials carried in the call request can include three parameters: the first application ID (app-id), the timestamp, and the signature.

[0088] The timestamp is the current timestamp when the first application initiated the call. The first application ID is the ID of the first application.

[0089] Optionally, the signature can be generated based on the first application ID, the aforementioned timestamp, and the second application ID. The second application ID is the ID of the second application.

[0090] For example, the signature generation steps include: concatenating the first application ID, the aforementioned timestamp, and the second application ID with a comma, and then encrypting them with MD5 code to convert them into a hexadecimal uppercase string as the signature.

[0091] Optionally, the authentication credentials may also include a user ID. The user ID can be extracted from the JWT token carried in the proxy request.

[0092] When the target microservice uses the TCP protocol, the authentication credentials carried in the call request may include the first application ID.

[0093] Optionally, the authentication credentials may also include the ID of the second application and the ID of the target platform microservice.

[0094] Optionally, authentication credentials may also include user certificates.

[0095] By supporting the TCP protocol, this invention enables authentication and authorization of TCP-based microservices in a middleware platform, and solves the technical challenge of centralized management and control of TCP-based long-lived SOCKET connections.

[0096] Based on any of the above embodiments, the authorization strategy for the target platform microservice includes application authentication, user authentication, or platform authentication.

[0097] Specifically, such as Figure 3 As shown, embodiments of the present invention support at least three freely combinable authentication modes: application authentication, user authentication, and platform authentication, which can flexibly adapt to different levels of security sharing requirements and support the simultaneous invocation of the same microservice by multiple clients.

[0098] Application authentication refers to using a first application as the authentication object. Accordingly, the authentication credentials include the certificate (or first ID) of the first application and the signature (i.e., the key of the second application) of the second application.

[0099] The application certificate refers to the digital certificate issued to the application by the microservice authorization device in the TCP protocol middleware using a CA certificate. It represents the application's identity and serves as the application's identification information.

[0100] Application ID refers to a unique identifier issued by the middleware microservice authorization device under the HTTP protocol to a second application.

[0101] The application signature (key) is a unique application key issued to the registered application by the platform's microservice authorization device and is not disclosed to the public.

[0102] User authentication refers to using the first client as the authentication object. Authentication credentials include user certificates. For example, a user certificate can be a JWT token. The JWT token is used to encrypt and encapsulate user information using the JWT protocol, serving as the user's identification information.

[0103] All of the above authentication credentials are encrypted during transmission (optional, symmetric and asymmetric encryption are supported), ensuring high security.

[0104] Platform authentication refers to the fact that the authorization device of the middleware microservice defaults to authenticating any call request as successful, without processing the call request itself, and directly passes it to the electronic device providing the target middleware microservice, leaving the actual authentication process to that electronic device. Platform authentication is particularly suitable for scenarios involving pure front-end page calls, preventing unauthorized cracking caused by loading authentication credential information into the front-end.

[0105] The embodiments of the present invention support at least three freely combinable authentication modes: application authentication, user authentication, and platform authentication, which can more flexibly adapt to different levels of security sharing requirements.

[0106] Based on any of the above embodiments, the first client is authenticated based on the authentication credentials carried in the call request, as well as the authorization policy, protocol type, and subscription relationship of the target platform microservice. Specifically, this includes: if the protocol type of the target platform microservice is TCP, obtaining the authentication credentials carried in the call request based on the authorization policy of the target platform microservice, the secure transport layer protocol, and the server name indication; and authenticating the first client based on the authentication credentials and the subscription relationship of the target platform microservice.

[0107] Specifically, when the target platform microservice uses the TCP protocol, the platform microservice authorization device can add a layer of TLS (Transport Layer Security Protocol) security protection on top of the original TCP connection. During the TLS handshake phase, it verifies the authenticity of the client certificate issued to the application and extracts the application ID carried in the certificate. Then, it performs secondary filtering by querying the subscription relationship.

[0108] Furthermore, by introducing SNI (Server Name Indication) technology, the application ID and service ID of the invoked application are added to the Host information submitted during the TLS handshake phase. The TCP gateway extracts this information to perform routing. If the authorization policy of the target microservice is user authentication, JWT token information can be added to the Host information. Moreover, flow control can be implemented by controlling the number of connections.

[0109] like Figure 4 As shown, the TLS mechanism can be implemented in two ways: the first is by modifying the code on the first client side to add TLS support, that is, by adding code related to secure transport to implement secure sockets; the second is by adding a local TLS proxy (such as...). Figure 4 The Envoy method in the database allows you to delegate connection requests to a proxy without modifying the code on the first client side.

[0110] This invention, by introducing TLS+SNI security control technology, can achieve authentication and routing by verifying the certificate and SNI information carried by the client during the TLS handshake phase, thus solving the technical problem of centralized management of long-lived TCP-based SOCKET connections.

[0111] Based on any of the above embodiments, before receiving the request from the first client to invoke the target middleware microservice, the method further includes: receiving a registration request from the electronic device providing the target middleware microservice.

[0112] The registration request includes the authorization policy and protocol type of the target middleware microservice.

[0113] Specifically, prior to step 101, the middleware microservice authorization device can perform the registration steps for the target middleware microservice.

[0114] Users can send a registration request to the authorized device of the platform microservice through the electronic device that provides the target platform microservice, requesting the addition of a new platform microservice, namely the target platform microservice.

[0115] In response to the registration request, the target key is sent to the electronic device, and the interface information of the target middleware microservice is published.

[0116] The interface information includes the authorization policy, protocol type, and corresponding identifier of the target platform microservice.

[0117] Specifically, after receiving a registration request, the microservice authorization device in the middle platform can assign the ID (i.e., identifier) ​​and key of the second application if the registration is successful. The ID of the second application is the identifier corresponding to the target microservice in the middle platform.

[0118] After allocating the key for the second application, the key of the second application can be used as the target key to return the target key to the electronic device that provides the target platform microservice.

[0119] After allocating the key for the second application, the interface information of the target platform microservices can be distributed.

[0120] The interface information of the target platform microservice can include the application to which the target platform microservice belongs, API name, professional type, authorization policy, and protocol type.

[0121] like Figure 5 As shown, the registration process for the target platform microservice may include the following steps:

[0122] Step 501: Log in to the platform and complete the application information registration and creation.

[0123] After a user logs into the target platform on the microservice authorization device in the middleware, a new application is added, namely the second application.

[0124] Optionally, you can enter the application's unique name, Chinese name, description, developer, contact person, contact person's phone number, contact person's email address, and domain information in the interface.

[0125] Step 502: Apply for application launch. After completing the administrator's review, you will obtain the application ID and key.

[0126] After completing the information entry, you can submit a deployment application to trigger the approval process. Once approved by the administrator, the target platform will automatically assign an application ID and a key. Optionally, the application ID is a randomly generated 32-bit UUID (Universally Unique Identifier). Optionally, the key is a random string encrypted with AES. Both guarantee global uniqueness. The application ID and key serve as the application's legitimate identity credentials, allowing it to consume successfully subscribed microservices.

[0127] Step 503: Register and publish API information, and determine the protocol type and authorization policy.

[0128] In this embodiment of the invention, the target key is sent to the electronic device in response to the registration request, and the interface information of the target middleware microservice is published. The publishing and consumption operations are standardized, and the work of microservices that originally required adding complex configuration and authentication is decomposed. On the one hand, the application certificate (ID) and application signature (key) carried in the request are used as authentication credentials for identity verification. On the other hand, the subscription relationship is used for permission control, which simplifies the authentication process.

[0129] Based on any of the above embodiments, after publishing the interface information of the target middleware microservice in response to the registration request, the method further includes: receiving a subscription request sent by a second client.

[0130] The subscription request is used to subscribe to the target platform microservice.

[0131] Specifically, after the target platform microservice is published, the platform microservice authorization device can perform the registration steps of the target platform microservice.

[0132] The second client can first perform the step of registering the third application. The third application refers to the application running on the second client that is used to call the target platform microservices. The steps for registering the third application are similar to those for registering the second application, and will not be repeated here.

[0133] The second client can send a subscription request to the microservice authorization device of the target platform based on the interface information of the target platform microservice. The subscription request can carry the ID of the third application.

[0134] Understandably, the first client can also act as the second client, subscribing to the target platform microservices. Correspondingly, the third application is the first application.

[0135] Optionally, the subscription request may include the subscription period.

[0136] In response to a subscription request, update the subscription relationship of the target platform microservice.

[0137] Specifically, after receiving a registration request, the middleware microservice authorization device can update the subscription relationship of the target middleware microservice and add the ID of the third application to the allowed list of the target middleware microservice.

[0138] This invention, in response to subscription requests, updates the subscription relationship of the target platform microservice, standardizes publishing and consumption operations, and decomposes the work of microservices that originally required adding complex configurations and authentication. On the one hand, it uses the application certificate (ID) and application signature (key) carried in the request as authentication credentials for identity verification; on the other hand, it uses the subscription relationship for access control, which simplifies the authentication process.

[0139] Based on any of the above embodiments, if authentication is successful, after forwarding the call request to the application programming interface of the target middleware microservice based on the protocol type of the target middleware microservice, the method further includes: forwarding the response data of the call request returned by the application programming interface of the target middleware microservice to the first client.

[0140] Among them, response data is generated by electronic devices that provide target platform microservices, provided that the authentication credentials are valid.

[0141] Specifically, the electronic device (which can be called the server) that provides the target microservice platform can re-verify the call request forwarded by the microservice platform authorization device.

[0142] The electronic device of the target platform microservice can verify the legitimacy of the authentication credentials carried in the call request based on the key of the second application.

[0143] If the verification passes, the target platform microservice can be executed, and the response data of the call request can be returned to the first client through the platform microservice authorization device; if the verification fails, the target platform microservice will not be executed, and the result of call failure or lack of permission to call can be returned to the first client through the platform microservice authorization device, or no result can be returned.

[0144] Optionally, after successful authentication, if the target microservice's protocol type is TCP, the microservice authorization device adds a corresponding TCP pass-through channel for the call request (e.g., ...). Figure 6 (As shown). This transparent channel is used for data transmission between the first client and the application programming interface (API) of the target middleware microservice. Therefore, the call request can also be transmitted to the API of the target middleware microservice through this transparent channel.

[0145] When the target platform microservice uses the TCP protocol, the response data can be directly returned to the first client through this transparent channel.

[0146] The embodiments of the present invention provide a secondary verification of the call request by an electronic device that provides the target microservice, which can further improve the security of the authorization of the microservice.

[0147] To facilitate understanding of the above embodiments of the present invention, the complete process of authorization for microservices in the middle platform is described below. For example... Figure 7 As shown, the authorization process for microservices in the middle platform can include the following steps:

[0148] Step 701: The capability provider registers the second application, publishes the target middleware microservice, and determines the protocol type and authorization policy of the target middleware microservice.

[0149] Step 702: The capability consumer registers the first application and subscribes to the target middleware microservice.

[0150] Step 703: The capability consumer accesses the mid-platform microservice through the mid-platform microservice authorization device according to the protocol type and authorization policy of the target mid-platform microservice.

[0151] Step 704: The middleware microservice authorization device verifies the legality of the request based on the subscription relationship, protocol type, and authorization policy, and then routes and forwards the request.

[0152] Step 705: The capability provider performs a secondary verification on the server side according to the authorization policy, and returns response data after passing the verification.

[0153] like Figure 8 As shown, step 704 may include the following steps:

[0154] Step 801: The gateway service determines the protocol type of the call request.

[0155] The process by which the gateway service of the microservice authorization device in the middle platform determines the protocol type of the call request is as follows: Figure 9 As shown.

[0156] Optionally, request traffic can be routed according to protocol type through a front-end Nginx, and HTTP traffic can be authorized through a microservice gateway, while TCP traffic can be authorized through a TCP gateway.

[0157] Preferably, the protocol type is distinguished by the port number on the Nginx side.

[0158] Optionally, the TCP gateway and HTTP gateway can be deployed within the K8S container cluster, and Istio IngressGateway can be used to distribute traffic according to protocol type.

[0159] By introducing gateways with different protocols, and using front-end devices to distribute request traffic according to protocol type, automatic identification of the two protocol types can be achieved.

[0160] Step 802: When the call request is a TCP protocol, the gateway service verifies the certificate and SNI during the first TLS handshake; when the call request is an HTTP protocol, the gateway service will authenticate the first client according to the different authorization policies.

[0161] When the call request is a TCP protocol, the gateway service authenticates the certificate when the application performs a TLS handshake with the gateway service for the first time. After successful authentication, the gateway service obtains the information of the target server from the SNI context and performs authentication and routing for this call based on this information.

[0162] When the call request is made using the HTTP protocol, the gateway service will authenticate the first client based on the different authorization modes of the shared capabilities being called.

[0163] Step 803: The gateway service processes the authentication results.

[0164] When authentication fails, the gateway service immediately returns a request failure message to the first client. Upon successful authentication, the gateway service adds a corresponding TCP pass-through channel for TCP protocol calls, eliminating the need for further authentication for subsequent data transmissions. Therefore, the first client can continuously obtain response data from the shared capabilities through the TCP channel. For HTTP protocol calls, the gateway service routes the request to the target microservice's interface.

[0165] Figure 10 This example demonstrates the authorization process for microservices in a middleware platform based on the HTTP protocol.

[0166] The following describes the microservice authorization device for the middle platform provided by the present invention. The microservice authorization device described below and the microservice authorization method described above can be referred to in correspondence.

[0167] Figure 11 This is one of the structural schematic diagrams of the microservice authorization device for the middle platform provided by the present invention. Based on the content of any of the above embodiments, such as... Figure 11 As shown, the microservice authorization device in the middleware platform includes a receiving module 1101, an authorization module 1102, and a forwarding module 1103, wherein:

[0168] The receiving module 1101 is used to receive the request sent by the first client to invoke the target middleware microservice;

[0169] The authorization module 1102 is used to authenticate the first client based on the authentication credentials carried in the call request, as well as the authorization policy, protocol type and subscription relationship of the target middleware microservice;

[0170] The forwarding module 1103 is used to forward the call request to the application programming interface of the target middleware microservice based on the protocol type of the target middleware microservice when the authentication is successful.

[0171] Specifically, the receiving module 1101, the authorization module 1102, and the forwarding module 1103 are electrically connected in sequence.

[0172] When the first client needs to invoke the target platform microservice, it sends an invocation request to the platform microservice authorization device. This invocation request is a request to invoke the target platform microservice.

[0173] The receiving module 1101 can receive the call request.

[0174] The authorization module 1102 can authenticate the first client based on the authentication credentials and subscription relationship, and determine whether the call request is a legitimate call request, that is, whether it has the permission to request to call the target middleware microservice.

[0175] If authentication is successful, the forwarding module 1103 can forward the call request to the application programming interface of the target platform microservice through the gateway corresponding to the protocol type of the target platform microservice, thereby authorizing the first client to call the target platform microservice.

[0176] Optionally, the protocol type of the target platform microservice may include HTTP or TCP.

[0177] Optionally, the authorization strategy for the target platform microservices may include application authentication, user authentication, or platform authentication.

[0178] Optionally, the authorization module 1102 can be specifically used for:

[0179] When the target platform microservice uses TCP as its protocol type, the authentication credentials carried in the call request are obtained based on the authorization policy of the target platform microservice, the secure transport layer protocol, and the server name indication.

[0180] The first client is authenticated based on the authentication credentials and the subscription relationship of the target platform microservice.

[0181] Optionally, the middleware microservice authorization device may also include:

[0182] The registration module is used to receive registration requests from electronic devices that provide the target platform microservices; in response to the registration requests, it sends the target key to the electronic devices and publishes the interface information of the target platform microservices.

[0183] The registration request carries the authorization policy and protocol type of the target middleware microservice; the interface information includes the authorization policy, protocol type and corresponding identifier of the target middleware microservice.

[0184] Optionally, the middleware microservice authorization device may also include:

[0185] The subscription module is used to receive subscription requests sent by the second client; in response to the subscription request, it updates the subscription relationship of the target middleware microservice.

[0186] The subscription request is used to subscribe to the target platform microservice.

[0187] Optionally, the forwarding module 1103 can also be used to forward the response data of the call request returned by the application programming interface of the target middleware microservice to the first client;

[0188] Among them, response data is generated by electronic devices that provide target platform microservices, provided that the authentication credentials are valid.

[0189] Figure 12 This is the second structural schematic diagram of the microservice authorization device provided by the present invention.

[0190] The part consisting of receiving module 1101, authorization module 1102 and forwarding module 1103 can be called a capability gateway.

[0191] like Figure 12 As shown, the microservice authorization device in the middleware platform may further include a registration module 1204 and a storage module 1205. The registration module 1204 is electrically connected to the receiving module 1101, the authorization module 1102, and the storage module 1205, respectively. The storage module 1205 is also electrically connected to the authorization module 1102 and the forwarding module 1103, respectively.

[0192] The receiving module 1101 can be used to receive call requests, extract the protocol type and authentication credentials carried in the call request, and determine the authentication mode (i.e., authorization policy) to be used. Optionally, different protocol types can be distinguished based on the port and routed to different protocol gateways.

[0193] The authorization module 1102 may include TCP authentication unit 1210 and TCP authentication unit 1220.

[0194] The authorization module 1102 includes: TCP authentication unit 1210 and TCP authentication unit 1220.

[0195] TCP authentication unit 1210 is used for authentication of long-connection requests based on the TCP protocol: verifying the validity of the client certificate during the TLS handshake phase and extracting the application ID carried in the certificate; and performing route identification and authorization verification by introducing SNI (Server Name Indication) technology.

[0196] TCP authentication unit 1220 is used for authentication of HTTP protocol requests, verifying the application signature and JWT token to determine the legitimacy of the request. Furthermore, it determines whether the user has the necessary permissions based on the subscription relationship.

[0197] The forwarding module 1103 includes a TCP forwarding unit 1230 and an HTTP forwarding unit 1240.

[0198] TCP forwarding unit 1230 is used to forward TCP requests after successful authentication. Optionally, after successful authentication, a new TCP transparent channel is added to the target microservice, and data is transmitted through this channel.

[0199] The HTTP forwarding unit 1240 is used to forward HTTP requests after successful authentication. Optionally, after successful authentication, the HTTP request is encapsulated again and forwarded to the interface of the target microservice.

[0200] The registration module 1204 is used to register application, microservice, and API capability information. It also handles the relationships between these three, as well as the subscription relationships between applications and APIs. Furthermore, it associates authentication parameter information (i.e., authentication credentials) according to different authentication strategies. Optionally, the registration module 1204 is also used to issue client certificates under the TCP protocol or application IDs and keys under the HTTP protocol.

[0201] The storage module 1205 is used to store relevant information registered by the registration module, including application key information and CA root certificate information.

[0202] The microservice authorization device provided in this embodiment of the invention is used to execute the microservice authorization method of the present invention. Its implementation method is the same as that of the microservice authorization method of the present invention, and it can achieve the same beneficial effects. It will not be described again here.

[0203] This platform microservice authorization device is used in the platform microservice authorization methods of the foregoing embodiments. Therefore, the descriptions and definitions in the platform microservice authorization methods of the foregoing embodiments can be used to understand the execution modules in the embodiments of the present invention.

[0204] This invention, based on the authentication credentials carried in the call request, as well as the authorization policy, protocol type, and subscription relationship of the target microservice, authenticates the first client. It can realize the authentication and authorization of microservices in the microservice sharing scenario, and is suitable for security protection in the microservice sharing scenario, especially in the microservice sharing scenario of complex business microservice construction where the capability builder and consumer are from different contractors.

[0205] The electronic device and storage medium provided by the present invention are described below. The electronic device and storage medium described below can be referred to in correspondence with the microservice authorization method of the middle platform described above.

[0206] Figure 13 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 13As shown, the electronic device may include a processor 1310, a communication interface 1320, a memory 1330, and a communication bus 1340, wherein the processor 1310, the communication interface 1320, and the memory 1330 communicate with each other via the communication bus 1340. The processor 1310 can call a computer program in the memory 1330 to execute the steps of the microservice authorization method, such as: receiving a request from a first client to invoke a target microservice; authenticating the first client based on the authentication credentials carried in the request, as well as the authorization policy, protocol type, and subscription relationship of the target microservice; and, if authentication is successful, forwarding the request to the application programming interface of the target microservice based on the protocol type of the target microservice.

[0207] Furthermore, the logical instructions in the aforementioned memory 1330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0208] On the other hand, the present invention also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can perform the steps of the middleware microservice authorization method provided by the above methods, such as: receiving a request from a first client to invoke a target middleware microservice; authenticating the first client based on the authentication credentials carried in the request, as well as the authorization policy, protocol type, and subscription relationship of the target middleware microservice; and, if the authentication is successful, forwarding the request to the application programming interface of the target middleware microservice based on the protocol type of the target middleware microservice.

[0209] On the other hand, embodiments of this application also provide a processor-readable storage medium storing a computer program. The computer program is used to cause the processor to execute the steps of the methods provided in the above embodiments, such as: receiving a request from a first client to invoke a target microservice; authenticating the first client based on the authentication credentials carried in the request, as well as the authorization policy, protocol type, and subscription relationship of the target microservice; and, if authentication is successful, forwarding the request to the application programming interface of the target microservice based on the protocol type of the target microservice.

[0210] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0211] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0212] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0213] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for authorizing microservices in a middleware platform, characterized in that, The method, applied to a mid-platform microservice authorization device, includes: Receive the request from the first client to invoke the target microservice in the middle platform; The first client is authenticated based on the authentication credentials carried in the call request, as well as the authorization policy, protocol type, and subscription relationship of the target platform microservice. If authentication is successful, the call request is forwarded to the application programming interface of the target platform microservice based on the protocol type of the target platform microservice. The authentication of the first client based on the authentication credentials carried in the call request, as well as the authorization policy, protocol type, and subscription relationship of the target platform microservice, specifically includes: When the protocol type of the target platform microservice is TCP, the authentication credentials carried in the call request are obtained based on the authorization policy of the target platform microservice, the secure transport layer protocol, and the server name indication. The first client is authenticated based on the authentication credentials and the subscription relationship of the target platform microservice; The method further includes, after receiving the registration request: Receive a subscription request sent by a second client; the subscription request carries the subscription validity period; In response to the subscription request, update the subscription relationship of the target platform microservice; wherein, the subscription request is used to subscribe to the target platform microservice; In the case where the protocol type of the target platform microservice is TCP, the platform microservice authorization device adds a layer of security protection of the transport layer protocol on top of the original TCP connection, and adds the application ID and service ID information to the Host information submitted in the handshake phase of the transport layer protocol by introducing server name indication technology.

2. The microservice authorization method for a middleware platform according to claim 1, characterized in that, The authorization strategies for the target platform microservices include application authentication, user authentication, or platform authentication.

3. The microservice authorization method for a middle platform according to claim 1, characterized in that, Before receiving the request from the first client to invoke the target microservice of the middle platform, the method further includes: Receive a registration request sent by an electronic device that provides the target platform microservice; In response to the registration request, the target key is sent to the electronic device, and the interface information of the target middleware microservice is published; The registration request carries the authorization policy and protocol type of the target middleware microservice; the interface information includes the authorization policy, protocol type, and corresponding identifier of the target middleware microservice.

4. The method for authorizing microservices in a middleware platform according to any one of claims 1 to 3, characterized in that, If authentication is successful, after forwarding the call request to the application programming interface of the target platform microservice based on the protocol type of the target platform microservice, the method further includes: The response data of the call request returned by the application programming interface of the target middleware microservice is forwarded to the first client; The response data is generated by the electronic device providing the target platform microservice after determining that the authentication credential is valid.

5. A middleware microservice authorization device, characterized in that, include: The receiving module is used to receive the request sent by the first client to invoke the target microservice in the middle platform; The authorization module is used to authenticate the first client based on the authentication credentials carried in the call request, as well as the authorization policy, protocol type, and subscription relationship of the target middleware microservice; The forwarding module is used to forward the call request to the application programming interface of the target platform microservice based on the protocol type of the target platform microservice when authentication is successful. The authorization module is specifically used to: when the protocol type of the target platform microservice is TCP protocol, obtain the authentication credentials carried in the call request based on the authorization policy of the target platform microservice, and on the basis of the secure transport layer protocol and server name indication; The first client is authenticated based on the authentication credentials and the subscription relationship of the target platform microservice; The subscription module is used to receive subscription requests sent by the second client; The subscription request carries the subscription activation period; In response to the subscription request, update the subscription relationship of the target platform microservice; wherein, the subscription request is used to subscribe to the target platform microservice; In the case where the protocol type of the target platform microservice is TCP, the platform microservice authorization device adds a layer of security protection of the transport layer protocol on top of the original TCP connection, and adds the application ID and service ID information to the Host information submitted in the handshake phase of the transport layer protocol by introducing server name indication technology.

6. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the microservice authorization method according to any one of claims 1 to 4.

7. A processor-readable storage medium, characterized in that, The processor-readable storage medium stores a computer program that causes the processor to perform the steps of the microservice authorization method according to any one of claims 1 to 4.

Images