A microservice switching method and system

Abstract

The present invention discloses a microservice switching method and system, wherein the method comprises: if switching from a private cloud microservice to a public cloud microservice, receiving a token acquisition request from the private cloud data center, wherein the token acquisition request includes at least the user information; in response to the token acquisition request, feeding back a token to the private cloud data center, and receiving a login verification request carrying the token from the private cloud data center, wherein the login verification request includes the service address of the public cloud microservice; after verifying the token in the login verification request, logging in to the public cloud data center based on the user information, and redirecting to the service address in the login verification request to switch to the public cloud microservice represented by the service address. The technical solution provided by the present application can avoid multiple login authentications when switching microservices, thereby improving the switching efficiency of microservices.

Description

Technical Field

[0001] The present invention relates to the field of Internet technology, and in particular to a microservice switching method and system. Background Art

[0002] With the continuous development of cloud service systems, the original large-scale cloud service systems can be split into several microservice systems, thereby providing more targeted and professional services through the microservice systems.

[0003] When using a microservice system, users usually need to switch from one microservice to another. When switching microservices, how to avoid multiple login authentications has become a key issue in improving user experience.

[0004] At present, an SSO (Single Sign On) system can be built based on the CAS (Central Authentication Service) protocol. Various microservices can access the SSO system for unified login authentication. When switching microservices, the SSO system can directly complete the login authentication based on the stored TGC (Ticket Granting Cookie, a cookie that stores user identity authentication credentials). In this way, users can switch between microservices without having to enter their account and password multiple times.

[0005] However, the above solutions also have certain defects. For example, when there are two or more SSO systems, if you need to provide services across SSO systems, you still need to go through multiple login authentication processes. Therefore, a more effective microservice switching solution is currently needed. Summary of the invention

[0006] The purpose of this application is to provide a microservice switching method and system, which can avoid multiple login authentications when switching microservices, thereby improving the switching efficiency of microservices.

[0007] To achieve the above-mentioned objectives, on the one hand, the present application provides a microservice switching method, which is applied to the single sign-on system of the public cloud, and the method includes: when a user has logged in to a private cloud data center, if switching from a private cloud microservice to a public cloud microservice, receiving a token acquisition request sent by the private cloud data center, the token acquisition request at least including the user information of the user in the private cloud data center; in response to the token acquisition request, feeding back a token to the private cloud data center, and receiving a login verification request carrying the token sent by the private cloud data center, the login verification request including the service address of the public cloud microservice; after verifying the token in the login verification request, logging in to the public cloud data center based on the user information, and redirecting to the service address in the login verification request to switch to the public cloud microservice represented by the service address.

[0008] To achieve the above-mentioned purpose, the present application also provides a single sign-on system for a public cloud, the system comprising: a token request receiving unit, for receiving a token acquisition request sent by the private cloud data center when switching from a private cloud microservice to a public cloud microservice when the user has logged in to the private cloud data center, the token acquisition request comprising at least the user information of the user in the private cloud data center; a verification unit, for responding to the token acquisition request, feeding back a token to the private cloud data center, and receiving a login verification request carrying the token sent by the private cloud data center, the login verification request comprising the service address of the public cloud microservice; a microservice switching unit, for logging in to the public cloud data center based on the user information after verifying the token in the login verification request, and redirecting to the service address in the login verification request to switch to the public cloud microservice represented by the service address.

[0009] To achieve the above-mentioned purpose, the present application also provides a microservice switching method on the other hand, which is applied to the single sign-on system of a private cloud, and the method includes: when a user has logged in to a public cloud data center, if switching from a public cloud microservice to a private cloud microservice, receiving an access request sent by the public cloud data center, the access request including a session identifier and a service address of the private cloud microservice; extracting the session identifier in the access request, and sending a verification request including the session identifier to the single sign-on system of the public cloud, and after the session identifier is verified, receiving user information fed back by the single sign-on system of the public cloud; logging in to the private cloud data center based on the user information, and redirecting to the service address in the access request to switch to the private cloud microservice represented by the service address.

[0010] To achieve the above-mentioned purpose, the present application also provides a single sign-on system for a private cloud, the system comprising: an access request receiving unit, which is used to receive an access request sent by the public cloud data center when the user has logged in to the public cloud data center and switches from the public cloud microservice to the private cloud microservice, the access request including a session identifier and a service address of the private cloud microservice; a verification request unit, which is used to extract the session identifier in the access request, and send a verification request including the session identifier to the single sign-on system of the public cloud, and after the session identifier is verified, receive user information fed back by the single sign-on system of the public cloud; a microservice switching unit, which is used to log in to the private cloud data center based on the user information, and redirect to the service address in the access request to switch to the private cloud microservice represented by the service address.

[0011] As can be seen from the above, in the technical solution provided by one or more embodiments of the present application, the public cloud microservice and the private cloud microservice can each have their own SSO system. If the user needs to switch between the public cloud microservice and the private cloud microservice, it involves an authentication process across the SSO system. During the authentication process, when switching from a private cloud microservice to a public cloud microservice, the private cloud data center can request a token from the public cloud SSO system. Subsequently, the private cloud SSO system can send a login verification request carrying the token to the public cloud SSO system. If the login verification request is verified by the public cloud SSO system, the user can log in to the public cloud data center directly based on the user information in the private cloud data center, thereby realizing the switching process of the microservice. If you switch from a public cloud microservice to a private cloud microservice, the public cloud data center can send an access request carrying a session identifier to the private cloud's SSO system, and the private cloud's SSO system can then request the public cloud's SSO system to verify the session identifier. If the session identifier passes the verification, the private cloud's SSO system can receive the user information fed back by the public cloud's SSO system, and can directly log in to the private cloud data center through the user information, thereby completing the switching of microservices. It can be seen that the technical solution provided by the present application does not require the user to enter the account number and password multiple times. Instead, when switching microservices across SSO systems, the two SSO systems can directly complete the authentication process and smoothly switch microservices. This process is imperceptible to the user. From the user's experience, the switching process of microservices can be realized without having to enter the account number and password multiple times. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0013] Figure 1 is a schematic diagram of a system architecture in an embodiment of the present invention;

[0014] Figure 2 Schematic diagram of a method for microservice switching in an embodiment of the present invention;

[0015] Figure 3 is a schematic diagram of exiting from a public cloud microservice in an embodiment of the present invention;

[0016] Figure 4 is a schematic diagram of exiting from a private cloud microservice in an embodiment of the present invention;

[0017] Figure 5 It is another schematic diagram of a method for microservice switching in an embodiment of the present invention. DETAILED DESCRIPTION

[0018] In order to make the purpose, technical solutions and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in combination with the specific implementation methods of this application and the corresponding drawings. Obviously, the described implementation methods are only part of the implementation methods of this application, not all of the implementation methods. Based on the implementation methods in this application, all other implementation methods obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0019] At present, the emergence of the CAS protocol and the SSO system implemented based on this protocol can, to a certain extent, avoid the situation where users need to enter their account and password multiple times when switching microservices.

[0020] Based on the fully standard CAS protocol, each microservice can be connected to the SSO system. When a user logs in to a microservice, the browser can be redirected to the SSO system for account authentication. After the account and password are successfully verified, the SSO system generates a TGT (Ticket Granting Ticket), stores the TGT in a cookie, and issues an ST (Service Ticket) to the microservice. The microservice can authenticate with the SSO system through the ST to complete a login. When switching microservices, the SSO system directly completes the login authentication by obtaining the TGC information in the browser. In this way, users can access other microservices without having to enter their account and password again. When a microservice exits, after receiving the exit request, the SSO system obtains all microservice sessions for this login based on the TGT, and sends the ST information containing the login to each microservice, thereby notifying the microservice to destroy the session bound to the ST and complete the exit.

[0021] In the simplified CAS implementation, when a user logs in to a microservice for the first time, the SSO system generates a globally unique session identifier (Session ID, SID). When switching to other microservices, the SID in the browser cookie is sent to the microservice to be switched and verified to complete the password-free login. When logging out, the SSO system sends a logout notification containing the SID, and each microservice destroys the session associated with the SID to complete the logout.

[0022] There are many solutions for implementing a single SSO login system based on the CAS protocol, and the solutions are constantly being updated. However, in some enterprises or institutions, especially companies that provide cloud solutions, when providing customized cloud services to the outside world, they all have independent application systems and authentication centers, that is, there are multiple SSO systems. For example, an enterprise provides a unified public cloud service to the outside world, which includes many microservice systems. At the same time, the enterprise also provides a customized private cloud service to other companies or individuals, and both the public cloud service and the private cloud service have their own SSO systems. If a user has logged in to a private cloud and wants to use or purchase a service on a public cloud, the user must go to the public cloud's SSO system and enter the user name and password for the public cloud to log in to the public cloud before continuing to operate. This gives users a very unfriendly experience.

[0023] Therefore, a mutual-trust authentication login solution that supports cross-SSO systems is needed to solve this problem.

[0024] There are a few solutions proposed for this demand. The most common one is the trust center system, that is, two or more SSO systems are connected to a trust center at the same time, and the trust center implements unified authentication to achieve mutual communication and trust between SSOs. However, this solution requires that the data of different SSO systems be shared to a unified trust center, which cannot play the role of isolating the data of private cloud and public cloud, and there are certain risks in the data. Moreover, the introduction of an additional trust center system requires an additional maintenance and development cost, and the development cycle is long, and the existing SSO system is over-modified. Another solution is to perform mutual trust login for the SSO login system that implements the standard CAS protocol, but this solution is not compatible with the SSO system that implements the simplified CAS protocol. Some other solutions only propose solutions for how to perform login verification, and do not involve solutions for how to perform unified logout. As a result, after users log in once, they have to log out separately in different SSO systems, which also brings trouble to users.

[0025] In view of this, an embodiment of the present application provides a microservice switching method, which can be applied to Figure 1 In the system architecture shown in the figure, the system architecture may include a private cloud SSO system, a private cloud data center, a public cloud SSO system, and a public cloud data center. The private cloud data center and the public cloud data center may provide users with private cloud microservices and public cloud microservices, respectively. The private cloud and public cloud SSO systems may authenticate user information to confirm that the user has the authority to access the corresponding microservices. Figure 1 and Figure 2 A microservice switching method provided in an embodiment of the present application can be applied to the above-mentioned public cloud SSO system. The method may include the following steps.

[0026] S11: When the user has logged in to the private cloud data center, if switching from the private cloud microservice to the public cloud microservice, a token acquisition request sent by the private cloud data center is received, and the token acquisition request includes at least the user information of the user in the private cloud data center.

[0027] In this embodiment, after the user logs in to the private cloud data center with an account and password, the user can access the private cloud microservices provided by the private cloud data center. When providing private cloud microservices to users, a list of public cloud microservices may also be provided in the page for users to choose. When the user selects one of the public cloud microservices, the process of switching from the private cloud microservice to the public cloud microservice is triggered. At this time, the private cloud data center can send a token acquisition request to the SSO system of the public cloud to obtain a one-time token from the SSO system of the public cloud. When sending the token acquisition request, the private cloud data center can send the user information of the user to the SSO system of the public cloud, so that the SSO system of the public cloud can automatically log in using the user information later. In actual applications, the user information can be in various forms. For example, the user information can be the account and password used by the user when logging in to the private cloud data center, or it can be the TGC information of the user stored in the private cloud data center after the user logs in to the private cloud data center. Of course, in actual applications, the user information can also be in other forms, as long as the user's login process can be completed based on the user information.

[0028] In one embodiment, in the token acquisition request sent by the private cloud data center, identification information pre-registered by the private cloud data center can be added to the request header. The identification information can be, for example, AK (Access Key) information. The private cloud data center can register the identification information in the management system. At the same time, when the identification information is generated, it can have a matching secret key (SK), so that AK and SK can constitute a set of matching information, and the corresponding SK can be queried according to AK. The private cloud data center can store the identification information in the request header of the token acquisition request, so that after the public cloud SSO system receives the token acquisition request, it can query the secret key matching the identification information from the management system. Then, the request content of the token acquisition request can be encrypted using the secret key to obtain a verification signature. If the verification signature encrypted using the secret key is consistent with the signature carried in the token acquisition request, it means that the token acquisition request meets the verification condition, and at this time, the public cloud SSO system can feedback a one-time token to the private cloud data center.

[0029] S13: In response to the token acquisition request, a token is fed back to the private cloud data center, and a login verification request carrying the token sent by the private cloud data center is received, wherein the login verification request includes the service address of the public cloud microservice.

[0030] In this embodiment, after the private cloud data center receives the one-time token, it can send a login verification request carrying the token to the public cloud SSO system to try to complete the verification of user information in the public cloud SSO system. Since the token is one-time, it will automatically expire after the verification is completed, thereby ensuring the security of the subsequent verification process.

[0031] Specifically, the login verification request can be initiated by a browser. When sending the login verification request, the browser can carry a one-time token on the one hand, and can also carry the service address of the public cloud microservice to be switched on the other hand. In this way, the public cloud data center will know which public cloud microservice to switch to later. In actual applications, the domain name of the service address of the public cloud microservice is usually different from the domain name of the login verification request. For example, the login verification request can be http: / / public-cloud.sso.com?service=https: / / a.client.com, and the service address of the public cloud microservice can be https: / / a.client.com. It can be seen that the service address of the public cloud microservice can be carried in the login verification request.

[0032] S15: After verifying the token in the login verification request, log in to the public cloud data center based on the user information, and redirect to the service address in the login verification request to switch to the public cloud microservice represented by the service address.

[0033] In this embodiment, after receiving the login verification request, the SSO system of the public cloud can verify whether the token therein is correct. If it is correct, the login verification request can be processed normally. When processing the login verification request, you can first log in to the public cloud data center based on the user information obtained in step S11. In this way, the process of the user needing to enter the account and password again is avoided. After logging in to the public cloud data center, the SSO system of the public cloud can rewrite the login verification request to generate a new link to the public cloud microservice. Specifically, the SSO system of the public cloud can identify the service address of the public cloud microservice from the login verification request, and use the service address of the public cloud microservice as the rewritten link. For example, for a login verification request such as http: / / public-cloud.sso.com?service=https: / / a.client.com, the service address of the public cloud microservice extracted from it can be https: / / a.client.com, then https: / / a.client.com can be used as the rewritten new link. After extracting the service address, the public cloud's SSO system can redirect to the service address, thereby switching to the public cloud microservice represented by the service address.

[0034] It can be seen that through the interaction between the private cloud data center and the public cloud SSO system, user information verification and login can be completed, and through redirection, it can switch to the public cloud microservice pointed to by the service address, thereby completing the switch from the private cloud microservice to the public cloud microservice without having to enter the account and password again.

[0035] When the user has finished accessing the public cloud microservice or the private cloud microservice, the user needs to log out of the current login state. In order to uniformly log out of the public cloud microservice and the private cloud microservice, different solutions can be implemented in this application for different exit scenarios.

[0036] Specifically, if a user logs out of a public cloud microservice after using it, the public cloud SSO system will receive a logout instruction to log out of the public cloud microservice. In the public cloud SSO system, the user's user information will be associated with each public cloud microservice logged in during this login process. In this way, all associated logged-in public cloud microservices can be queried through the user information. At this time, the public cloud SSO system can send logout notifications to these public cloud microservices one by one, thereby completing the logout process of the public cloud microservice.

[0037] In addition, during this login process, the user may have accessed some private cloud microservices, causing these private cloud microservices to be currently logged in. Among them, the private cloud microservices in the logged-in state can also be associated with user information. In this way, the SSO system of the public cloud can determine whether there are any private cloud microservices in the logged-in state through the user information. If there are, the SSO system of the public cloud can encrypt the user information to obtain a session identifier (SID). In the SSO system of the private cloud, all logged-in private cloud microservices can be associated with the SID. In this way, the SSO system of the public cloud can send the obtained SID to the SSO system of the private cloud. In this way, the SSO system of the private cloud can log out all the private cloud microservices associated with the SID. In this way, even if you log out of the microservice from the public cloud, you can also log out of the public cloud microservice and the private cloud microservice together.

[0038] See also Figure 3 In a specific application scenario, when the user triggers the logout operation, the public cloud SSO system can redirect to the public cloud logout page by redirecting. At the same time, the public cloud SSO system can notify the logged-in public cloud microservice to log out in the above manner, and determine whether there is a private cloud microservice currently logged in based on the TGC information. After obtaining the SID, the public cloud SSO system can call the logout interface of the private cloud SSO system, and the process of calling the logout interface can be a redirection process, thereby redirecting to the private cloud logout page. In this way, the public cloud SSO system can initiate a redirect access to the logout interface, and the above-mentioned SID can be carried in the redirect access, so that the SID is passed to the private cloud SSO system. The private cloud SSO system can then initiate a logout notification to the associated private cloud microservice based on the SID.

[0039] See also Figure 4In one embodiment, if the user exits the microservice from the private cloud, the SSO system of the private cloud can receive an exit instruction to exit the microservice from the private cloud. At this time, the SSO system of the private cloud can query the associated logged-in private cloud microservices according to the SID, and can send an exit notification to these private cloud microservices. After completing the exit of the private cloud microservice, it is also necessary to exit the public cloud microservice that is currently logged in. Specifically, the SSO system of the private cloud can send an exit notification to the SSO system of the public cloud, and the exit notification can include the SID and the jump link. In this way, after receiving the SID, the SSO system of the public cloud can decrypt the SID to obtain the corresponding TGC information. Through the TGC information, the SSO system of the public cloud can query the associated public cloud microservices and can log out of these public cloud microservices. After logging out, it is necessary to display the page after logging out to the user, and the page can be determined by the SSO system of the private cloud through the above-mentioned jump link. Therefore, after completing the exit from the public cloud microservice, the public cloud's SSO system can redirect to the page pointed to by the above jump link, so that the page after exiting the microservice can be displayed to the user.

[0040] In this embodiment, when the private cloud SSO system sends a logout notification to the public cloud SSO system, it can call the logout interface of the public cloud SSO system. The process of calling the logout interface can also be a browser redirection process, which can carry the above-mentioned SID and jump link through redirection, so that the public cloud SSO system can complete the logout of the public cloud microservice based on the SID, and can display the logout page to the user according to the jump link.

[0041] In one embodiment of the present application, a single sign-on system for a public cloud is also provided, the system comprising:

[0042] A token request receiving unit, configured to receive a token acquisition request from the private cloud data center when the user has logged in to the private cloud data center and switches from the private cloud microservice to the public cloud microservice, wherein the token acquisition request includes at least user information of the user in the private cloud data center;

[0043] A verification unit, configured to, in response to the token acquisition request, feed back a token to the private cloud data center, and receive a login verification request carrying the token from the private cloud data center, wherein the login verification request includes a service address of the public cloud microservice;

[0044] The microservice switching unit is used to log in to the public cloud data center based on the user information after verifying the token in the login verification request, and redirect to the service address in the login verification request to switch to the public cloud microservice represented by the service address.

[0045] One embodiment of the present application also provides a microservice switching method, which can be applied to a single sign-on system of a private cloud. Figure 1 and Figure 5 , the method may include the following steps.

[0046] S21: When the user has logged in to the public cloud data center, if switching from the public cloud microservice to the private cloud microservice, an access request sent by the public cloud data center is received, wherein the access request includes a session identifier and a service address of the private cloud microservice.

[0047] In this embodiment, after the user logs in to the public cloud data center with an account and password, he can access the various public cloud microservices provided by the public cloud data center. When providing public cloud microservices to users, the page may also have a list of private cloud microservices for users to choose from. When the user selects one of the private cloud microservices, the process of switching from the public cloud microservice to the private cloud microservice is triggered. At this time, since the domain name in the public cloud data is different from the domain name of the public cloud's SSO system, the public cloud data center can send a cross-domain request to the public cloud's SSO system. The cross-domain request can be an ajax request initiated by the public cloud data center, and the ajax request can call the interface of the public cloud's SSO system. For example, the ajax request can be https: / / public.sso.com / obtain-sid, which is used to obtain the SID from the public cloud's SSO system.

[0048] In this embodiment, in response to the cross-domain request, the public cloud SSO system can query the user information of this login, which can be, for example, TGC information. Then, the public cloud SSO system can encrypt the user information to obtain the corresponding SID, and feed the SID back to the public cloud data center.

[0049] When switching from a public cloud microservice to a private cloud microservice, the public cloud data center can send an access request to the SSO system of the private cloud. The access request can carry the above SID and the service address of the private cloud microservice to be switched.

[0050] In an actual application scenario, the public cloud data center can send the above access request to the private cloud by calling the private cloud's authentication interface. After receiving the access request, the private cloud's microservice can feed back the SID to the private cloud's SSO system for verification. In this way, the private cloud's SSO system can receive the SID provided by the public cloud data center.

[0051] S23: extracting the session identifier in the access request, and sending a verification request including the session identifier to the single sign-on system of the public cloud, and receiving user information fed back by the single sign-on system of the public cloud after the session identifier is verified.

[0052] In this embodiment, after receiving the SID provided by the public cloud data center, the private cloud SSO system can request the public cloud SSO system to verify the legitimacy of the SID. When the SID is verified by the public cloud SSO system, the public cloud SSO system can feed back the user information of the current user login to the private cloud SSO system.

[0053] S25: Log in to the private cloud data center based on the user information, and redirect to the service address in the access request to switch to the private cloud microservice represented by the service address.

[0054] In this embodiment, after the private cloud's SSO system receives the user information, it can directly use the user information to log in to the private cloud data center. After logging in, it can redirect to the service address in the access request by redirection, thereby switching to the private cloud microservice represented by the service address. In this way, the switching process from the public cloud microservice to the private cloud microservice can be completed.

[0055] In this embodiment, after obtaining the SID, the SSO system of the private cloud can bind the SID to the private cloud microservice in this login process, and then identify the service address of the private cloud microservice from the access request, and redirect access to the private cloud microservice represented by the service address. In actual applications, the access request initiated by the public cloud data center can be https: / / private.sso.com?service=https: / / b.client.com, and the service address of the private cloud microservice https: / / b.client.com can be carried in the access request. Since the domain names of the access request and the service address are different, the browser needs to access the private cloud microservice represented by the service address by redirection.

[0056] In one embodiment, the user may log out from a public cloud microservice or a private cloud microservice in the manner described above. In this way, after receiving the logout instruction to log out of the private cloud microservice, the private cloud SSO system may query the logged-in private cloud microservice associated with the session identifier and send a logout notification to the logged-in private cloud microservice. Then, the session identifier and the jump link may be sent to the public cloud SSO system so that the public cloud SSO system will redirect the user to the page pointed to by the jump link after logging out of the public cloud microservice associated with the session identifier.

[0057] If you log out of the microservice from the public cloud, the SSO system of the private cloud can receive a logout notification from the SSO system of the public cloud. In response to the logout notification, the SSO system of the private cloud can query the logged-in private cloud microservice associated with the session identifier and send a logout notification to the logged-in private cloud microservice.

[0058] The detailed description process can be referred to the previous description, which will not be repeated here.

[0059] The present application also provides a single sign-on system for a private cloud, the system comprising:

[0060] An access request receiving unit, configured to receive an access request sent by the public cloud data center when the user has logged in to the public cloud data center and switches from the public cloud microservice to the private cloud microservice, wherein the access request includes a session identifier and a service address of the private cloud microservice;

[0061] A verification request unit, configured to extract the session identifier in the access request, send a verification request including the session identifier to the single sign-on system of the public cloud, and receive user information fed back by the single sign-on system of the public cloud after the session identifier is verified;

[0062] The microservice switching unit is used to log in to the private cloud data center based on the user information and redirect to the service address in the access request to switch to the private cloud microservice represented by the service address.

[0063] As can be seen from the above, in the technical solution provided by one or more embodiments of the present application, the public cloud microservice and the private cloud microservice can each have their own SSO system. If the user needs to switch between the public cloud microservice and the private cloud microservice, it involves an authentication process across the SSO system. During the authentication process, when switching from a private cloud microservice to a public cloud microservice, the private cloud data center can request a token from the public cloud SSO system. Subsequently, the private cloud SSO system can send a login verification request carrying the token to the public cloud SSO system. If the login verification request is verified by the public cloud SSO system, the user can log in to the public cloud data center directly based on the user information in the private cloud data center, thereby realizing the switching process of the microservice. If you switch from a public cloud microservice to a private cloud microservice, the public cloud data center can send an access request carrying a session identifier to the private cloud's SSO system, and the private cloud's SSO system can then request the public cloud's SSO system to verify the session identifier. If the session identifier passes the verification, the private cloud's SSO system can receive the user information fed back by the public cloud's SSO system, and can directly log in to the private cloud data center through the user information, thereby completing the switching of microservices. It can be seen that the technical solution provided by the present application does not require the user to enter the account number and password multiple times. Instead, when switching microservices across SSO systems, the two SSO systems can directly complete the authentication process and smoothly switch microservices. This process is imperceptible to the user. From the user's experience, the switching process of microservices can be realized without having to enter the account number and password multiple times.

[0064] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the implementation of the system, the introduction of the implementation of the aforementioned method can be referred to for comparative explanation.

[0065] It will be appreciated by those skilled in the art that the embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may be in the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may be in the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0066] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0067] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0068] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0069] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0070] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0071] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0072] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0073] The above is only the implementation mode of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A microservice switching method, characterized in that: The method is applied to a single sign-on system of a public cloud, and the method comprises: When the user has logged in to the private cloud data center, if the user switches from the private cloud microservice to the public cloud microservice, a token acquisition request sent by the private cloud data center is received, and the token acquisition request includes at least user information of the user in the private cloud data center; In response to the token acquisition request, feeding back a token to the private cloud data center, and receiving a login verification request carrying the token from the private cloud data center, wherein the login verification request includes a service address of the public cloud microservice; After verifying the token in the login verification request, log in to the public cloud data center based on the user information, and redirect to the service address in the login verification request to switch to the public cloud microservice represented by the service address; If you exit the microservice from the private cloud, you will receive the session ID and redirect link from the private cloud's single sign-on system. The logged-in public cloud microservice associated with the session identifier is queried, a logout notification is sent to the logged-in public cloud microservice obtained through the query, and the redirection is performed to the jump link.

2. The method according to claim 1, characterized in that The method further comprises: If switching from the public cloud microservice to the private cloud microservice, receiving the cross-domain request sent by the public cloud data center, querying the user information of this login in response to the cross-domain request, encrypting the user information, generating a corresponding session identifier, and feeding back the session identifier to the public cloud data center.

3. The method according to claim 1, characterized in that: Redirecting to the service address in the login verification request includes: The service address of the public cloud microservice is identified from the login verification request, and access to the public cloud microservice represented by the service address is redirected.

4. The method according to claim 1, characterized in that: The token acquisition request also includes identification information pre-registered by the private cloud data center; and feeding back the token to the private cloud data center includes: Querying a secret key that matches the identification information, and using the secret key to encrypt the request content of the token acquisition request to obtain a verification signature; If the verification signature is consistent with the signature carried in the token acquisition request, a token is fed back to the private cloud data center.

5. The method according to claim 1, characterized in that: The method further comprises: After receiving a logout instruction to log out of the public cloud microservice, querying the logged-in public cloud microservice associated with the user information, and sending a logout notification to the logged-in public cloud microservice; The user information is encrypted to obtain a session identifier, and the session identifier is sent to a single sign-on system of the private cloud, so that the single sign-on system of the private cloud logs out the private cloud microservice associated with the session identifier.

6. The method according to claim 5, characterized in that The single sign-on system that sends the session identifier to the private cloud includes: The logout interface of the single sign-on system of the private cloud is called to initiate a redirect access to the logout interface, wherein the redirect access carries the session identifier.

7. A single sign-on system for a public cloud, characterized in that: The system comprises: A token request receiving unit, configured to receive a token acquisition request from the private cloud data center when the user has logged in to the private cloud data center and switches from the private cloud microservice to the public cloud microservice, wherein the token acquisition request includes at least user information of the user in the private cloud data center; A verification unit, configured to, in response to the token acquisition request, feed back a token to the private cloud data center, and receive a login verification request carrying the token from the private cloud data center, wherein the login verification request includes a service address of the public cloud microservice; A microservice switching unit, configured to log in to the public cloud data center based on the user information after verifying the token in the login verification request, and redirect to the service address in the login verification request to switch to the public cloud microservice represented by the service address; The system is also used to receive a session identifier and a jump link sent by the single sign-on system of the private cloud when exiting a microservice from the private cloud; query the logged-in public cloud microservice associated with the session identifier, send an exit notification to the logged-in public cloud microservice obtained by the query, and redirect to the jump link.

8. A microservice switching method, characterized in that: The method is applied to a single sign-on system of a private cloud, and the method comprises: When the user has logged in to the public cloud data center, if the user switches from the public cloud microservice to the private cloud microservice, an access request sent by the public cloud data center is received, wherein the access request includes a session identifier and a service address of the private cloud microservice; Extracting the session identifier in the access request, and sending a verification request including the session identifier to the single sign-on system of the public cloud, and receiving user information fed back by the single sign-on system of the public cloud after the session identifier is verified; Log in to the private cloud data center based on the user information, and redirect to the service address in the access request to switch to the private cloud microservice represented by the service address.

9. The method according to claim 8, characterized in that The session identifier is generated in the following manner: The single sign-on system of the public cloud receives the cross-domain request sent by the public cloud data center, queries the user information of this login in response to the cross-domain request, encrypts the user information, generates a corresponding session identifier, and feeds back the session identifier to the public cloud data center.

10. The method according to claim 8, characterized in that The redirection to the service address in the access request includes: The session identifier is bound to the private cloud microservice in this login process, the service address is identified from the access request, and access to the private cloud microservice represented by the service address is redirected.

11. The method according to claim 8, characterized in that The method further comprises: After receiving an exit instruction to exit the private cloud microservice, querying the logged-in private cloud microservice associated with the session identifier, and sending an exit notification to the logged-in private cloud microservice; The session identifier and the jump link are sent to the single sign-on system of the public cloud, so that the single sign-on system of the public cloud logs out the public cloud microservice associated with the session identifier and then redirects to the page pointed to by the jump link.

12. The method according to claim 8, characterized in that The method further comprises: If you log out of a microservice from a public cloud, you will receive a logout notification from the public cloud's single sign-on system. In response to the logout notification, a logged-in private cloud microservice associated with the session identifier is queried, and a logout notification is sent to the logged-in private cloud microservice.

13. A single sign-on system for a private cloud, characterized in that: The system comprises: An access request receiving unit, configured to receive an access request sent by the public cloud data center when the user has logged in to the public cloud data center and switches from the public cloud microservice to the private cloud microservice, wherein the access request includes a session identifier and a service address of the private cloud microservice; A verification request unit, configured to extract the session identifier in the access request, send a verification request including the session identifier to the single sign-on system of the public cloud, and receive user information fed back by the single sign-on system of the public cloud after the session identifier is verified; The microservice switching unit is used to log in to the private cloud data center based on the user information and redirect to the service address in the access request to switch to the private cloud microservice represented by the service address.

Images