CN115664761A

CN115664761A - Single sign-on method and device, electronic equipment and readable storage medium

Info

Publication number: CN115664761A
Application number: CN202211281279.6A
Authority: CN
Inventors: 张嘉佳; 乔志奇; 朱时永; 李超杰; 张�杰; 张昆
Original assignee: Hundsun Technologies Inc
Current assignee: Hundsun Technologies Inc
Priority date: 2022-10-19
Filing date: 2022-10-19
Publication date: 2023-01-31

Abstract

According to the single sign-on method, the single sign-on device, the electronic equipment and the readable storage medium, when a request receiving party receives a resource request aiming at the homologous restriction type of a system to be accessed, whether an effective session identifier matched with the system to be accessed exists is determined; if not, redirecting the resource request to a request receiver; the request receiver generates target response information after receiving the redirected resource request and sends the target response information to the request initiator; the target response information is used for indicating 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 source restriction type. The invention redirects the resource request to the request receiver, generates the target response information and feeds the target response information back to the request initiator to indicate the request initiator to send the login request to the CAS service after receiving the target response information to complete single sign-on, thereby solving the cross-domain problem and needing no additional configuration to the client system or the CAS server.

Description

Single sign-on method and device, electronic equipment and readable storage medium

Technical Field

The invention relates to the field of computer networks, in particular to a single sign-on method, a single sign-on device, electronic equipment and a readable storage medium.

Background

Single sign-on is a popular solution for enterprise business integration. A plurality of applications are subjected to login authentication based on a uniform account center and share a login state, namely, a user can access all mutually trusted applications only by logging in once; and logout at one place is global logout.

In the existing single sign-on scheme, when a user does not log in a system to be accessed, the user generally needs to redirect to a CAS server from the system to be accessed for login authentication, at this time, the system to be accessed and the CAS server have a cross-domain problem in different domains, which may cause no response to a request or an error report, and a related technology for solving the cross-domain problem either has a defect of complex operation or needs to modify system configuration to increase maintenance cost, so how to provide a simple and efficient single sign-on scheme capable of solving the cross-domain problem is a technical problem to be solved.

Disclosure of Invention

An objective of the present invention is to provide a single sign-on method, apparatus, electronic device and readable storage medium, so as to solve the cross-domain problem in the single sign-on process based on CAS service.

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, the method including: when a request receiver receives a resource request aiming at the system to be accessed, determining whether an effective session identifier matched with the system to be accessed exists in the resource request; the resource request type is a homologous restriction type, and a source site and a destination site of the resource request are represented by the homologous restriction type and 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 receiving party generates target response information and sends the target response information to the request initiating party; the target response information is used for indicating 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.

In a second aspect, the present invention provides a single sign-on apparatus, applied to an electronic device, where the system to be accessed is installed in the electronic device, including: the determining module is used for determining whether an effective session identifier matched with the system to be accessed exists in the resource request when the resource request aiming at the system to be accessed is received; the resource request type is a homologous restriction type, and a source site and a destination site of the resource request are represented by the homologous restriction type and need to have the same protocol, domain name and port; a redirection module, configured to redirect the resource request to the request receiver if the resource request does not exist; the generation module is used for generating target response information after receiving the redirected resource request and sending the target response information to a request initiator; the target response information is used for indicating 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.

In a third aspect, the present invention provides an electronic device, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the single sign-on method according to the first aspect when executing the computer program.

In a fourth aspect, the present invention provides a readable storage medium having stored thereon a computer program which, when executed by a processor, implements the single sign-on method of the first aspect.

Compared with the prior art, the single sign-on method, the single sign-on device, the electronic equipment and the readable storage medium provided by the invention have the main differences that: in the prior art, after receiving a resource request, an access system redirects the resource request to a CAS service end, and a cross-domain problem easily occurs in the redirection process, which results in a request error report or no response. The whole process for solving the cross-domain problem does not need to carry out additional configuration on a client system or a CAS (CAS) server, so that the production and maintenance cost of the equipment can be reduced.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present invention and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained according to the drawings without inventive efforts.

FIG. 1 is a schematic diagram of a single sign-on;

fig. 2 is a schematic view of a single sign-on method according to an embodiment of the present invention;

fig. 3 is a block diagram of an electronic device according to an embodiment of the present invention;

FIG. 4 is a schematic flow chart of a single sign-on method according to an embodiment of the present invention;

fig. 5 is a scene schematic diagram of a single sign-on method according to an embodiment of the present invention;

fig. 6 is a resource request scenario provided by an embodiment of the present invention;

fig. 7 is a schematic diagram illustrating an update of a resource request scenario according to an embodiment of the present invention;

FIG. 8 is an exemplary diagram of a prior art rendering of a home page;

FIG. 9 is an exemplary diagram after rendering of a home page provided by an embodiment of the present invention;

FIG. 10 is a schematic illustration of redirection provided by an embodiment of the present invention;

FIG. 11 is a diagram illustrating a redirected resource request according to an embodiment of the present invention;

fig. 12 is a schematic flowchart of step S404 provided by the embodiment of the present invention;

FIG. 13 is a diagram illustrating a target response message according to an embodiment of the present invention;

FIG. 14 is a diagram illustrating an example of a CAS server login request provided by an embodiment of the present invention;

fig. 15 is a schematic view of another scenario of a single sign-on method according to an embodiment of the present invention;

fig. 16 is a functional block diagram of a single sign-on apparatus according to an embodiment of the present invention.

Detailed Description

In order to make the objects, 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 drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. The components of embodiments of the present invention generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations.

Thus, the following detailed description of the embodiments of the present invention, presented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

In the description of the present invention, it should be noted that, if the terms "upper", "lower", "inner", "outer", etc. are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings or the orientation or positional relationship which the product of the present invention is used to usually place, it is only for convenience of description and simplification of the description, but it is not intended to indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus, should not be construed as limiting the present invention.

Furthermore, the appearances of the terms "first," "second," and the like, if any, are used solely to distinguish one from another and are not to be construed as indicating or implying relative importance.

It should be noted that the features of the embodiments of the present invention may be combined with each other without conflict.

Single Sign On (SSO) is an authentication method, and a user can log On only once and access multiple applications, systems or Web sites that are trusted with each other by using one user ID and password. The single sign-on technology improves user experience, reduces the cost of managing user names and passwords on a large number of applications, and improves working efficiency.

For example, there are multiple systems, such as forums, collaborations, human resource systems, etc., that are common in both traditional and internet enterprises. If the user needs to input the user name and the password when accessing each system, the steps are complicated, and the user experience is poor. A unified login system is therefore required. CAS is a single sign-on system for Web applications, which a user can use for single sign-on and sign-off.

Referring to fig. 1, fig. 1 is a schematic diagram of a single sign-on principle, and the completion of the single sign-on may include the following steps:

s1, the browser sends a request for accessing the limited resource to an application system.

S2, the application system detects that the user does not log in, and redirects to the CAS server.

And S3, the browser initiates a login request to the CAS server side.

And S4, if the CAS server detects that no effective session identifier exists, returning a login page to the browser.

And S5, the browser sends the user name and the user password to the CAS server.

And S6, after the CAS server successfully verifies the user name and the user password, creating a global session, attaching the generated bill to the request for acquiring the limited resource, and redirecting to the application system.

And S7, the browser sends a request for accessing the limited resource to the application system with the ticket.

And S8, after the application system obtains the bill, sending a bill verification request to the CAS server.

And S9, after the CAS server verifies that the bill is valid, sending a message of successful verification to the application system.

And S10, returning the limited resources to the browser by the application system.

In the existing single sign-on scheme, when a user does not log in a system to be accessed, the user generally needs to redirect to a CAS server from the system to be accessed to perform login authentication (i.e., the application system is redirected to the CAS server in step 2), at this time, the system to be accessed and the CAS server have different domains, a cross-domain problem exists, and a request may not be responded or an error may be reported.

The above cross-domain problem is referred to as: at least one of the protocol, domain name and port of the request actually sent is inconsistent with the content displayed in the address bar of the browser, the redirected request does not mean a new request but continues the original request, and after redirection, the site application system, application system and CAS server of the request are different in source, namely the domain name, protocol and port are different, so that the cross-domain problem occurs.

In the existing scheme of using CAS to perform single sign-on, a native CAS filter (CAS client) may be used to perform single sign-on, that is, the CAS filter is integrated in a server of a service system to be accessed, but after this way is used, in a scenario where there are multiple application systems, for example, an application system a already has a single sign-on system, another application system B needs to interface with this single sign-on system, and at this time, the application system B needs to integrate the CAS filter in its server, in the process of accessing the application system B, a cross-domain problem still exists when jumping to the CAS server, that is, different application systems all need to refer to a jar package of the CAS filter, and if different application systems share a CAS server, a cross-domain problem also exists.

The related art also proposes some solutions, but these solutions have other drawbacks:

the first scheme is as follows: all front ends need to be deployed on native nginx, and both the application system and the CAS server need to be routed through native nginx, and the location information of static resources is configured in the nginx. These are not only cumbersome to operate and prone to errors, but also restart nginx due to system upgrade, which is more restrictive, and each time the system is added, the nginx configuration needs to be modified and restarted, which increases maintenance costs.

Scheme II: in order to facilitate the relevant test on the CAS server, the CAS server is open source, so the related art allows cross-domain by modifying the CAS server source code, but modification of the CAS server source code without authorization has a great safety hazard, so modification of the CAS server source code is usually not allowed, and in addition, in a scenario that a single sign-on system interface with a customer is required, it is not practical to require the customer to modify CAS logic.

In addition, although a client system is required to have a perfect single sign-on system, in order to expand business requirements, a business system developed by another service provider may be required to implement some business functions, and therefore, how to embed the business system into the client single sign-on system and enable the business system to be capable of interfacing with the client single sign-on system is also a technical problem to be solved.

Based on the technical problems, the embodiment of the present invention provides a single sign-on method, which can achieve the effect of solving the cross-domain problem in the scenario where the system to be accessed is docked with the client single sign-on system, and the following describes in detail the single sign-on method provided by the embodiment of the present invention with reference to the related drawings.

First, referring to fig. 2, fig. 2 is a schematic view of a scenario of a single sign-on method provided by an embodiment of the present invention, where the scenario includes a terminal 201 and a CAS server 202, and the terminal 201 and the CAS server 202 are connected through a network, where:

the CAS server 202 may be a server or a server cluster, and is connected to the terminal 201 through a communication network, so as to provide a corresponding authentication service for the client single sign-on system.

The communication Network may be a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a mobile Network, a wired Network, a wireless Network, a private Network, or the like.

The terminal 201 may be, but is not limited to: smart phones, computers, tablets, personal computers, and the like. The system 203 to be accessed can be independently deployed on the terminal 201, and the system 203 to be accessed refers to a system capable of providing business services for customers, such as an order system, a report system and the like. The number of the systems 203 to be accessed may be one or more, and the systems 203 to be accessed may be from the same service provider or from different service providers, which is not limited in this embodiment of the application.

The terminal 201 can also be deployed with a client single sign-on system, and the embodiment of the invention provides the single sign-on device 500, so that the system 203 to be accessed can be in butt joint with the client single sign-on system, and the complicated operation that the client can only log in the system to be accessed by inputting user information every time is avoided, and the single sign-on device 500 can be deployed in a software module or hardware mode. The single sign-on apparatus 500 can not only become a complete CAS client by itself, but also embed its own interface into the counterpart system and share the single sign-on service with the counterpart system.

In an alternative embodiment, the single sign-on apparatus 500 may be deployed in software as a module with a routing function on the system 203 to be accessed.

In another alternative embodiment, the single sign-on apparatus 500 may be disposed on the terminal 201 separately from the system 203 to be accessed in a software or hardware manner.

The embodiment of the present invention does not limit the two embodiments.

In the embodiment of the present application, the single sign-on device 500 is a functional module with a routing function, and may be, but is not limited to, a gateway, such as openreserve, where openreserve is a high-performance Web platform based on Nginx and Lua, and the single sign-on device has strong extensibility and high performance, and is generally used for a microservice unified access gateway.

In the embodiment of the present invention, in order to solve the cross-domain problem in the redirection technology, the core of the single sign-on method is: after receiving the request for the system 203 to be accessed, the single sign-on device 500 may redirect the request to the single sign-on device 500 itself, so that both the source site and the destination site of the redirected request are the single sign-on devices 500, thereby solving the cross-domain problem, and after solving the cross-domain problem, in order to implement the single sign-on function of the system 203 to be accessed, the single sign-on device 500 may further generate a response message, where the response message includes key information for triggering execution of a CAS server login authentication procedure, and after receiving the response message, the request initiator may send a login request to the CAS server in a manner of calling a function, thereby completing the login authentication and also avoiding sending the request across domains.

It should be noted that the scenario shown in fig. 2 is only an example, in order to enable the system to be accessed to interface with the client single sign-on system, the client single sign-on system and the system to be accessed 203 according to the embodiment of the present application may be independently deployed on the terminal 201, and in other scenarios, the client single sign-on system and the system to be accessed 203 may be independently deployed on different terminals, for example, the system to be accessed 203 is deployed on the terminal 201, and the client single sign-on system is deployed on other terminals, which are not limited in the embodiments of the present invention.

Referring to fig. 3, fig. 3 is a block diagram of an electronic device according to an embodiment of the present invention, where the electronic device may be, but is not limited to, the terminal 201 in fig. 1, and may be used to execute the single sign-on method according to the embodiment of the present invention.

As shown in fig. 3, the electronic device 300 comprises a memory 301, a processor 302 and a communication interface 303, wherein the memory 301, the processor 302 and the communication interface 303 are electrically connected to each other directly or indirectly to realize data transmission or interaction. For example, the components may be electrically connected to each other via one or more communication buses or signal lines.

The memory 301 may be used to store software programs and modules, such as the single sign-on device 500 and the instructions/modules of the system 203 to be accessed, which may be stored in the memory 301 in the form of software or firmware or fixed in an Operating System (OS) of the electronic device 300, and the processor 302 executes the software programs and modules stored in the memory 301 to perform various functional applications and data processing. The communication interface 303 may be used for communicating signaling or data with other node devices.

The Memory 301 may be, but is not limited to, a Random Access Memory (RAM), a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Read-Only Memory (EPROM), an electrically Erasable Read-Only Memory (EEPROM), and the like.

The processor 302 may be an integrated circuit chip having signal processing capabilities. The processor 302 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; but also Digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.

It will be appreciated that the configuration shown in fig. 3 is merely illustrative and that electronic device 300 may include more or fewer components than shown in fig. 3 or have a different configuration than shown in fig. 3. The components shown in fig. 3 may be implemented in hardware, software, or a combination thereof.

Referring to fig. 4, fig. 4 is a schematic flowchart of a single sign-on method provided by an embodiment of the present invention, where the method includes the following steps:

s402, when the request receiver receives the resource request aiming at the system to be accessed, whether the effective session identification matched with the system to be accessed exists in the resource request is determined.

In this embodiment of the present invention, the request receiving party is the single sign-on device 500 in this embodiment of the present invention, the resource request is from the request initiating party, the request initiating party may be a front end of a browser, for example, a browser is installed on the terminal 201, the client inputs the name of the system to be accessed through the browser, so as to generate a resource request for the system to be accessed, and then the front end sends out the resource request, so the request initiating party may be understood as the front end.

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

The resource request in the embodiment of the present invention is a request of a homologous restriction type, that is, an Ajax request issued by a browser, where the "homologous restriction" requires that a source site and a destination site of the request have the same protocol, domain name and port, and in the process of sending the request of this type, it may be, but is not limited to, indicated that the request has a homologous restriction by an origin field. Because of such limitation, the cross-domain problem occurs in the process of redirecting the application system to the CAS server in fig. 1, and therefore the single sign-on method for solving the cross-domain problem provided by the present application is directed to the Ajax request.

In the embodiment of the invention, the effective session identifier matched with the system to be accessed is generated when the client logs in the system to be accessed, and if the identifier does not exist, the user does not log in the system to be accessed before. The cookie carried in the resource request is used for caching the session identifier, and is usually a token field in the cookie, after the system to be accessed receives the resource request, whether the cookie is the token field matched with the system to be accessed can be checked, if not, it indicates that the client has not logged in the system to be accessed, and the access is the first access.

And S404, if the resource request does not exist, redirecting the resource request to a request receiver.

In order 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 obviously different from the single sign-on process shown in fig. 1, and redirects the resource request to the request receiver itself, so that the source site of the request is the request receiver, and the target site of the request is also the request receiver, thereby solving the cross-domain problem in the redirection process.

In the embodiment of the present invention, after the resource request is redirected to the request receiver itself, after it is determined that the client has not logged in the system to be accessed, the client needs to be directed to complete login authentication through the CAS server, so as to achieve the effect of interfacing with the client single-point login system, and therefore, step S406 may be executed.

S406, the request receiver generates target response information after receiving the redirected resource request.

It can be understood that, redirecting the resource request to the request receiver itself has already been an effect of solving the cross-domain problem, but in order to enable the system to be accessed to interface with the single sign-on system of the client, the login authentication needs to be completed through the CAS server, so that the request receiver generates the target response message after receiving the redirected resource request.

The target response information is used for indicating the request initiator to call the preset sending function to send the login request to the CAS server, and the initiated login request is not a request of a same source restriction type, so that origin restriction is broken through, and the cross-domain problem is avoided.

In the embodiment of the invention, the preset sending function can be window.location.ref, the login request is sent in a window.location.ref mode, which is equivalent to a request mode of directly inputting a website in a browser, and the sent request is not an Ajax request but a Document request, so that the problem of cross-domain is avoided.

It can be understood that the target response message may include login address information of the CAS server, and after the request initiator obtains the target response message, the single sign-on may be completed according to the flow from step 3 to step 10 shown in fig. 1.

Compared with the prior art, the single sign-on method provided by the embodiment of the invention has the main differences that: in the prior art, after receiving a resource request, an access system redirects the resource request to a CAS service end, and a cross-domain problem easily occurs in the redirection process, which results in a request error report or no response. The whole process for solving the cross-domain problem does not need to carry out additional configuration on a client system or a CAS (CAS) server, so that the production and maintenance cost of the equipment can be reduced.

For convenience of understanding of the embodiment of the present invention, an implementation scenario is given below, please refer to fig. 5, fig. 5 is a scenario schematic diagram of a single sign-on method provided by the embodiment of the present invention, and it can be seen by comparing fig. 5 with fig. 1 that, in step 3 of fig. 5, redirection to a request recipient itself can avoid a cross-domain problem occurring when redirection to a CAS service end occurs in step 2 of fig. 1, and, in step 5 of fig. 5, a login request is initiated in a function manner, which is different from that in fig. 1 in which a login request is directly sent through a browser.

In an optional embodiment, in order to enable the system to be accessed to interface with an existing single sign-on system of the client and complete single sign-on, instead of requiring the client to input user information each time the system to be accessed is logged on, the request initiator may perform special processing in the process of sending a resource request to the request receiver, that is:

the resource request is generated by a request initiator based on domain name information of the system to be accessed and system identification information matched with the system to be accessed; the resource request generated in this manner may be used to prohibit the system to be accessed from returning a login page to the request originator.

That is to say, if the request receiving party directly feeds back the login page of the system to be accessed after receiving the resource request, the user needs to manually input the user name and the password each time, the operation is complicated, and the user experience is poor.

Therefore, in the process of generating a resource request, the request initiator generates the resource request based on the domain name information of the request receiver and the system identification information matched with the system to be accessed, wherein the domain name information can be used as the destination of the request, the system identification information will be described in detail in the following content, and the resource request can play a role of prohibiting feedback of a login page of the system to be accessed.

To facilitate understanding of the above embodiments, the following practical examples are explained:

assuming that 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-built", the user inputs "hui-built" in the browser, the complete request address is as shown in fig. 6, and fig. 6 is a resource request scenario provided by the embodiment of the present invention, and is: http://10.40.2.63:38088/hui-build, the browser front end may intercept the request, and not let the login page displaying "hui-build", but generate a resource request based on the domain name information "10.40.2.63:

the complete request address is updated as: http://10.40.2.63:38088/g/hsxone. Omc/v/getUserAuthMenustime =1661147719990&ssoName =

hui-build hui-build&to＝/mainIndex。

When the gateway receives the resource request as shown in fig. 7, the login page information of the system to be accessed is not returned.

In an optional embodiment, in the prior art, after a client successfully logs in, only response data of a top page of a system to be accessed can be fed back to the client, and no top page rendering is performed, as shown in fig. 8, fig. 8 is an exemplary diagram of performing no top page rendering in the prior art, which gives a poor experience to the client, and in order to ensure that the client can successfully return to the top page of the system to be accessed after successfully logging in, an embodiment of the present invention further provides a possible embodiment, that is:

when the request receiver receives the resource request, the system identification information is extracted from the resource request and stored in the Cookie.

In this embodiment, after the request receiving side obtains the resource request, the system identification information ssoName may be preferentially obtained from the request header, and if the request header does not have the ssoName, the system identification information ssoName may be obtained from the request parameter, and if the request parameter does not have the ssoName, the default ssoName may be used. The ssoName information is then cached in the Cookie.

Since there may be a plurality of system logins, the request receiver (e.g. gateway) may be designed to have multiple processes, and different processes store ssonames corresponding to different systems, where the reason for placing the ssonames in the Cookie is to obtain the information when jumping to the request receiver next time. After the subsequent ticket check succeeds, the request is redirected to the ssoName system home page, as shown in fig. 9, fig. 9 is an exemplary diagram after the home page is rendered, as compared with the result provided in fig. 8, a client more expects to obtain the page in fig. 7, and the user experience is improved.

In an optional embodiment, in order to ensure that the resource request can be redirected to the request receiver, after the request receiver receives the resource request, a correct redirection address needs to be provided, so that an embodiment of the present invention further provides an implementation manner, that is, step S404 may be performed as follows:

generating a redirection address based on the domain name information of the request receiver, a preset domain name field and system identification information matched with the system to be accessed, and sending the redirection address to the request initiator;

as can be seen from the above generation manner, the redirection address is a special url designed in the embodiment of the present invention, and includes a preset domain name field and system identification information. The system identification information is used for indicating to return the front-end page of the system to be accessed after the resource request is successful.

When the request receiver is a gateway, the domain name information of the request receiver may be information consisting of an IP address and a port of the gateway.

And the preset domain name field is used for triggering and executing the CAS server login process after the request receiver receives the redirected resource request. The system to be accessed can determine that a special url is redirected to the request receiver based on the preset domain name field, so as to trigger the subsequent process of generating the CAS server login address information.

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

To facilitate understanding of the above redirection process, continuing with the scenario shown in fig. 6 and fig. 7 as an example, after the gateway receives the request shown in fig. 7, it is determined that there is no valid session identifier, and then a redirection address may be generated based on the domain name information "10.40.2.63, 38088", the preset domain name field is assumed to be "/hsair/cas/login", and the system identification information "ssoName = hui-build", as shown in fig. 10, fig. 10 is a redirection schematic diagram provided by the embodiment of the present invention, and then the redirection address is: http://10.40.2.63:38088/hsair/cas/loginssoName = hui-build.

As shown in fig. 10, fig. 10 is a schematic view of a redirection response provided in the embodiment of the present invention, where the content corresponding to Location is the redirection address, and after receiving the redirection response, the request initiator may initiate a redirected resource request according to the address indicated by the Location, as shown in fig. 11, and fig. 11 is a schematic view of a redirected resource request provided in the embodiment of the present invention, it can be seen that, in fig. 11, the request address url is the address corresponding to the Location in fig. 10.

In an optional embodiment, in order 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, the request receiver may arrange the login address information sent to the CAS service to indicate that the request initiator initiates a login request to the CAS service, so that step S406 may join fig. 12, where fig. 12 is a schematic flowchart of step S404 provided in the embodiment of the present invention:

s404-1: when a request receiver detects that a preset domain name field exists in a redirected resource request, generating a request parameter;

the request parameter is used for indicating that the CAS server redirects to a request receiver after the user login information is successfully verified;

s404-2: generating a login address based on the request parameters and the domain name information of the CAS server;

s404-3: adding a preset response header field in the response header, and generating target response information by using the login address as the content of the response header field;

the preset response header field is used for indicating a request initiator to call a preset sending function to send a login request according to a login address.

In the embodiment of the present invention, after receiving the redirected resource request, the request receiver may first determine whether the request url in the resource request is a special login url, that is, determine whether a preset domain field exists, for example, if the preset domain field is/hsair/cas/login, if/hsair/cas/login exists in the redirected resource request, it indicates that the currently received special login url exists.

If the login url is a special login url, the response 200 is returned, and a preset response header field is added to the response header, where the preset response field may be composed of a CAS and a service system identifier in a preset domain name field, for example, if the preset domain name field is/hsair/CAS/logic, and the service system identifier is hsair, the preset response header field may be represented as: hsiar-Cas.

The corresponding content of the preset response header field is url sent to the CAS server, namely the login address, and the information is used as target response information and is provided for the request initiator.

Similarly, because the request initiator can receive a large number of response messages at the same time, but not each response message needs to be correspondingly processed, the request initiator can first judge whether a preset response header field exists or not for the received response message, if the preset response header field exists, a document request is initiated in a window location. If not, no processing may be done.

For ease of understanding of the above embodiments, we proceed with the example of the scenario shown in fig. 11:

in FIG. 11, the url of the redirected resource request is: http://10.40.2.63:38088/hsair/cas/loginssoName = hui-build, the gateway receives the redirected resource request, and when detecting the preset domain name field "/hsair/cas/login", it may generate a request parameter based on the url, where the request parameter is named service:

service＝http％3A％2F％2F10.40.2.63％3A38088％2Fcas％2Fusr％2Flogin％3FssoName％3Dhui-build。

according to the rule of CAS single sign-on, after the CAS server verifies the user name and password successfully, it will redirect an address with the ticket, the address is the address after decoding the request parameter: http:// 10.40.2.63.

Suppose the domain name information of the CAS server is: 192.168.86.165, the login address generated based on the request parameters and the domain name information of the CAS server can be expressed as: http://192.168.86.165,// cas/loginervice = http% 3A-2F-The 2F10.40.2.63-3A38088-2FCAS-2Fusr-2Flogin-3Fssome Name-3Dhui-build-is calculated.

For the generated target response information, refer to fig. 13, and fig. 13 is a schematic diagram of the target response information provided in the embodiment of the present invention.

After receiving the target response information shown in fig. 13, the browser front end, in cooperation with the gateway, determines whether there is a preset response header field Hsiar-Cas, and if so, obtains the content corresponding to the Hsiar-Cas, and then initiates a document request (function called directly) in a window location. As shown in fig. 14, fig. 14 is an exemplary diagram of a CAS server login request according to an embodiment of the present invention.

It can be understood that, after receiving the login request, the CAS server detects whether the request header has the global ticket TGC or whether the session specified in the TGC has failed, and if so, returns to the login page, and lets the client input the user name and the password, and after the client inputs the user name and the password, the request is reinitiated, and after the CAS server verifies the user name and the password successfully, the CAS server generates the TGC session and the ticket token, and then redirects to the address matched with the request parameter in the login address.

Such as: continuing with the above example of request parameters, the address to which the request parameters are matched is http://10.40.2.63,// 3/usr// loginsoname = hui-build, then the url redirected is: http:// 10.40.2.63.

After the request receiver receives the redirection request, when ticket information contained in the request parameter is acquired, the ticket is continuously taken to the CAS server for verification, so that the ticket is determined to be generated by the CAS server instead of being forged by the client. Besides uri and ticket parameters, other contents of the assembled request sent to the CAS server must be completely consistent with values behind the request parameter service, so as to ensure that the CAS server can accurately return response information of bill verification to the request receiver.

In an optional implementation manner, when the request receiver receives a response message that the bill verification of the CAS server is successful, a redirection address of the password-free login request is generated, and the redirection address is sent to the request initiator; the password-free login request is used for acquiring the authority information of the user in the system to be accessed.

In the embodiment of the invention, the response message of successful bill verification comprises login information of a user, which is mainly login user name information, a request receiving party returns to redirect after receiving the response message of successful bill verification, the redirected address is a password-free login request used for acquiring user authority information, wherein the password-free login request comprises token information matched with the request accessing party, and the browser can drive the token to continue the password-free login request with the browser until the whole single sign-on is completed.

It is understood that the single sign-on process is similar to the single sign-on process provided herein and will not be described herein.

In an optional embodiment, the request receiver may sample a cluster deployment manner, and multiple request receivers may be uniformly managed by the load balancing server, in this scenario, the foregoing step S404 and step S406 may be performed as follows:

step S404, if not, redirecting the resource request to the request receiver, specifically: redirecting the resource request to a request load balancing server;

step S406, after the request receiver receives the redirected resource request, generating target response information, and sending the target response information to the request initiator, specifically: after the request receiving party generates the target response information, the target response information is redirected to the load balancing service end, so that the load balancing service end transmits the target response information to the request initiating party.

To facilitate understanding of the single sign-on implementation manner under the cluster deployment, an embodiment of the present invention provides another scenario schematic diagram, please refer to fig. 15, and fig. 15 is another scenario schematic diagram of the single sign-on method provided by the embodiment of the present invention.

1. And the request initiator requests the resource of the system to be accessed to the load balancing server.

It should be noted that the resource request sent here is Ajax request.

2. And the load balancing server forwards the request to one of the request receivers according to the load balancing strategy.

3. And the request receiver detects that the user does not log in, and redirects the request to the load balancing server side.

4. And the load balancing server transparently transmits the redirection response to the request initiator.

5. And the request initiator acquires the redirection url from the redirection response and initiates a request to the load balancing server.

6. And the load balancing server transparently transmits the request to a request receiver.

7. And after the request receiver receives the request, a special response header field is set under the condition of judging that the request is a special url, and target response information is generated and sent to the load balancing server.

8. And the load balancing server transmits the target response information to the request initiator.

9. And finally, the request initiator acquires the url from the special response header field and re-sends the CAS server login request through the window.

After that, the single sign-on can be completed in the manner of steps 6 to 12 in fig. 5, and the resource is obtained.

Based on the same inventive concept, the single sign-on apparatus 500 provided in the embodiment of the present invention may include: referring to fig. 16, fig. 16 is a functional block diagram of a single sign-on apparatus according to an embodiment of the present invention, where:

a determining module 510, configured to determine, when a resource request for a system to be accessed is received, whether an active session identifier matching the system to be accessed exists in the resource request; the resource request type is a homologous restriction type, and a source site and a destination site of the homologous restriction type representation request need to have the same protocol, domain name and port;

a redirection module 520, configured to redirect the resource request to the request receiver if the resource request does not exist;

a generating module 530, configured to generate target response information after receiving the redirected resource request, and send the target response information to the request initiator; the target response information is used for indicating a request initiator to call a preset sending function to send a login request to a CAS (CAS) server; the login request is not a request of the homologous restriction type.

It will be appreciated that the determining module 510, the redirecting module 520, and the generating module 530 may perform the various steps of fig. 4 in conjunction to achieve a corresponding technical effect.

In an alternative embodiment, the redirection module 520 is specifically configured to:

the redirection address is used for indicating a request initiator to send a redirected resource request to a request receiver; the system identification information is used for indicating to return to a front-end page of the system to be accessed after the resource request is successful; the preset domain name field is used for triggering and executing a CAS server login process after the request receiver receives the redirected resource request.

In an alternative embodiment, the generating module 530 is specifically configured to:

when a request receiver detects that a preset domain name field exists in a redirected resource request, generating a request parameter; the request parameter is used for indicating that the CAS server redirects to a request receiver after the user login information is successfully verified;

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 generating target response information by using the login address as the content of the response header field;

In an optional embodiment, the resource request is generated by the request initiator based on the domain name information of the request receiver and the system identification information matched with the system to be accessed; the resource request is used for forbidding to return a login page of the system to be accessed to the request initiator.

In an optional embodiment, when the request receiver receives the resource request, the system identification information is extracted from the resource request, and the system identification information is stored in the Cookie.

In an optional implementation mode, when a request receiver receives a response message of successful bill verification, a redirection address of a password-free login request is generated, and the redirection address is sent to a request initiator; the password-free login request is used for acquiring the authority information of the user in the system to be accessed.

In an optional implementation manner, a plurality of request receivers exist, and the plurality of request receivers are managed by the load balancing server; the redirecting module 520 is specifically configured to redirect the resource request to the request load balancing server, and the generating module 530 is specifically configured to redirect the resource request to the load balancing server after generating the target response information, so that the load balancing server transparently transmits the target response information to the request initiator.

The single sign-on device provided by the invention comprises: the system comprises a determining module, a redirecting module and a generating module, wherein the determining module is used for determining whether an effective session identifier matched with the system to be accessed exists in a resource request when the resource request aiming at the system to be accessed is received; the resource request type is a homologous restriction type, and a source site and a destination site of the homologous restriction type representation request need to have the same protocol, domain name and port; the redirection module is used for redirecting the resource request to a request receiver if the resource request does not exist; the generation module is used for generating target response information after receiving the redirected resource request and sending the target response information to the request initiator; the target response information is used for indicating a request initiator to call a preset sending function to send a login request to a CAS (CAS) server; the login request is not a request of the same source restriction type. In order to solve the cross-domain problem, the resource request is redirected to the request receiver, so that the cross-domain problem is solved, and in order to continuously realize single sign-on, the request receiver generates target response information and feeds the target response information back to the request initiator after receiving the redirected resource request, so as to indicate the request initiator to send a sign-on request to the CAS after receiving the target response information, and complete the single sign-on process. The whole process for solving the cross-domain problem does not need to carry out additional configuration on a client system or a CAS (CAS) server, so that the production and maintenance cost of the equipment can be reduced.

Embodiments of the present invention further provide a readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the single sign-on method according to any one of the foregoing embodiments. The readable storage medium can be, but is not limited to, various media that can store program codes, such as a U disk, a removable hard disk, a ROM, a RAM, a PROM, an EPROM, an EEPROM, a magnetic or optical disk, etc.

It should be understood that the disclosed apparatus and method may be embodied in other forms. The apparatus embodiments described above are merely illustrative, and for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

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

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing an electronic device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes. It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a … …" does not exclude the presence of another identical element in a process, method, article, or apparatus that comprises the element.

The above is only a preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes will occur to those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

Claims

1. A single sign-on method applied to an electronic device, wherein the electronic device is provided with a system to be accessed, and the method comprises the following steps:

when a request receiver receives a resource request aiming at the system to be accessed, determining whether an effective session identifier matched with the system to be accessed exists in the resource request; the resource request type is a homologous restriction type, and the homologous restriction type represents that a source site and a 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 target response information and sends the target response information to the request initiator;

the target response information is used for indicating 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 of claim 1, wherein redirecting the resource request to the request recipient if not present comprises:

wherein, the redirection address is used for indicating the request initiator to send the redirected resource request to the request receiver; the system identification information is used for indicating to return to a front-end page of the system to be accessed after the resource request is successful; and the preset domain name field is used for triggering and executing a CAS server login process after the request receiver receives the redirected resource request.

3. The method of claim 1, wherein the generating of the target response message and the sending of the target response message to the request initiator after the request receiver receives the redirected resource request comprises:

when the request receiver detects that a preset domain name field exists in the redirected resource request, request parameters are generated; the request parameter is used for indicating that the CAS server redirects to the request receiver after the user login information is successfully verified;

generating a login address based on the request parameter and the domain name information of the CAS server;

adding a preset response header field in a response header, and generating the target response information by using the login address as the content of the response header field;

and the preset response header field is used for indicating the request initiator to call a preset sending function to send a login request according to the login address.

4. The method according to claim 1, wherein the resource request is generated by the request initiator based on domain name information of the request receiver and system identification information matched with the system to be accessed; the resource request is used for forbidding to return the login page of the system to be accessed to the request initiator.

5. The method of claim 4, further comprising:

and when the request receiver receives the resource request, extracting the system identification information from the resource request, and storing the system identification information in the Cookie.

6. The method of claim 1, further comprising:

when the request receiver receives a response message of successful bill verification, generating a redirection address of a password-free login request, and sending the redirection address to the request initiator; the password-free login request is used for acquiring the authority information of the user in the system to be accessed.

7. The method according to claim 1, wherein there are a plurality of said request receivers, and a plurality of said request receivers are managed by a load balancing server;

if not, redirecting the resource request to the request receiver, including:

redirecting the resource request to the load balancing server;

after receiving the redirected resource request, the request receiver generates target response information and sends the target response information to the request initiator, and the method comprises the following steps:

after the request receiving party generates the target response information, the target response information is redirected to the load balancing service end, so that the load balancing service end transmits the target response information to the request initiating party.

8. A single sign-on apparatus applied to an electronic device, the electronic device being installed with a system to be accessed, comprising:

the determining module is used for determining whether an effective session identifier matched with the system to be accessed exists in the resource request when the resource request aiming at the system to be accessed is received; the resource request type is a homologous restriction type, and the homologous restriction type represents that a source site and a destination site of the request need to have the same protocol, domain name and port;

the redirection module is used for redirecting the resource request to a request receiver if the resource request does not exist;

the generation module is used for generating target response information after receiving the redirected resource request and sending the target response information to a request initiator;

9. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the single sign-on method of any one of claims 1 to 7 when executing the computer program.

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