Single Sign-On Method, Device, Electronic Device and Readable Storage Medium

Abstract

The single sign-on method, device, electronic device and readable storage medium provided by the present invention, when a resource request of the same-origin restriction type for a system to be accessed is received by a request receiver, determine whether there is a valid session identifier that matches the system to be accessed; if not, redirect the resource request to the request receiver; after receiving the redirected resource request, the request receiver generates a target response message and sends the target response message to the request initiator; the target response message is used to instruct the request initiator to call a preset sending function to send a login request to the CAS server; the login request is not a request of the same-origin restriction type. The present invention redirects the resource request to the request receiver itself, generates a target response message and feeds it back to the request initiator, so as to instruct the request initiator to send a login request to the CAS service after receiving the target response message to complete single sign-on, solves the cross-domain problem, and does not require additional configuration for the client system or the CAS server.

Description

Technical Field

[0001] The present invention relates to the field of computer networks, and in particular, to a single sign-on method, device, electronic device, and readable storage medium. Background Art

[0002] Single sign-on is a currently popular solution for enterprise business integration. Multiple applications are authenticated based on a unified account center and share the login status, that is, the user only needs to log in once to access all mutually trusted applications; and logging out at one place will log out globally.

[0003] In the existing single sign-on solutions, when the user is not logged in to the system to be accessed, it is usually necessary to redirect from the system to be accessed to the CAS server for login authentication. At this time, the system to be accessed and the CAS server are in different domains, resulting in cross-domain problems, which may cause requests to have no response or error. The related technologies for solving cross-domain problems either have the defect of complex operations or require modifying the system configuration to increase the maintenance cost. Therefore, how to provide a simple and efficient single sign-on solution that can solve cross-domain problems is a technical problem to be solved. Summary of the Invention

[0004] One of the purposes of the present invention is to provide a single sign-on method, device, electronic device, and readable storage medium to solve the cross-domain problem in the single sign-on process based on the CAS service.

[0005] In a first aspect, the present invention provides a single sign-on method applied to an electronic device, where the electronic device is installed with a system to be accessed, and the method includes: when a request receiver receives a resource request for the system to be accessed, determining whether there is a valid session identifier matching the system to be accessed in the resource request; where the type of the resource request is a same-origin restriction type, and the same-origin restriction type indicates that the source site and the destination site of the request need to have the same protocol, domain name, and port; if not, redirecting the resource request to the request receiver; after receiving the redirected resource request, the request receiver generates a target response message and sends the target response message to the request initiator; where the target response message is used to instruct the request initiator to call a preset sending function to send a login request to the CAS server; the login request is not a request of the same-origin restriction type.

[0006] Second aspect, the present invention provides a single sign-on device, which is applied to an electronic device. The electronic device is installed with the system to be accessed, and includes: a determination module, configured to determine whether there is a valid session identifier matching the system to be accessed in the resource request when receiving a resource request for the system to be accessed; wherein, the type of the resource request is a same-origin restriction type, and the same-origin restriction type indicates that the source site and the destination site of the request need to have the same protocol, domain name, and port; a redirection module, configured to, if not, redirect the resource request to the request recipient; a generation module, configured to generate a target response message and send the target response message to the request initiator after receiving the redirected resource request; wherein, the target response message is used to instruct the request initiator to call a preset sending function to send a login request to the CAS server; the login request is not a request of the same-origin restriction type.

[0007] Third aspect, the present invention provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the single sign-on method described in the first aspect is implemented.

[0008] Fourth aspect, the present invention provides a readable storage medium, on which a computer program is stored. When the program is executed by a processor, the single sign-on method described in the first aspect is implemented.

[0009] The single sign-on method, device, electronic device, and readable storage medium provided by the present invention, compared with the prior art, the main difference is that: in the prior art, after the system to be accessed receives a resource request, it will redirect the resource request to the CAS server, and cross-domain problems are likely to occur during the redirection process, resulting in request errors or no response. In order to solve this cross-domain problem, the present application redirects the resource request to the request recipient itself, thus solving the cross-domain problem. In order to continue to implement single sign-on, after the request recipient receives the redirected resource request, it will generate a target response message and feedback it to the request initiator to instruct the request initiator to send a login request to the CAS server after receiving the target response message, completing the single sign-on process. The entire process of solving the cross-domain problem does not require additional configuration of the client system or the CAS server, which can reduce the device production and maintenance costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following will briefly introduce the drawings required for the embodiments. It should be understood that the following drawings only show some embodiments of the present invention, and therefore should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0011] Figure 1 Schematic diagram of the principle of single sign-on;

[0012] Figure 2 Scenario schematic diagram of a single sign-on method provided by an embodiment of the present invention;

[0013] Figure 3 Block diagram of the structure of an electronic device provided by an embodiment of the present invention;

[0014] Figure 4 Schematic flowchart of the single sign-on method provided by an embodiment of the present invention;

[0015] Figure 5 Scenario schematic diagram of the single sign-on method provided by an embodiment of the present invention;

[0016] Figure 6 Resource request scenario provided by an embodiment of the present invention;

[0017] Figure 7 Update schematic diagram of the resource request scenario provided by an embodiment of the present invention;

[0018] Figure 8 Example diagram of the prior art without home page rendering;

[0019] Figure 9 Example diagram after home page rendering provided by an embodiment of the present invention;

[0020] Figure 10 Redirection schematic diagram provided by an embodiment of the present invention;

[0021] Figure 11 Schematic diagram of the redirected resource request provided by an embodiment of the present invention;

[0022] Figure 12 Schematic flowchart of step S404 provided by an embodiment of the present invention;

[0023] Figure 13 Schematic diagram of the target response information provided by an embodiment of the present invention;

[0024] Figure 14 Example diagram of the CAS server login request provided by an embodiment of the present invention;

[0025] Figure 15 Another scenario schematic diagram of the single sign-on method provided by an embodiment of the present invention;

[0026] Figure 16 Functional module diagram of the single sign-on device provided by an embodiment of the present invention. Detailed implementation manners

[0027] To make the objectives, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some, but not all, of the embodiments of the present invention. The components of the embodiments of the present invention usually described and illustrated in the drawings here can be arranged and designed in various different configurations.

[0028] Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0029] It should be noted that like reference numerals and letters denote like items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings.

[0030] In the description of the present invention, it should be noted that if terms such as "upper", "lower", "inner", "outer", etc. indicate orientations or positional relationships based on the orientations or positional relationships shown in the drawings, or the orientations or positional relationships in which the inventive product is customarily placed during use, it is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention.

[0031] In addition, terms such as "first", "second", etc. are only used for descriptive distinction and cannot be understood as indicating or implying relative importance.

[0032] It should be noted that the features in the embodiments of the present invention can be combined with each other without conflict.

[0033] Single Sign-On (SSO) is an authentication method. Users can log in only once, use a single user ID and password, and access multiple mutually trusted applications, systems, or websites. The single sign-on technology improves the user experience, reduces the cost of managing usernames and passwords for a large number of applications, and improves work efficiency.

[0034] For example, there are usually multiple systems in general traditional and Internet enterprises, such as forums, collaboration, and human resources systems, which are relatively common. If users need to enter usernames and passwords when accessing each system, the steps will be rather cumbersome and the user experience will be poor. Therefore, a unified login system is needed. CAS is a single sign-on system for web applications, and users can use it for single sign-on and sign-out.

[0035] Please refer to Figure 1 , Figure 1 , which is a schematic diagram of the principle of single sign-on. Completing single sign-on can include the following steps:

[0036] S1. The browser sends a request to access a restricted resource to the application system.

[0037] S2. If the application system detects that the user has not logged in, it redirects to the CAS server.

[0038] S3. The browser sends a login request to the CAS server.

[0039] S4. If the CAS server detects that there is no valid session identifier, it returns a login page to the browser.

[0040] S5. The browser sends the username and user password to the CAS server.

[0041] S6. After the CAS server successfully verifies the username and user password, it creates a global session, attaches the generated ticket to the request for obtaining the restricted resource, and redirects to the application system.

[0042] S7. The browser sends a request to access the restricted resource to the application system with the ticket.

[0043] S8. After obtaining the ticket, the application system sends a ticket verification request to the CAS server.

[0044] S9. After the CAS server verifies that the ticket is valid, it sends a verification success message to the application system.

[0045] S10. The application system returns the restricted resource to the browser.

[0046] In the existing single sign-on solutions, when the user has not logged in to the system to be accessed, it is usually necessary to redirect from the system to be accessed to the CAS server for login authentication (i.e., the application system redirects to the CAS server in step 2). At this time, the system to be accessed and the CAS server are in different domains, resulting in cross-domain problems, which may cause the request to have no response or report an error.

[0047] The above cross-domain problem refers to: at least one of the protocol, domain name, and port of the actually sent request is inconsistent with that displayed in the browser address bar. Due to the same-origin restriction, a redirected request does not mean a new request, but a continuation of the original request. After redirection, the originating site of the request is the application system. The application system and the CAS server are not of the same origin, that is, the domain name, protocol, and port are different. Therefore, the cross-domain problem occurs.

[0048] In the existing solution of using CAS for single sign-on, the native CAS filter (CAS client) can be used for single sign-on, that is, the CAS filter is integrated into the server of the business system to be accessed. However, after using this method, in a scenario with multiple application systems, for example, an application system A already has a single sign-on system, and another application system B needs to connect to this single sign-on system. At this time, application system B needs to integrate the CAS filter into its server. Then, in the process of accessing application system B, there is still a cross-domain problem when jumping to the CAS server. In other words, different application systems need to reference the CAS filter jar package. If different application systems share a cas server, there is still a cross-domain problem.

[0049] The related technologies have also proposed some solutions, but these solutions all have other defects:

[0050] Solution 1: All front-ends need to be deployed on native nginx, and both the application system and CAS server need to use native nginx routing, and configure the location information of static resources in nginx. These operations are not only cumbersome and error-prone, but also require restarting nginx for system upgrades, which has many restrictions. In addition, each time a system is added, the nginx configuration needs to be modified and restarted, increasing maintenance costs.

[0051] Solution 2: To facilitate related testing on the CAS server, the CAS server is open source, so the related technology allows cross-domain by modifying the CAS server source code. However, unauthorized modification of the CAS server source code poses a major security risk, so modification of the CAS server source code is usually not allowed. In addition, in the scenario where it is necessary to connect to the customer's single sign-on system, it is unrealistic to require the customer to modify the CAS logic.

[0052] Moreover, although the customer system currently has a complete single sign-on system, in order to expand business needs, business systems developed by other service providers may be needed to implement certain business functions. Therefore, how to embed the business system into the customer single sign-on system so that the business system can connect to the customer single sign-on system is also a technical problem that needs to be solved.

[0053] Based on the above-mentioned technical problems, the present invention provides a single sign-on method, which can solve the cross-domain problem in the scenario where the system to be accessed is connected to the customer's single sign-on system. The single sign-on method provided by the embodiment of the present invention will be introduced in detail below in conjunction with relevant drawings.

[0054] First, see Figure 2 , Figure 2This is a schematic diagram of the scenario of a single sign-on method provided by an embodiment of the present invention. This scenario includes a terminal 201 and a CAS server 202, which are connected through a network. Specifically:

[0055] The above-mentioned CAS server 202 can be a single server or a server cluster, and is connected to the terminal 201 through a communication network, and can provide corresponding authentication services for the customer single sign-on system.

[0056] The above-mentioned communication network can be a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a mobile network, a wired network or a wireless network, a private network, etc.

[0057] The above-mentioned terminal 201 can be, but is not limited to: a smart phone, a computer, a tablet computer, a personal computer, etc. The to-be-accessed system 203 can be independently deployed on the terminal 201. The to-be-accessed system 203 refers to a system that can provide business services for customers, such as an order system, a report system, and so on. The to-be-accessed system 203 can be one or more. The to-be-accessed system 203 can come from the same service provider or different service providers. The embodiments of the present application do not make any limitations in this regard.

[0058] A customer single sign-on system can also be deployed on the terminal 201. The embodiment of the present invention provides a single sign-on device 500 in order to enable the to-be-accessed system 203 to be docked with the customer single sign-on system and avoid the cumbersome operation of the customer having to input user information every time to log in to the to-be-accessed system. The single sign-on device 500 can be deployed in the form of a software module or hardware. The single sign-on device 500 can not only be a complete CAS client by itself, but also embed its interface into the other system and share the single sign-on service with the other system.

[0059] In an alternative embodiment, the single sign-on device 500 can be deployed in the form of software as a module with routing functions on the to-be-accessed system 203.

[0060] In another alternative embodiment, the single sign-on device 500 can also be deployed separately from the to-be-accessed system 203 on the terminal 201 in the form of software or hardware.

[0061] The embodiments of the present invention do not make any limitations on the above two embodiments.

[0062] In the embodiment of the present application, the single sign-on device 500 is a functional module with routing functions, which can be, but is not limited to, a gateway, such as Openresty. Openresty is a high-performance Web platform based on Nginx and Lua. It has strong scalability and high performance and is usually used for the unified access gateway of microservices.

[0063] In the embodiment of the present invention, to solve the cross-domain problem in the redirection technology, the core of the single sign-on method lies in that: after receiving a request for the to-be-accessed system 203, the single sign-on device 500 can redirect the request to itself. In this way, the source site and the destination site of the redirected request are both the single sign-on device 500, solving the cross-domain problem. And after solving the cross-domain problem, in order to implement the single sign-on function of the to-be-accessed system 203, the single sign-on device 500 can also generate a response message, which has key information for triggering the execution of the CAS server login authentication process. After receiving the response message, the request initiator can send a login request to the CAS server by calling a function, thereby completing the login authentication and also avoiding sending requests across domains.

[0064] It should be noted that Figure 2 The shown scenario is only an example. To enable the to-be-accessed system to dock with the customer single sign-on system, the customer single sign-on system and the to-be-accessed system 203 involved in the embodiment of the present application can be independently deployed on the terminal 201. In other scenarios, the customer single sign-on system and the to-be-accessed system 203 can be independently deployed on different terminals. For example, the to-be-accessed system 203 is deployed on the terminal 201, while the customer single sign-on system is deployed on other terminals. The embodiments of the present invention do not make any limitations.

[0065] Please refer to Figure 3 , Figure 3 which is a structural block diagram of an electronic device provided by the embodiment of the present invention. The electronic device can be, but is not limited to, Figure 1 the terminal 201 in

[0066] As Figure 3 shown, the electronic device 300 includes a memory 301, a processor 302, and a communication interface 303. The memory 301, the processor 302, and the communication interface 303 are directly or indirectly electrically connected to each other to realize data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0067] The memory 301 can be used to store software programs and modules, such as the instructions / modules of the single sign-on device 500 and the system to be accessed 203 provided in the embodiments of the present invention. They can be stored in the memory 301 in the form of software or firmware, or be solidified in the operating system (OS) of the electronic device 300. The processor 302 executes various functional applications and data processing by executing the software programs and modules stored in the memory 301. The communication interface 303 can be used for signaling or data communication with other node devices.

[0068] Among them, the memory 301 can be, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc.

[0069] The processor 302 can be an integrated circuit chip with signal processing capabilities. The processor 302 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0070] It can be understood that Figure 3 the structure shown is only schematic, and the electronic device 300 may also include more or fewer components than those Figure 3 shown, or have a configuration different from that Figure 3 shown. Figure 3 Each component shown can be implemented by hardware, software, or a combination thereof.

[0071] The following will introduce the single sign-on method provided in the embodiments of the present invention in detail. Please refer to Figure 4 ,Figure 4 A schematic flowchart of the single sign-on method provided by an embodiment of the present invention. The method may include the following steps:

[0072] S402: When the request receiver receives a resource request for the system to be accessed, determine whether there is a valid session identifier matching the system to be accessed in the resource request.

[0073] In the embodiment of the present invention, the request receiver is the single sign-on device 500 in the embodiment of the present invention. The resource request comes from the request initiator, and the request initiator may be the browser front-end. For example, a browser is installed on the terminal 201, and the customer enters the name of the system to be accessed through the browser, thereby generating a resource request for the system to be accessed. Then the front-end sends the resource request. Then the request initiator can be understood as the front-end.

[0074] If both the system to be accessed and the customer system are deployed on the terminal 201, then the resource request is sent by the browser front-end on the terminal 201; if the system to be accessed and the customer single sign-on system are separately deployed on different terminals, then the resource request is sent by the browser front-end on the terminal where the customer single sign-on system is deployed.

[0075] The resource request in the embodiment of the present invention is a request of the same-origin restriction type, that is, an Ajax request sent through the browser. "Same-origin restriction" requires that the source site of the request and the destination site have the same protocol, domain name, and port. During the process of sending this type of request, it can be but not limited to indicating the existence of the same-origin restriction through the origin field. Because of this restriction, Figure 1 a cross-domain problem will occur during the process of redirecting the application system to the CAS server. Therefore, the single sign-on method provided in this application to solve the cross-domain problem is specifically aimed at Ajax requests.

[0076] In the embodiment of the present invention, the valid session identifier matching the system to be accessed is generated when the customer has logged in to the system to be accessed. If there is no such identifier, it indicates that the user has not logged in to the system to be accessed before. The cookie carried in the resource request is used to cache the session identifier, usually the token field in the cookie. When the system to be accessed receives the resource request, it can check whether there is a token field in the cookie that matches the system to be accessed. If not, it indicates that the customer has not logged in to the system to be accessed yet, and this access is the first access.

[0077] S404: If not, redirect the resource request to the request receiver.

[0078] To solve the cross-domain problem, the embodiment of the present invention specifically designs to redirect the resource request to the request receiver itself, which is different from Figure 1The single sign-on process shown has obvious differences. By redirecting the resource request to the request recipient itself, the source site of the request is the request recipient, and the target site of the request is also the request recipient, thus solving the cross-domain problem during the redirection process.

[0079] In the embodiment of the present invention, after redirecting the resource request to the request recipient itself, after determining that the customer has not logged in to the system to be accessed, it is also necessary to guide the customer to complete the login authentication through the CAS server, so as to achieve the effect of docking with the customer's single sign-on system. Therefore, step S406 can be executed.

[0080] S406: After the request recipient receives the redirected resource request, it generates target response information.

[0081] It can be understood that redirecting the resource request to the request recipient itself has achieved the effect of solving the cross-domain problem. However, in order for the system to be accessed to dock with the customer's single sign-on system, it is necessary to complete the login authentication through the CAS server. Therefore, after the request recipient receives the redirected resource request, it generates target response information.

[0082] The target response information is used to instruct the request initiator to send a login request to the CAS server by calling a preset sending function. At this time, the initiated login request is no longer a request of the same-origin restriction type, breaking through the origin restriction and avoiding the cross-domain problem.

[0083] In the embodiment of the present invention, the preset sending function can be window.location.ref. By sending the login request in the way of window.location.ref, it is equivalent to directly entering the website address in the browser. The sent request is no longer an Ajax request but a Document request, thus there is no cross-domain problem.

[0084] It can be understood that the target response information may include the login address information of the CAS server. After the request initiator obtains the target response information, it can follow the Figure 1 process of steps 3 to 10 shown to complete single sign-on.

[0085] Compared with the prior art, the single sign-on method provided by the embodiments of the present invention mainly lies in that: after receiving a resource request in the prior art, the system to be accessed redirects the resource request to the CAS server, and cross-domain problems are likely to occur during the redirection process, resulting in request errors or no response. To solve this cross-domain problem, the present application redirects the resource request to the request receiver itself, thus solving the cross-domain problem. To continue to implement single sign-on, after receiving the redirected resource request, the request receiver generates target response information and feeds it back to the request initiator to instruct the request initiator to send a login request to the CAS server after receiving the target response information, completing the single sign-on process. The entire process of solving the cross-domain problem does not require additional configuration of the client system or the CAS server, which can reduce the equipment production and maintenance costs.

[0086] To facilitate the understanding of the embodiments of the present invention, a specific implementation scenario is given below. Please refer to Figure 5 , Figure 5 which is a schematic diagram of the scenario of the single sign-on method provided by the embodiments of the present invention. Comparing Figure 5 and Figure 1 it can be seen that in step 3 of Figure 5 , redirecting to the request receiver itself can avoid the cross-domain problem that occurs when redirecting to the CAS server in step 2 of Figure 1 . Moreover, in step 5 of Figure 5 , the login request is initiated in the form of a function, which is different from directly sending the login request through the browser in Figure 1 . This way of sending requests in the embodiments of the present invention breaks through the origin restriction problem of the way of sending requests by the browser, that is, it avoids the problem that the domain name and port of the actually sent request are inconsistent with the domain name and port of the request displayed in the browser address bar.

[0087] In an alternative embodiment, in order to enable the system to be accessed to dock with the existing single sign-on system of the customer and complete single sign-on, rather than requiring the customer to input user information every time the system to be accessed is logged in, during the process of the request initiator sending a resource request to the request receiver, special processing can be performed, that is:

[0088] The resource request is generated by the request initiator based on the domain name information of the system to be accessed and the system identification information matching the system to be accessed; the resource request generated in this way can be used to prevent the system to be accessed from returning a login page to the request initiator.

[0089] That is to say, if the request receiver directly returns the login page of the system to be accessed after receiving the resource request, then the customer needs to manually enter the username and password each time, which is cumbersome and has a poor user experience. Therefore, since the customer already has a single sign-on system, the single sign-on authentication process on the CAS server side can be executed to avoid the above operation process of directly entering user information and improve the user experience.

[0090] Therefore, during the process of generating a resource request, the request initiator generates it based on the domain name information of the request receiver and the system identification information matching the system to be accessed. Among them, the domain name information can be used as the destination of the request, and the system identification information will be introduced in detail in the following content. Such a resource request can play a role in preventing the feedback of the login page of the system to be accessed.

[0091] To facilitate the understanding of the above embodiments, a practical example is given below for explanation:

[0092] Suppose the request receiver is a gateway, the domain name information is "10.40.2.63:38088", the name of the system to be accessed is "hui-build", and the user enters "hui-build" in the browser. The complete request address is as Figure 6 shown Figure 6 The resource request scenario provided by the embodiment of the present invention is: http: / / 10.40.2.63:38088 / hui-build. The browser front end can intercept this request and prevent the display of the login page of "hui-build", but instead generate a resource request based on the domain name information "10.40.2.63:38088" and the system identification information "ssoName=hui-build". Figure 7 The updated schematic diagram of the resource request scenario provided by the embodiment of the present invention:

[0093] The complete request address is updated to: http: / / 10.40.2.63:38088 / g / hsxone.omc / v / getUserAuthMenus?time=1661147719990&ssoName=

[0094] hui-build hui-build&to= / mainIndex.

[0095] When the gateway receives the resource request as Figure 7 shown, it will not return the login page information of the system to be accessed.

[0096] In an optional implementation manner, after the customer logs in successfully in the prior art, it can only return the response data of the home page of the system to be accessed to the customer and will not perform home page rendering, as Figure 8 shownFigure 8 It is an example diagram of the prior art without rendering the home page, which gives customers a bad experience. In order to ensure that after the customer successfully logs in, the home page of the system to be accessed can be successfully returned, an embodiment of the present invention also gives a possible implementation manner, that is:

[0097] When the request receiver receives a resource request, it extracts the system identification information from the resource request and stores the system identification information in a Cookie.

[0098] In this embodiment, after the request receiver obtains the resource request, it can preferentially obtain the system identification information ssoName from the request header. If ssoName does not exist in the request header, it is obtained from the request parameters. If ssoName does not exist in the request parameters either, the default ssoName is used. Then the information of ssoName is cached in the Cookie.

[0099] Since there may be multiple system logins, the request receiver (such as a gateway) can be designed as a multi-process. Different processes store the ssoName corresponding to different systems. Storing it in the Cookie here is to be able to obtain this information when redirecting to the request receiver next time. After the subsequent ticket verification is successful, the request is redirected to the home page of the ssoName system, as Figure 9 shown, Figure 9 is an example diagram after the home page rendering provided by the embodiment of the present invention. As Figure 8 compared with the provided result, customers more expect to get Figure 7 such a page, which improves the customer experience.

[0100] In an alternative implementation manner, in order to ensure that the request can be redirected to the request receiver, after the request receiver receives the resource request, it needs to provide a correct redirect address. Therefore, an embodiment of the present invention also gives an implementation manner, that is, the above step S404 can be executed in the following manner:

[0101] Generate a redirect address based on the domain name information of the request receiver, the preset domain name field, and the system identification information matching the system to be accessed, and send the redirect address to the request initiator;

[0102] Among them, the redirect address is used to instruct the request initiator to send a redirected resource request to the request receiver. It can be seen from the above generation method that the redirect address is a special url designed in the embodiment of the present invention, including a preset domain name field and system identification information. The system identification information is used to indicate the return of the front-end page of the system to be accessed after the resource request is successful.

[0103] When the request receiver is a gateway, the domain name information of the above request receiver can be the information composed of the IP address and port of the gateway.

[0104] A preset domain name field, which is used to instruct the request receiver to trigger the execution of the CAS server login process after receiving the redirected resource request. The system to be accessed can determine, based on this preset domain name field, that the redirected resource for the request receiver is a special URL, thereby triggering the subsequent process of generating the CAS server login address information.

[0105] In an embodiment of the present invention, the preset domain name field may be in the form of / single / cas / login, where "single" may be an identifier of a business system, which is not limited herein, that is, the preset domain name field includes the business system identifier and the CAS login information.

[0106] To facilitate understanding of the above redirection process, continue with the Figure 6 and Figure 7 shown scenario as an example. When the gateway receives the Figure 7 shown request and determines that there is no valid session identifier, it can generate a redirection address based on the domain name information "10.40.2.63:38088", the preset domain name field assumed to be " / hsair / cas / login", and the system identifier information "ssoName = hui-build", as Figure 10 shown. Figure 10 FIG. is a redirection schematic diagram provided by an embodiment of the present invention. Then the redirection address is: http: / / 10.40.2.63:38088 / hsair / cas / login?ssoName = hui-build.

[0107] The gateway can return a redirection response to the browser front-end, as Figure 10 shown. Figure 10 FIG. is a schematic diagram of the redirection response provided by an embodiment of the present invention. Among them, the content corresponding to Location is the above redirection address. After the request initiator receives the redirection response, it can initiate a redirected resource request according to the address indicated by Location, as Figure 11 shown. Figure 11 FIG. is a schematic diagram of the redirected resource request provided by an embodiment of the present invention. It can be seen that in Figure 11 , the request address url is exactly the address corresponding to Location in Figure 10 .

[0108] In an alternative embodiment, to ensure that the request initiator can accurately initiate a login request to the CAS service, after the request receiver receives the redirected resource request, it can organize the login address information sent to the CAS server to instruct the request initiator to initiate a login request to the CAS server. Therefore, the above step S406 can be participated in Figure 12 , Figure 12Schematic flowchart of step S404 provided by the embodiments of the present invention:

[0109] S404-1: When the request receiver detects a preset domain name field in the redirected resource request, generate request parameters;

[0110] Among them, the request parameters are used to instruct the CAS server to redirect to the request receiver after the user login information is successfully verified;

[0111] S404-2: Generate a login address based on the request parameters and the domain name information of the CAS server;

[0112] S404-3: Add a preset response header field to the response header, and use the login address as the content of the response header field to generate a target response message;

[0113] Among them, the preset response header field is used to instruct the request initiator to send a login request by calling a preset sending function according to the login address.

[0114] In the embodiments of the present invention, after the request receiver receives the redirected resource request, it will first determine whether the request url in the resource request is a special login url, that is, determine whether there is a preset domain name field. For example, assume that the preset domain field is / hsair / cas / login. If / hsair / cas / login exists in the redirected resource request, it indicates the current received special login url.

[0115] If it is a special login url, return a response 200, and add a preset response header field to the response header. The preset response field can be composed of the business system identifier in the CAS and the preset domain name field. For example, if the preset domain name field is / hsair / cas / login and the business system identifier is hsair, then the preset response header field can be expressed as: Hsiar-Cas.

[0116] The content corresponding to the preset response header field is the url sent to the CAS server, that is, the above-mentioned login address, and these information are provided to the request initiator as the target response message.

[0117] Similarly, since the request initiator can receive a large number of response messages at the same time, but not every response message needs to be processed correspondingly. Therefore, for the received response messages, the request initiator can first determine whether there is a preset response header field. If there is this preset response header field, it will initiate a document request in the way of window.location.ref, and the url of the request is the content of the preset response field, that is, the above-mentioned login address; if not, it can be left unprocessed.

[0118] For the convenience of understanding the above embodiments, continue with the Figure 11 illustrated scenario as an example:

[0119] In Figure 11 , the url of the redirected resource request is: http: / / 10.40.2.63:38088 / hsair / cas / login?ssoName=hui-build. When the gateway receives the redirected resource request and detects the preset domain name field " / hsair / cas / login", it can generate request parameters based on the above url, and the request parameter is named service:

[0120] service=http%3A%2F%2F10.40.2.63%3A38088%2Fcas%2Fusr%2Flogin%3FssoName%3Dhui-build.

[0121] According to the rules of CAS single sign-on, after the CAS server successfully verifies the username and password, it will redirect an address with a ticket, and this address is the address after decoding the above request parameters: http: / / 10.40.2.63:38088 / cas / usr / login?ssoName=hui-build.

[0122] Assume that the domain name information of the CAS server is: 192.168.86.165:18081. Then the login address generated based on the above request parameters and the domain name information of the CAS server can be expressed as: http: / / 192.168.86.165:18081 / cas / login?service=http%3A%2F%2F10.40.2.63%3A38088%2FCAS%2Fusr%2Flogin%3FssoName%3Dhui-build.

[0123] The generated target response information can be seen in Figure 13 , Figure 13 which is a schematic diagram of the target response information provided by the embodiments of the present invention.

[0124] After the browser front-end receives the target response information as shown in Figure 13 , it will cooperate with the gateway to determine whether there is a preset response header field Hsiar-Cas. If so, it will obtain the content corresponding to Hsiar-Cas, and then initiate a document request (a directly called function) in the way of window.location.ref, and the url of the request is the content specified by the preset response header field Hsiar-Cas in Figure 13 . AsFigure 14 As shown, Figure 14 An example diagram of a CAS server login request provided in an embodiment of the present invention.

[0125] It is understandable that after receiving the login request, the CAS server detects whether there is a global ticket TGC in the request header or whether the session specified in TGC has expired. If so, it will return to the login page and ask the customer to enter the username and password. After the customer enters the username and password, it will re-initiate the request. After the CAS server successfully verifies the username and password, it generates a TGC session and ticket, and then redirects to the address matched by the request parameters in the login address.

[0126] For example, taking the above request parameters as an example, the address matched by the request parameters is http: / / 10.40.2.63:38088 / cas / usr / login?ssoName=hui-build, then the redirected url is: http: / / 10.40.2.63:38088 / cas / usr / login?ssoName=hui-build&ticket=xxx, which points to the request recipient.

[0127] When the request recipient receives the redirect request and obtains the ticket information contained in the request parameters, it continues to take the ticket to the CAS server for verification to confirm that the ticket is not forged by the client but generated by the CAS server. In addition to the uri and ticket parameters, the other contents of the request assembled and sent to the CAS server must be completely consistent with the value after the request parameter service to ensure that the CAS server can accurately return the ticket verification response information to the request recipient.

[0128] In an optional implementation, when the request recipient receives a response message indicating successful ticket verification from the CAS server, a redirect address for a password-free login request is generated and sent to the request initiator; the password-free login request is used to obtain the user's permission information for the system to be accessed.

[0129] In an embodiment of the present invention, the response message of successful ticket verification will include the user's login information, mainly the login username information. After the request recipient receives the response message of successful ticket verification, it will return a redirect. The redirect address is a password-free login request, which is used to obtain user authority information. The password-free login request includes token information that matches the requesting access party. The browser can continue the password-free login request with the token. At this point, the entire single sign-on is completed.

[0130] It can be understood that the single sign-out process is similar to the single sign-in process provided by this application, and will not be elaborated here.

[0131] In an alternative embodiment, the request receivers may be deployed in a cluster, and multiple request receivers may be uniformly managed by a load balancing server. In this scenario, steps S404 and S406 may be executed as follows:

[0132] Step S404: If not, redirect the resource request to the request receiver, specifically: redirect the resource request to the load balancing server;

[0133] Step S406: After receiving the redirected resource request, the request receiver generates target response information and sends the target response information to the request initiator, specifically: after the request receiver generates the target response information, it redirects to the load balancing server so that the load balancing server forwards the target response information to the request initiator.

[0134] To facilitate understanding of the single sign-on implementation method under the above cluster deployment, another scenario schematic diagram is given in an embodiment of the present invention. Please refer to Figure 15 , Figure 15 which is another scenario schematic diagram of the single sign-on method provided by the embodiment of the present invention.

[0135] 1. The request initiator sends a resource request for the system to be accessed to the load balancing server.

[0136] It should be noted that the resource request sent here is an Ajax request.

[0137] 2. The load balancing server forwards the request to one of the request receivers according to the load balancing policy.

[0138] 3. The request receiver detects that it is not logged in and first redirects to the load balancing server.

[0139] 4. The load balancing server forwards the redirect response to the request initiator.

[0140] 5. The request initiator obtains the redirect url from the redirect response and sends a request to the load balancing server.

[0141] 6. The load balancing server forwards the request to the request receiver.

[0142] 7. After receiving the request, the request receiver sets a special response header field when it determines that it is a special url, and generates target response information and sends it to the load balancing server.

[0143] 8. The load balancing server forwards the target response information to the request initiator.

[0144] 9. Finally, the request initiator obtains the URL from the special response header field and resends a login request to the CAS server through window.location.ref.

[0145] After that, single sign-on can be completed and resources can be obtained in the manner of steps 6 to 12 in Figure 5 to obtain resources.

[0146] Based on the same inventive concept, the single sign-on device 500 provided by an embodiment of the present invention may include: a determination module 510, a redirection module 520, and a generation module 530. Please refer to Figure 16 , Figure 16 which is a functional module diagram of the single sign-on device provided by an embodiment of the present invention, where:

[0147] The determination module 510 is configured to determine whether there is a valid session identifier matching the system to be accessed in the resource request when receiving a resource request for the system to be accessed; wherein, the type of the resource request is a same-origin restriction type, and the same-origin restriction type indicates that the source site and the destination site of the request need to have the same protocol, domain name, and port;

[0148] The redirection module 520 is configured to redirect the resource request to the request receiver if not;

[0149] The generation module 530 is configured to generate a target response message after receiving the redirected resource request and send the target response message to the request initiator; wherein, the target response message is used to instruct the request initiator to call a preset sending function to send a login request to the CAS server; the login request is not a request of the same-origin restriction type.

[0150] It can be understood that the determination module 510, the redirection module 520, and the generation module 530 can cooperate to execute Figure 4 each step in to achieve the corresponding technical effects.

[0151] In an optional implementation manner, the redirection module 520 is specifically configured to:

[0152] Generate a redirection address based on the domain name information of the request receiver, a preset domain name field, and system identifier information matching the system to be accessed, and send the redirection address to the request initiator;

[0153] wherein, the redirection address is used to instruct the request initiator to send a redirected resource request to the request receiver; the system identifier information is used to indicate the front-end page of the system to be accessed to be returned after the resource request is successful; the preset domain name field is used to instruct the request receiver to trigger the execution of the CAS server login process after receiving the redirected resource request.

[0154] In an alternative embodiment, the generation module 530 is specifically configured to:

[0155] When the request recipient detects a preset domain name field in the redirected resource request, generate request parameters; wherein the request parameters are used to instruct the CAS server to redirect to the request recipient after successful verification of the user login information;

[0156] Generate a login address based on the request parameters and the domain name information of the CAS server;

[0157] Add a preset response header field to the response header, and use the login address as the content of the response header field to generate a target response message;

[0158] Wherein the preset response header field is used to instruct the request initiator to send a login request by calling a preset sending function according to the login address.

[0159] In an alternative embodiment, the resource request is generated by the request initiator based on the domain name information of the request recipient and the system identification information matching the system to be accessed; the resource request is used to prohibit the return of the login page of the system to be accessed to the request initiator.

[0160] In an alternative embodiment, when the request recipient receives the resource request, extract the system identification information from the resource request and store the system identification information in a Cookie.

[0161] In an alternative embodiment, when the request recipient receives a response message with successful ticket verification, generate a redirect address for the passwordless login request and send the redirect address to the request initiator; the passwordless login request is used to obtain the permission information of the user in the system to be accessed.

[0162] In an alternative embodiment, there are multiple request recipients, and the multiple request recipients are managed by a load balancing server; the redirect module 520 is specifically configured to redirect the resource request to the load balancing server, and the generation module 530 is specifically configured to redirect to the load balancing server after generating the target response message, so that the load balancing server transmits the target response message to the request initiator.

[0163] The single sign-on device provided by the present invention includes: a determination module, a redirection module, and a generation module. The determination module is configured to determine whether there is a valid session identifier matching the system to be accessed in the resource request when receiving a resource request for the system to be accessed; wherein, the type of the resource request is a same-origin restriction type, and the same-origin restriction type indicates that the source site and the destination site of the request need to have the same protocol, domain name, and port. The redirection module is configured to, if not, redirect the resource request to the request receiver. The generation module is configured to generate a target response message after receiving the redirected resource request and send the target response message to the request initiator; wherein, the target response message is used to instruct the request initiator to call a preset sending function to send a login request to the CAS server; the login request is not a request of the same-origin restriction type. This application solves this cross-domain problem by redirecting the resource request to the request receiver itself, thus solving the cross-domain problem. In order to continue to implement single sign-on, after receiving the redirected resource request, the request receiver will generate a target response message and feedback it to the request initiator to instruct the request initiator to send a login request to the CAS server after receiving the target response message, completing the single sign-on process. The entire process of solving the cross-domain problem does not require additional configuration of the client system or the CAS server, which can reduce the device production and maintenance costs.

[0164] An embodiment of the present invention further provides a readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the single sign-on method in any one of the foregoing embodiments. The readable storage medium may be, but is not limited to, various media such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a PROM, an EPROM, an EEPROM, a magnetic disk, or an optical disc that can store program codes.

[0165] It should be understood that the devices and methods disclosed in the present invention can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions, and operations of devices, methods, and computer program products according to multiple embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and the module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0166] In addition, the functional modules in various embodiments of the present invention may be integrated together to form an independent part, or each module may exist alone, or two or more modules may be integrated to form an independent part.

[0167] If a function is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of this 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 for causing an electronic device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods according to the various embodiments of the present invention. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program codes. It should be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variation thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article or device including the element.

[0168] The above are only the preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention. It should be noted that similar reference numerals and letters denote similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings.

Claims

1. A single sign-on method, characterized in that, it is applied to a single sign-on device in an electronic device, and the electronic device is installed with a system to be accessed. The method includes: When the single sign-on device receives a resource request for the system to be accessed as a request recipient, determining whether there is a valid session identifier matching the system to be accessed in the resource request; wherein, the type of the resource request is a same-origin restriction type, and the same-origin restriction type indicates that the source site and the destination site of the request need to have the same protocol, domain name, and port; If not, redirecting the resource request to the request recipient; After receiving the redirected resource request, the request recipient generates a target response message and sends the target response message to the request initiator; wherein, the target response message is used to instruct the request initiator to call a preset sending function to send a login request to the CAS server; the login request is not a request of the same-origin restriction type.

2. The method according to claim 1, characterized in that, if not, redirecting the resource request to the request recipient includes: Generating a redirect address based on the domain name information of the request recipient, a preset domain name field, and system identifier information matching the system to be accessed, and sending the redirect address to the request initiator; wherein, the redirect address is used to instruct the request initiator to send the redirected resource request to the request recipient; the system identifier information is used to instruct to return the front-end page of the system to be accessed after the resource request is successful; the preset domain name field is used to instruct the request recipient to trigger the execution of the CAS server login process after receiving the redirected resource request.

3. The method according to claim 1, characterized in that, After receiving the redirected resource request, the request recipient generates a target response message and sends the target response message to the request initiator, including: When the request recipient detects that there is a preset domain name field in the redirected resource request, generating request parameters; wherein, the request parameters are used to instruct the CAS server to redirect to the request recipient after the user login information is verified successfully; Generating a login address based on the request parameters and the domain name information of the CAS server; Adding a preset response header field in the response header and using the login address as the content of the response header field to generate the target response message; wherein, the preset response header field is used to instruct the request initiator to send a login request by calling a preset sending function according to the login address.

4. The method according to claim 1, characterized in that, The resource request is generated by the request initiator based on the domain name information of the request recipient and system identifier information matching the system to be accessed; the resource request is used to prevent the login page of the system to be accessed from being returned to the request initiator.

5. The method according to claim 4, characterized in that, The method further includes: When the request recipient receives the resource request, extract the system identification information from the resource request and store the system identification information in a Cookie.

6. The method according to claim 1, wherein, the method further includes: when the request recipient receives a response message indicating successful ticket verification, generate a redirect address for the passwordless login request and send the redirect address to the request initiator; the passwordless login request is used to obtain the permission information of the user in the to-be-accessed system.

7. The method according to claim 1, wherein, there are multiple request recipients, and the multiple request recipients are managed by a load balancing server; if not, redirecting the resource request to the request recipient includes: redirecting the resource request to the load balancing server; after receiving the redirected resource request, the request recipient generates target response information and sends the target response information to the request initiator, including: after generating the target response information, the request recipient redirects to the load balancing server, so that the load balancing server forwards the target response information to the request initiator.

8. A single sign-on device, wherein, applied to an electronic device, the electronic device is installed with a to-be-accessed system, including: a determination module, configured to determine whether there is a valid session identifier matching the to-be-accessed system in the resource request when receiving a resource request for the to-be-accessed system; wherein, the type of the resource request is a same-origin restriction type, and the same-origin restriction type indicates that the source site and the destination site of the request need to have the same protocol, domain name, and port; a redirect module, configured to redirect the resource request to the single sign-on device itself if not; a generation module, configured to generate target response information after receiving the redirected resource request and send the target response information to the request initiator; wherein, the target response information is used to instruct the request initiator to call a preset sending function to send a login request to a CAS server; the login request is not a request of the same-origin restriction type.

9. An electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein, when the processor executes the computer program, the single sign-on method according to any one of claims 1 to 7 is implemented.

10. A readable storage medium, on which a computer program is stored, wherein, when the program is executed by a processor, the single sign-on method according to any one of claims 1 to 7 is implemented.

Images