CN110519240B

CN110519240B - Single sign-on method, device and system

Info

Publication number: CN110519240B
Application number: CN201910736510.8A
Authority: CN
Inventors: 韩卓亮; 徐方胜
Original assignee: Zhejiang Dasou Vehicle Software Technology Co Ltd
Current assignee: Zhejiang Dasou Vehicle Software Technology Co Ltd
Priority date: 2019-08-09
Filing date: 2019-08-09
Publication date: 2021-04-27
Anticipated expiration: 2039-08-09
Also published as: CN110519240A

Abstract

The application provides a single sign-on method, a single sign-on device and a single sign-on system, wherein the single sign-on method comprises the following steps: after receiving a service access request sent by the user terminal, the service system detects whether the service access request carries a packet; if not, returning a link pointing to the redirection page of the main SSO server to the user terminal; the main SSO server sends the user information submitted by the user through the redirection page to a sub SSO server corresponding to the service system; and the sub SSO server verifies the user information, generates a Ticket based on the user information after the user information passes the verification, acquires user access data corresponding to the user information, generates a first Token, and STOREs the generated Ticket and the first Token in association with the SSO-STORE corresponding to the service system. By using the scheme provided by the application, the user can track the user access data based on the Ticket after the user logs in at a single point.

Description

Single sign-on method, device and system

Technical Field

The present application relates to the field of computer communications, and in particular, to a single sign-on method, apparatus, and system.

Background

The Single sign-on (SSO) mechanism enables a user to access all applications in the same service system based on a Ticket (Ticket) after the user successfully obtains the Ticket (Ticket) through one-time login, and does not need to log in each application of the same service system, thereby providing great convenience for the user to access a plurality of applications in the same service system.

However, in the existing single sign-on implementation, there is no mechanism for managing the Ticket generated for the user, and the user access data cannot be tracked based on the Ticket.

Disclosure of Invention

In view of this, the present application provides a single sign-on method, apparatus, and system, which are used to track user access data based on Ticket after a user performs single sign-on.

Specifically, the method is realized through the following technical scheme:

according to a first aspect of the application, a single sign-on system is provided, the system comprises a main single sign-on SSO server, a plurality of sub SSO servers, a plurality of service systems and a plurality of single sign-on warehouse SSO-STOREs; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the service system is used for detecting whether a packet is carried in a service access request after the service access request sent by the user terminal is received; if not, returning a link pointing to the redirection page of the main SSO server to the user terminal;

the main SSO server is used for sending the user information submitted by the user through the redirection page to the sub SSO server corresponding to the service system;

and the sub SSO server is used for verifying the user information, generating a Ticket based on the user information after the user information passes the verification, acquiring user access data corresponding to the user information, generating a first Token, and storing the generated Ticket and the first Token in association with each other to the SSO-STORE corresponding to the service system.

Optionally, the sub SSO server is further configured to return the Ticket to the user terminal, so that the user terminal adds the Ticket to the service access request and sends the service access request to the service system.

Optionally, the service system is further configured to, when it is detected that the service access request carries a Ticket, search whether a first Token corresponding to the Ticket exists in an SSO-STORE corresponding to the service system; if yes, the resource accessed by the service access request is returned to the user terminal.

Optionally, the service system is further configured to return an invalid message for indicating that the first Token is invalid to the user terminal when the first Token corresponding to the Ticket is not found in the SSO-STORE corresponding to the service system;

after receiving the invalid message, the user terminal sends a Token updating request to the main SSO server; the Token updating request carries the socket, user information and the service system domain name;

the main SSO server forwards the Token updating request to a sub SSO server corresponding to the service system;

and the sub SSO server acquires the user access data currently corresponding to the user information, generates a second Token, and STOREs the second Token and the socket in association with the SSO-STORE corresponding to the service system.

Optionally, the main SSO server is further configured to, after receiving a logout request sent by the user terminal, determine an SSO-STORE corresponding to a domain name of a service system carried by the logout request, and delete a Ticket carried by the logout request and a Token associated with the Ticket from the found SSO-STORE.

Optionally, the user accessing data includes: user login behavior records and accessible resource lists.

According to a second aspect of the present application, a single sign-on method is provided, which is applied to any sub-SSO server in a single sign-on system; the single sign-on system further comprises: a plurality of SSO-STOREs, a plurality of service systems and a main SSO server; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the method comprises the following steps:

receiving user information sent by the main SSO server; the user information is submitted by a user through a redirection page; the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a packet;

after the user information passes the verification, generating a socket based on the user information;

acquiring user access data corresponding to the user information, and generating a first Token;

and storing the Ticket and the first Token association to an SSO-STORE corresponding to the service system.

Optionally, after generating a Ticket based on the user information, the method further includes:

and returning the Ticket to the user terminal so that the user terminal adds the Ticket to the service access request and sends the service access request to the service system.

Optionally, the generating a packet based on the user information includes:

acquiring a user identifier from the user information;

randomly generating a random number with a designated number of bits;

generating a Ticket based on the user identification and the random number.

Optionally, the user accessing data includes: user login behavior record and accessible resource list

The single sign-on system further comprises: the authority server and the user server correspond to the service system; the user server at least stores user login behavior records corresponding to user information; the authority server at least stores an accessible resource list corresponding to each user information;

the acquiring of the user access data corresponding to the user information includes:

acquiring a user login behavior record corresponding to the user information from the user server;

and acquiring an accessible resource list corresponding to the user information from the authority server.

Optionally, the storing the Ticket and the first Token association to an SSO-STORE corresponding to the domain name of the service system includes:

and storing the Ticket as a key and the first Token as a key value to the SSO-STORE.

Optionally, the method further includes:

receiving a Token updating request from a user terminal forwarded by the main SSO server; the Token updating request carries the socket, user information and the service system domain name;

acquiring user access data corresponding to the user information currently and generating a second Token;

and storing the second Token and the Ticket in association with the SSO-STORE corresponding to the service system domain name.

According to a third aspect of the present application, there is provided a single sign-on method, which is applied to a primary SSO server in a single sign-on system, and the single sign-on system further includes: the system comprises a plurality of sub SSO servers, a plurality of SSO-STOREs, a user terminal and at least one service system; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the method comprises the following steps:

acquiring user information submitted by a user through a redirection page; the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a packet;

determining a sub SSO server corresponding to the service system;

and forwarding the user information to the sub SSO server, so that the sub SSO server acquires user access data corresponding to the user information and generates a first Token after the user information passes verification, and STOREs the generated Ticket and the first Token in association with an SSO-STORE corresponding to the domain name of the service system.

Optionally, the method further includes:

receiving a Token update request sent by the user terminal; the Token updating request carries user information and the domain name of the service system; the Token updating request is sent by the user terminal after receiving an invalid message returned by the service system, or is sent by the user terminal after receiving a message for indicating that the user access data is updated;

and forwarding the Token updating request to the sub SSO server corresponding to the service system, so that the sub SSO server acquires user access data currently corresponding to the user information and generates a second Token, and storing the second Token and the Ticket in association to an SSO-STORE corresponding to the service system.

Optionally, the method further includes:

receiving a logout request sent by the user terminal; the logout request carries a socket and a domain name of a logout service system;

determining an SSO-STORE corresponding to the logged-out service system;

deleting the Ticket carried by the logout request and the associated Token in the searched SSO-STORE.

According to a fourth aspect of the present application, there is provided a single sign-on method, which is applied to any business system in a single sign-on system, and the single sign-on system further includes: the system comprises a plurality of sub SSO servers, a plurality of SSO-STOREs, a user terminal and a main SSO server; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the method comprises the following steps:

receiving a service access request sent by the user terminal;

detecting whether the service access request carries a packet;

if not, returning a link pointing to the redirection page of the main SSO server to the user terminal, so that the main SSO server is used for sending user information submitted by a user through the redirection page to a sub SSO server corresponding to the service system, the sub SSO server verifies the user information, after the verification is passed, generating a Ticket based on the user information, acquiring user access data corresponding to the user information and generating a first Token, and storing the generated Ticket and the first Token in association with the SSO-STORE corresponding to the service system.

Optionally, the method further includes:

if yes, searching whether a first Token corresponding to the Ticket exists in the SSO-STORE corresponding to the service system;

if yes, returning the resource accessed by the service access request to the user terminal;

if the Token does not exist, returning an invalid message for indicating that the first Token is invalid to the user terminal, so that the user terminal sends a Token updating request carrying the Ticket, the user information and the service system to the main SSO server, the main SSO server forwards the Token updating request to the sub SSO server, the sub SSO server obtains user access data currently corresponding to the user information and regenerates a second Token, and the second Token and the Ticket are stored in an SSO-STORE corresponding to the service system in an associated manner.

According to a fifth aspect of the present application, a single sign-on apparatus is provided, which is applied to any sub-SSO server in a single sign-on system; the single sign-on system further comprises: a plurality of SSO-STOREs, a plurality of service systems and a main SSO server; one or more sub-SSO servers and one or more SSO-STOREs are corresponding to each service system, and the apparatus includes:

a receiving unit, configured to receive user information sent by the master SSO server; the user information is submitted by a user through a redirection page; the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a packet;

the generating unit is used for generating a socket based on the user information after the user information passes the verification;

the acquisition unit is used for acquiring user access data corresponding to the user information and generating a first Token;

and the storage unit is used for storing the Ticket and the first Token association to the SSO-STORE corresponding to the service system.

Optionally, the apparatus further comprises:

and the returning unit is used for returning the Ticket to the user terminal so that the user terminal adds the Ticket to the service access request and sends the service access request to the service system.

Optionally, the generating unit is specifically configured to obtain a user identifier from the user information; randomly generating a random number with a designated number of bits; generating a Ticket based on the user identification and the random number.

Optionally, the user accessing data includes: recording user login behaviors and accessible resource lists;

the acquiring unit is specifically configured to acquire a user login behavior record corresponding to the user information from the user server; and acquiring an accessible resource list corresponding to the user information from the authority server.

Optionally, the storage unit is specifically configured to STORE the Ticket as a key and the first Token as a key value to the SSO-STORE.

Optionally, the receiving unit is further configured to receive a Token update request from a user terminal forwarded by the primary SSO server; the Token updating request carries the socket, user information and the service system domain name;

the acquiring unit is further configured to acquire user access data currently corresponding to the user information and generate a second Token;

the storage unit is further configured to STORE the second Token and the Ticket in association with the SSO-STORE corresponding to the service system domain name.

According to a sixth aspect of the present application, there is provided a single sign-on apparatus, which is applied to a main SSO server in a single sign-on system, the single sign-on system further comprising: the system comprises a plurality of sub SSO servers, a plurality of SSO-STOREs, a user terminal and at least one service system; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the device comprises:

the acquiring unit is used for acquiring user information submitted by a user through a redirection page; the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a packet;

a first determining unit, configured to determine a sub-SSO server corresponding to the service system;

and the first forwarding unit is used for forwarding the user information to the sub-SSO server, so that the sub-SSO server acquires user access data corresponding to the user information and generates a first Token after the user information is verified, and STOREs the generated Ticket and the first Token in association with the SSO-STORE corresponding to the domain name of the service system.

Optionally, the apparatus further comprises:

a first receiving unit, configured to receive a Token update request sent by the user terminal; the Token updating request carries user information and the domain name of the service system; the Token updating request is sent by the user terminal after receiving an invalid message returned by the service system, or is sent by the user terminal after receiving a message for indicating that the user access data is updated;

and the second forwarding unit is used for forwarding the Token updating request to the sub-SSO server corresponding to the service system, so that the sub-SSO server acquires user access data currently corresponding to the user information and generates a second Token, and STOREs the second Token and the Ticket in association with the SSO-STORE corresponding to the service system.

Optionally, the apparatus further comprises:

a second receiving unit, configured to receive a logout request sent by the user terminal; the logout request carries a socket and a domain name of a logout service system;

a second determining unit, configured to determine an SSO-STORE corresponding to the logged-out service system;

and the deleting unit is used for deleting the Ticket carried by the logout request and the associated Token in the searched SSO-STORE.

According to a seventh aspect of the present application, there is provided a single sign-on apparatus, which is applied to any business system in a single sign-on system, and the single sign-on system further includes: the system comprises a plurality of sub SSO servers, a plurality of SSO-STOREs, a user terminal and a main SSO server; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the device comprises:

a receiving unit, configured to receive a service access request sent by the user terminal;

the detection unit is used for detecting whether the service access request carries a packet or not;

and if not, returning a link pointing to the redirection page of the main SSO server to the user terminal, so that the main SSO server is used for sending the user information submitted by the user through the redirection page to a sub SSO server corresponding to the service system, the sub SSO server verifies the user information, after the verification is passed, generating a Ticket based on the user information, acquiring user access data corresponding to the user information and generating a first Token, and storing the generated Ticket and the first Token in association with the SSO-STORE corresponding to the service system.

Optionally, the apparatus further comprises:

the searching unit is used for searching whether a first Token corresponding to the Ticket exists in the SSO-STORE corresponding to the service system if the first Token corresponding to the Ticket exists; if yes, returning the resource accessed by the service access request to the user terminal; if the Token does not exist, returning an invalid message for indicating that the first Token is invalid to the user terminal, so that the user terminal sends a Token updating request carrying the Ticket, the user information and the service system to the main SSO server, the main SSO server forwards the Token updating request to the sub SSO server, the sub SSO server obtains user access data currently corresponding to the user information and regenerates a second Token, and the second Token and the Ticket are stored in an SSO-STORE corresponding to the service system in an associated manner.

As can be seen from the above description, after the user information is verified, the sub-SSO server STOREs the Ticket generated for the user and the Token containing the user access data of the user in association with each other in the SSO-STORE corresponding to each service system, so that not only can the Ticket of the user accessing each service system be managed, but also the user access data can be tracked based on the Ticket when the user is online.

Drawings

FIG. 1 is a schematic diagram of a single sign-on system according to an exemplary embodiment of the present application;

FIG. 2 is a flow chart of a single sign-on method shown in an exemplary embodiment of the present application;

FIG. 3 is a flow chart of another method of single sign-on shown in an exemplary embodiment of the present application;

FIG. 4 is a flow chart of another method of single sign-on shown in an exemplary embodiment of the present application;

FIG. 5 is a flow chart illustrating a method of single sign-on in accordance with an exemplary embodiment of the present application;

fig. 6 is a flowchart illustrating a Token update method according to an exemplary embodiment of the present application;

FIG. 7 is a flow chart illustrating a logout method according to an exemplary embodiment of the present application;

FIG. 8 is a block diagram of a seed SSO server according to an exemplary embodiment of the present application;

FIG. 9 is a block diagram of a single sign-on device shown in an exemplary embodiment of the present application;

FIG. 10 is a hardware block diagram of a primary SSO server according to an exemplary embodiment of the present application;

FIG. 11 is a block diagram of another single sign-on device shown in an exemplary embodiment of the present application;

FIG. 12 is a hardware block diagram of a business system shown in an exemplary embodiment of the present application;

fig. 13 is a block diagram of another single sign-on device according to an exemplary embodiment of the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

Referring to fig. 1, fig. 1 is a schematic diagram of a single sign-on system according to an exemplary embodiment of the present application.

The single sign-on system includes: the system comprises a user terminal, a main SSO server, a plurality of sub SSO servers, a plurality of service systems, a plurality of SSO-STOREs (single sign-on warehouses), a plurality of user servers and a plurality of authority servers.

1. Business system

The service system is a service system providing accessible resources for users. The domain names of different service systems are different, so that one service system can be identified by the domain name of the service system.

A plurality of accessible resources (also referred to as applications) may be included in a business system.

For example, a business system may be an ali business system, which may include a panning application, a tianmao application, a pay for treasure application, etc. Tanker applications, Temple applications, Payment applications, etc. are all referred to as accessible resources.

2. User terminal

The user terminal is used for communicating with a background (such as a main SSO server, a sub SSO server, a service system, an SSO-STORE and the like), transmitting user information, an access request and the like to the background, and receiving a packet returned by the background and the like.

The user terminal may be a mobile phone, a computer, etc., and the user terminal is only illustrated by way of example and is not particularly limited

3. SSO server

In a conventional single sign-on system, an SSO server is configured, and the SSO server processes all requests from a user terminal, such as an SSO server performing identity verification on a user, generating a Ticket, and the like. In addition, the SSO server is also used to manage and store user access data.

Wherein the user accessing the data may include: the user may access the resource list and the user login behavior record. The user login behavior record may include: login time, login times, login IP, etc.

Unlike the conventional SSO server in the single sign-on system, the present application designs a multi-stage SSO server to process the request of the user terminal. In addition, the application also designs a plurality of servers for storing the user access data.

1) Multi-stage SSO server

The single sign-on system is provided with a main SSO server and at least one sub SSO server. Each sub SSO server corresponds to different service systems.

The main SSO server forwards the request to the corresponding sub SSO server according to the domain name of the service system carried in the request (such as login request, Token update request and the like) sent by the user terminal.

The child SSO server can process the request. For example, if the request is a first access request, the sub-SSO server may verify user information carried in the request, generate a Ticket for the user after the user information passes the verification, and generate a Token for the user based on the user behavior access data of the user, associate the Ticket with the Token, and the like.

The Ticket is an authentication credential allocated to a user, and the Ticket may be generated based on user information of the user. The Token may be generated by the user access data described above.

In the application, the main SSO server distributes the requests aiming at different service systems to different sub SSO servers, and the sub SSO servers process the requests of the service systems corresponding to the sub SSO servers, so that load sharing is realized, and the request processing efficiency is improved.

2) Multiple servers for storing user access data

The SSO server of the conventional single sign-on system performs data storage and management (e.g., storing and managing user access data, etc.) in addition to the request processing operation.

In the present application, however, data storage and management is stripped from the traditional SSO server. For example, the single sign-on system is also provided with a user server and an authority server. Each service system corresponds to a respective user server and an authority server.

The user server is used for storing and managing user login behavior records and the like. The entitlement server is used to store and manage user accessible resource lists and the like.

On one hand, the data storage and management are stripped from the sub SSO server, so that the sub SSO server only performs request processing, and the processing performance of the sub SSO server is greatly improved.

On the other hand, the data storage and management are separated from the sub SSO server, and even if the working state of the sub SSO server is abnormal, the data storage and management are not influenced.

In the third aspect, the user login behavior data and the user accessible resource list are separately stored, so that the coupling between the user and the authority can be reduced to a certain extent, and the user and the authority can be combined according to different service scenes.

4、SSO-STORE

The existing single sign-on mechanism does not manage the Ticket, and when a user is online, the user access data cannot be tracked based on the Ticket.

In the embodiment of the present application, the single sign-on system of the present application is further configured with the SSO-STORE corresponding to each service system separately.

The SSO-STORE is a management system for managing Ticket. For example, the SSO-STORE STOREs therein a Ticket allocated to the user and a Token corresponding to the Ticket. In addition, the SSO-STORE also STOREs relevant information related to the Ticket, such as the generation time of the Ticket, the effective duration of the Ticket, and the like.

And storing the Ticket of the user accessing each service system and the Token containing the user access data of the user in association with each other in the SSO-STORE corresponding to each service system, so that the management of the Ticket of the user accessing each service system is realized, and the user access data can be tracked based on the Ticket when the user is online.

In addition, each SSO-STORE can be built based on multiple layers of Redis (a high-performance key-value database). The manner of construction of the SSO-STORE is not specifically limited herein.

In addition, it should be further noted that, in the embodiment of the present application, the sub-SSO server, the SSO-STORE, the user server, and the authority server are classified according to different service systems, so that the sub-SSO server, the SSO-STORE, the user server, and the authority server corresponding to the same service system jointly serve the service system.

For example, as shown in table 1.

Business system	Sub SSO server	SSO-STORE	Authority server	User server
					Business system 1	Child SSO Server 1	SSO-STORE1	Authority server 1	User server 1
Business system 2	Child SSO Server 2	SSO-STORE2	Authority server 2	User server 2

TABLE 1

As shown in table 1, it is assumed that the single sign-on system includes two service systems, namely, a service system 1 and a service system 2. Com is the domain name of the service system 1, and is souche-inc.com is the domain name of the service system 2, and the domain name of the service system 1 corresponds to the sub-SSO server 1, the SSO-STORE1, the user server 1 and the authority server 1.

The domain name of the service system 2 corresponds to the sub SSO server 2, SSO-STORE2, the user server 2, and the authority server 2.

Of course, in the present application, one service system may also correspond to a plurality of sub SSO servers, a plurality of SSO-STOREs, a plurality of user servers, and a plurality of rights servers, which are not specifically limited herein.

Referring to fig. 2, fig. 2 is a flowchart illustrating a single sign-on method according to an exemplary embodiment of the present application, which can be applied to a sub SSO server of the single sign-on system shown in fig. 1, and can include the following steps.

Step 201: the sub SSO server receives the user information sent by the main SSO server; the user information is submitted by a user through a redirection page; and the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a packet.

When a user needs to access a service system in the single sign-on system shown in fig. 1, the user terminal may send a service access request of the user to the service system through the domain name. The business system domain name may uniquely identify a business system.

After receiving the service access request, the service system can check whether the service access request carries a packet.

1) And the service access request does not carry a Ticket scene.

If the service access request does not carry a packet, it indicates that the user terminal accesses the service system for the first time. At this point, steps 202 through 205 may be performed.

Specifically, if the service access request does not carry a Ticket, the service system returns a redirection page link pointing to the main SSO server to the user terminal.

And the user terminal acquires the redirection page based on the redirection page link.

The user terminal may present the redirection page. The user may enter user information on the redirection page. The user information may include: user name, password, etc. The user information is not particularly limited herein.

The user terminal can obtain user information input by a user, a login request is constructed based on the user information and the domain name of the service system, the user information is redirected to the main SSO server through the login request, and the main SSO server can also send the user information to the sub SSO server corresponding to the domain name of the service system based on the login request.

Specifically, the user terminal sends a login request to the master SSO server. The login request carries user information and the domain name of the service system.

After receiving the login request, the main SSO server determines a sub SSO server corresponding to the domain name of the service system, and sends the login request to the sub SSO server.

The child SSO server can receive the login request sent by the master SSO server.

Step 202: the child SSO server can verify the received user information.

If the verification is passed, executing step 203 to step 206;

and if the verification fails, returning prompt information that the identity verification fails to pass to the user terminal.

Step 203: and the sub SSO server generates a Ticket based on the user information.

In implementation, the sub SSO server can obtain the user identifier, such as UUID _ a, from the user information. The user identification may uniquely identify a user.

The child SSO server can also generate a random number, such as UUID _ B, of a specified number of bits.

And then, the sub SSO server generates a socket based on the acquired user identification and the generated random number. For example, the child SSO server can compile UUID _ a and UUID _ B into Ticket according to specified rules.

Step 204: and the sub SSO server acquires user access data corresponding to the user information and generates a first Token.

Wherein the user accessing data comprises: user login behavior records and accessible resource lists. The user login behavior record may include: login time, login times, login device IP address, etc.

When the method is implemented, the sub-SSO server can acquire the user login behavior record corresponding to the user information from the user server corresponding to the service system domain name.

The sub SSO server can obtain the accessible resource list corresponding to the user information from the authority server corresponding to the service system domain name.

The child SSO server can generate a first Token based on the acquired user login behavior record and the accessible resource list.

In this embodiment, after the sub-SSO server generates the first Token, the sub-SSO server may further return the first Token to the user terminal. The user terminal may store the first Token and display the user access data carried in the first Token.

Step 205: and the sub SSO server can STORE the Ticket and the first Token association to an SSO-STORE corresponding to the service system domain name.

In this embodiment of the present application, the sub-SSO server may associate the storage packet with the first Token in a Key-Value manner.

During implementation, the sub-SSO server can use Ticket as Key, and STORE the first Token as Value in the SSO-STORE corresponding to the domain name of the service system.

Because the SSO-STORE STOREs the corresponding relation between the Ticket and the Token, when a manager or other systems except the single sign-on system are on line, the manager or other systems can find the corresponding Token according to the Ticket, and further obtain the user access data carried in the Token, so that the user access data can be tracked.

Of course, in practical applications, other information may also be stored in the SSO-STORE, such as a corresponding relationship between the user identifier and the Ticket, a corresponding relationship between the user identifier and the key information, and the like.

The key information may be specific information in the user access data, for example, the key information may include: ticekt, AppName (application name, also referred to as user accessible resource name), ASI (standard information of application) parameter, storage period, and the like.

In addition, in this embodiment of the present application, after generating a Ticket, the sub-SSO server returns the Ticket to the user terminal, so that the user terminal adds the Ticket to the service access request and sends the service access request to the service system.

In implementation, the sub SSO server may return a Ticket to the user terminal.

The user terminal can write the Ticket into the cookie of the service access request and resend the service access request to the service system.

2) Scene with Ticket carried in service request

In this embodiment of the application, when the user goes offline, the master SSO server may delete a Ticket and its associated Token in the SSO-STORE, but the Ticket is still cached in the browser of the user terminal. When the user terminal goes offline and logs in again in a short time, a service request sent by the user terminal carries a Ticket, but the corresponding SSO-STORE does not have a Token corresponding to the Ticket.

Therefore, when the service system detects that the service access request carries a Ticket and the SSO-STORE corresponding to the domain name of the service system does not have the first Token corresponding to the Ticket, the service system may return an invalid message for indicating that the first Token is invalid to the user terminal.

When the user terminal receives the above-mentioned invalidation message indicating that the first Token is invalid, the user terminal may send a Token update request to the primary SSO server. The Token update request carries user information, the domain name of the service system, and a packet corresponding to the user terminal.

After receiving the Token update request, the main SSO server may determine a sub-SSO server corresponding to the service system domain name carried in the Token update request, and then send the Token update request to the sub-SSO server.

And after receiving the Token updating request, the sub SSO server acquires user access data currently corresponding to the user information carried by the Token updating request and regenerates a second Token. The manner of obtaining the user access data currently corresponding to the user and regenerating the second Token is shown in step 204, and is not described here again.

In addition, the sub-SSO server can STORE the second Token and the Ticket in association with the SSO-STORE corresponding to the service system domain name carried by the Token update request.

The child SSO server may also return a second Token to the user terminal. And after receiving the second Token, the user terminal can update the first Token of the local record by using the second Token and display the second Token.

In addition, in the embodiment of the present application, when the user terminal successfully logs in the service system, the user login behavior record in the user server may be updated. Of course, the user login behavior record in the user server and the accessible resource list in the authority server can also be manually updated.

When the user login behavior record stored by the user server is updated or the accessible resource list stored by the authority server is updated, the user server or the authority server can inform the master SSO server, and the master SSO server can send a message for indicating that the user access data is updated to the user terminal. The message for indicating that the user access data is updated carries the service system domain name.

When the user terminal receives a message indicating that the user access data is updated, the user terminal may transmit a Token update request to the master SSO server. The Token update request carries user information, the domain name of the service system, and a packet corresponding to the user terminal.

In addition, the application also provides a login quitting mode of the user terminal.

When the user terminal logs out, it is necessary to delete a Ticket corresponding to the user terminal and its Token in the SSO-STORE, delete a Ticket corresponding to the user terminal and its corresponding user identifier, and delete key information including a Ticket corresponding to the user terminal and its corresponding user identifier.

In implementation, when a user logs out of the business system, the user terminal may send a logout request to the master SSO server. The logout request carries a Ticket and a logout service system domain name.

The main SSO server can determine the SSO-STORE corresponding to the logout service system domain name, and then delete the Ticket carried by the logout request and the Token associated with the Ticket in the determined SSO-STORE.

Referring to fig. 3, fig. 3 is a flowchart illustrating a single sign-on method according to an exemplary embodiment of the present application, which may be applied to a primary SSO server in the single sign-on system shown in fig. 1, and may include the following steps.

Step 301: and the main SSO server acquires the user information submitted by the user through the redirection page. And the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a packet.

The login request carries user information and a service system domain name of a service system accessed by the user.

Specifically, when a user needs to access a service system in the single sign-on system shown in fig. 1, the user terminal may send a service access request of the user to the service system.

If the service access request does not carry a packet, it indicates that the user terminal accesses the service system for the first time. At this time, the service system returns a redirection page link to the user terminal.

The user terminal may present the redirection page. The user may enter user information on the redirection page. The user information may include: user name, password, etc.

The user terminal can obtain user information input by a user and send a login request to the main SSO server. The login request carries user information and the domain name of the service system.

Step 302: and the main SSO server determines a sub SSO server corresponding to the service system.

When the login request is carried out, the main SSO server stores the corresponding relation between the service system domain name and the sub SSO server identification, and the main SSO server can search the sub SSO server identification corresponding to the service system domain name carried by the login request in the corresponding relation.

Wherein, the sub-SSO server identifier may include: the IP address, device ID, etc. of the sub SSO server are only exemplary and not particularly limited.

Step 303: the main SSO server can forward the login request to the sub SSO server so that the sub SSO server can verify the user information, and after the user information passes the verification, a socket is generated based on the user information and returned to the user terminal so that the user terminal can add the socket to the service access request and send the socket to the service system; and enabling the sub SSO server to acquire user access data corresponding to the user information, generate a first Token, and STORE the generated Ticket and the first Token in association with the SSO-STORE corresponding to the service system.

When implemented, the master SSO server can forward the login request to the child SSO server.

And after the sub SSO server receives the login request, the sub SSO server can verify the user information, and after the user information passes the verification, a packet is generated based on the user information and is returned to the user terminal.

And the user terminal adds the Ticket into the service access request and sends the service access request to the service system.

In addition, after the sub-SSO server passes the verification, the sub-SSO server obtains the user access data corresponding to the user information, generates a first Token, and STOREs the generated Ticket and the first Token in association with the SSO-STORE corresponding to the service system.

In addition, in the embodiment of the present application, the master SSO server receives a Token update request sent by the user terminal; the Token updating request carries user information, the service system domain name and a packet corresponding to the user terminal; the Token update request is sent by the user terminal after receiving an invalid message returned by the service system, or sent by the user terminal after receiving a message for indicating that the user access data is updated.

The main SSO server can forward the Token updating request to the sub SSO server corresponding to the service system, so that the sub SSO server obtains the user access data currently corresponding to the user information and regenerates a second Token, and STOREs the second Token and the Ticket in association with each other to the SSO-STORE corresponding to the service system, and returns the second Token to the user terminal, so that the user terminal displays the second Token.

In an embodiment of the present application, when a user logs out of a service system, the user terminal may send a logout request to the master SSO server. The logout request carries a Ticket and a logout service system domain name.

Referring to fig. 4, fig. 4 is a flowchart illustrating another single sign-on method according to an exemplary embodiment of the present application, which can be applied to a business system in the single sign-on system shown in fig. 1, and can include the following steps.

Step 401: and the service system receives a service access request sent by the user terminal.

When a user needs to access a service system in the single sign-on system shown in fig. 1, the user terminal may send a service access request of the user to the service system.

Step 402: and the service system detects whether the service access request carries a packet.

During implementation, the service system may detect whether a cookie or a specific parameter of the service access request carries a packet.

Step 403: if the service access request does not carry a Ticket, returning a redirection page link to the user terminal, redirecting user information input by a user to the main SSO server through the redirection page link by the user terminal, forwarding the user information to a sub SSO server corresponding to the service system by the main SSO server, generating a Ticket based on the user information and returning the Ticket to the user terminal after the user information is verified by the sub SSO server, so that the user terminal adds the Ticket to the service access request and sends the Ticket to the service system, acquiring user access data corresponding to the user information by the sub SSO server and generating a first Token, and storing the generated Ticket and the first Token in association with an SSO-RE corresponding to the service system.

When the service system is realized, if the service access request does not carry a packet, it indicates that the user terminal accesses the service system for the first time. At this time, the service system returns a redirection page link to the user terminal.

And the user terminal acquires the user information input by the user on the redirection page and sends a login request carrying the user information and the domain name of the service system to the main SSO server.

And the main SSO server forwards the login request to a sub SSO server corresponding to the service system domain name.

And the sub SSO server verifies the user information, and generates a packet based on the user information and returns the packet to the user terminal after the user information passes the verification. The sub SSO server can also acquire user access data corresponding to the user information, generate a first Token, and STORE the generated Ticket and the first Token in association with the SSO-STORE corresponding to the service system domain name.

In this embodiment of the application, if the service access request carries a Ticket, the service system may search whether there is a first Token corresponding to the Ticket in the SSO-STORE corresponding to the domain name of the service system.

And if the first Token corresponding to the Ticket exists in the SSO-STORE, determining that the user terminal successfully logs in the service system, and returning the resource requested by the service access request to the user terminal.

If the SSO-STORE does not have the first Token corresponding to the Ticket, an invalid message for indicating that the first Token is invalid is returned to the user terminal, so that the user terminal sends a Token updating request carrying the Ticket, user information and the service system domain name to the main SSO server, the main SSO server forwards the Token updating request to the sub SSO server, the sub SSO server obtains a user login behavior record and an accessible resource list corresponding to the user information at present and regenerates a second Token, the second Token and the Ticket are stored in association to the SSO-STORE corresponding to the service system domain name, and the second Token is returned to the user terminal so that the user terminal can display the second Token.

Wherein, the service system is configured with an SSO client, and the SSO client is stored in the service system in a plug-in form. The operations performed by the service system for single sign-on may all be performed by the SSO client, for example, the SSO client of the service system performs the above steps 401 to 403. Of course, a code program may also be separately configured in the business system, and the single sign-on operation is executed by the code program, which is only exemplary and not specifically limited herein.

As can be seen from the above description, on one hand, after the user information is verified, the child SSO server STOREs the Ticket generated for the user and the Token containing the user access data of the user in association with each other in the SSO-STORE corresponding to each service system, so that not only is the management of the Ticket of the user accessing each service system realized, but also the user access data can be tracked based on the Ticket when the user is online.

On the other hand, the main server distributes the requests (such as login requests and Token update requests) aiming at different service systems to different sub-SSO servers, and the sub-servers process the requests of the service systems corresponding to the sub-servers, so that load sharing is realized, and the request processing efficiency is improved.

In the third aspect, the storage and management of the user access data are separated from the sub SSO server, so that the sub SSO server only performs request processing, and the processing performance of the sub SSO server is greatly improved. In addition, the storage and management of the user access data are separated from the sub SSO server, and even if the working state of the sub SSO server is abnormal, the storage and management of the user access data are not influenced.

Referring to fig. 5, fig. 5 is a flowchart illustrating a single sign-on method according to an exemplary embodiment of the present application.

The single sign-on method can be applied to the single sign-on system shown in fig. 1, and the method can include the following steps.

Step 501: in response to a user's trigger operation for the service system 1, the user terminal sends a service access request 1 to the service system 1.

When a user inputs a URL link of an application in the service system 1 at the user terminal or clicks an application in the service system 1, the user terminal may detect a trigger operation of the user with respect to the service system 1.

The user terminal may obtain the service system domain name of the service system 1 accessed by the user based on the URL link of the application, and send the service access request 1 carrying the service system 1 domain name to the service system 1.

Step 502: an SSO client of a service system 1 intercepts a service access request 1 and detects whether the service access request 1 carries a packet 1;

if the service access request 1 does not carry packet 1, executing step 503 to step 518;

if the service access request 1 carries a packet 1, steps 519 to 530 are executed.

Step 503: if the service access request 1 does not carry packet 1, the SSO client of the service system 1 returns a link for redirecting pages to the user terminal.

The redirection page link is used for instructing the user terminal to acquire the redirection page based on the redirection page link.

Step 504: and the user terminal acquires the redirection page based on the redirection page link and acquires the user information input by the user on the redirection page.

The redirection page is used to instruct the user to enter user information on the redirection page.

Wherein the user information includes: a username and password, etc. Here, the user information is merely exemplary and is not particularly limited.

Step 505: the user terminal sends a login request to the main SSO server; the login request carries the user information and the domain name of the service system 1.

The user terminal may construct a login request based on the user information and the domain name of the service system 1 to be accessed, and send the login request to the primary SSO server.

Step 506: and the main SSO server determines a sub SSO server 1 corresponding to the domain name of the service system 1.

When the method is implemented, the main SSO server stores a corresponding relationship between the service system domain name and the sub-SSO server identifier, and the main SSO server can search the sub-SSO server identifier (i.e. the identifier of the sub-SSO server 1) corresponding to the service system domain name carried by the login request in the corresponding relationship.

Step 507: the master SSO server forwards the login request to the child SSO server 1.

The master SSO server forwards the login request to the child SSO server 1 indicated by the child SSO server identifier determined in step 506.

Step 508: and the sub SSO server 1 checks the identity information carried in the login request.

If the verification fails, go to step 509;

if the verification is passed, step 510 to step 518 are performed.

Step 509: if the verification fails, the sub-SSO server 1 returns a prompt message to the user terminal.

The prompt message is used for indicating that the user information of the user terminal is not verified.

Step 510: if the verification is passed, the sub SSO server generates a Ticket1 based on the user information carried in the login request.

Then, the sub SSO server generates Ticket1 based on the obtained user identifier and the generated random number. For example, the child SSO server can compile UUID _ a and UUID _ B into Ticket1 according to specified rules.

Step 511: the sub-SSO server 1 sends an acquisition request to the authority server 1 corresponding to the service system domain name.

The acquisition request carries the user information.

Step 512: the sub SSO server 1 receives the accessible resource list corresponding to the user information returned by the authority server 1.

After receiving the acquisition request, the authorization server 1 may search an accessible resource list corresponding to the user information, and return the accessible resource list to the sub-SSO server 1.

Step 513: the sub SSO server 1 sends an acquisition request to the user server 1 corresponding to the service system domain name.

The acquisition request carries user information.

Step 514: the sub SSO server 1 receives the user login behavior record corresponding to the user information returned by the user server 1.

After receiving the obtaining request, the user server 1 may search a user login behavior record corresponding to the user information, and return the user login behavior record to the sub-SSO server 1.

Step 515: the child SSO server 1 generates Token1 based on the acquired user login behavior record and accessible resource list.

In implementation, the child SSO server 1 can perform operations such as logging on a user and splicing an accessible resource list to generate Token 1.

Step 516: the sub SSO server 1 can STORE the Ticket1 and the Token1 in association with the SSO-STORE1 corresponding to the service system domain name.

During implementation, the child SSO server can use Ticket1 as a Key, and STORE Token1 as Value to the SSO-STORE corresponding to the service system domain name.

517: the child SSO server 1 returns the generated Ticket1 to the user terminal.

The Ticket1 is used to instruct the terminal to add the Ticket1 to the service access request, and to resend the service access request to the service system 1.

Step 518: the child SSO server 1 returns Token1 to the user terminal.

The user terminal may present Token1 so that the user can view the user login behavior record and the accessible resource list in Token 1.

Step 519: if the service access request carries Ticket1, detecting whether there is Token1 corresponding to the Ticket1 in the SSO-STORE1 corresponding to the service system domain name.

If Token1 corresponding to the Ticket1 exists in the SSO-STORE1, execute step 520;

if Token1 corresponding to the Ticket1 does not exist in the SSO-STORE1, steps 521 to 530 are performed.

Step 520: if Token1 corresponding to the Ticket exists in the SSO-STORE corresponding to the domain name of the service system, the SSO client of the service system 1 returns the resource accessed by the service access request to the user terminal.

If Token1 corresponding to the Ticket exists in the SSO-STORE corresponding to the domain name of the service system, it indicates that the user terminal successfully logs in the service system 1. The SSO client of the service system 1 returns the resource accessed by the service access request to the user terminal.

Step 521: if Token1 corresponding to the Ticket1 does not exist in the SSO-STORE1, an invalid message is returned to the user terminal.

The invalidation message is used to indicate that Token1 corresponding to Token1 is invalid.

Step 522: and the user terminal sends a Token updating message to the main SSO server.

The Token update request carries the Ticket1, user information and the service system 1 domain name;

step 523: and the main SSO server forwards the Token updating request to a sub SSO server 1 corresponding to the domain name of the service system 1.

The master SSO server can look up the child SSO server 1 corresponding to the domain name of the service system 1, and then the master SSO server can forward the Token update request to the child SSO server 1.

Step 524: the sub SSO server 1 sends an acquisition request to the user server 1 corresponding to the service system domain name.

The acquisition request carries user information.

Step 525: the sub-SSO server 1 receives the user login behavior record corresponding to the user information currently returned by the user server 1.

Step 526: the sub SSO server 1 sends an acquisition request to the authority server 1 corresponding to the domain name of the service system 1.

The acquisition request carries user information.

Step 527: the sub SSO server 1 receives the accessible resource list corresponding to the user information returned by the authority server 1.

Step 528: the child SSO server 1 generates Token2 based on the acquired user login behavior record and accessible resource list.

In implementation, the child SSO server 1 can perform operations such as logging on a user and splicing an accessible resource list to generate Token 2.

Step 529: the sub-SSO server can STORE the Ticket1 and the Token2 association to the SSO-STORE1 corresponding to the service system domain name.

During implementation, the child SSO server can use Ticket1 as a Key, and STORE Token2 as Value to the SSO-STORE corresponding to the service system domain name.

Step 530: the child SSO server 1 returns Token2 to the user terminal.

The user terminal may present Token2 so that the user can view the user login behavior record and the accessible resource list in Token 2.

In addition, the present application further provides a Token updating method, and referring to fig. 6, fig. 6 is a flowchart of a Token updating method shown in an exemplary embodiment of the present application.

Still taking the example shown in fig. 5 as an example, assuming that the user accessible resource list stored by the authority server 1 is updated, or the user login behavior record stored by the user server 1 is updated, the authority server or the user server may notify the master SSO server that the user access data has been updated. After the user access data is updated, steps 601 through 610 may be performed.

Step 601: the master SSO server sends a message to the user terminal indicating that the user access data is updated.

The updated message carries the user information corresponding to the updated user access data and the domain name of the service system 1.

Step 602: and the user terminal sends a Token updating request to the main SSO server.

The Token request carries a packet corresponding to the user terminal, user information, and a domain name of the service system 1.

Step 603: and the main SSO server forwards the Token updating request to a sub SSO server 1 corresponding to the service system 1 domain name carried by the Token updating request.

Step 604: the sub SSO server 1 sends an acquisition request to the user server 1 corresponding to the domain name of the service system 1.

The acquisition request carries user information.

Step 605: the sub-SSO server 1 receives the user login behavior record corresponding to the user information currently returned by the user server 1.

Step 606: the sub SSO server 1 sends an acquisition request to the authority server 1 corresponding to the domain name of the service system 1.

The acquisition request carries user information.

Step 607: the sub SSO server 1 receives the accessible resource list corresponding to the user information returned by the authority server 1.

Step 608: the child SSO server 1 generates Token3 based on the acquired user login behavior record and accessible resource list.

In implementation, the child SSO server 1 can perform operations such as logging on a user and splicing an accessible resource list to generate Token 3.

Step 609: the sub SSO server 1 can STORE the Ticket1 and the Token3 association to the SSO-STORE1 corresponding to the domain name of the service system 1.

During implementation, the child SSO server can use Ticket1 as a Key, and STORE Token3 as Value to the SSO-STORE corresponding to the service system domain name.

Step 610: the child SSO server 1 returns Token3 to the user terminal.

The user terminal may present Token3 so that the user can view the user login behavior record and the accessible resource list in Token 2.

In addition, the present application also provides a logout method, and referring to fig. 7, fig. 7 is a flowchart of a logout method shown in the present application, which may include the following steps.

Assuming that the user logs out of the service system 1, steps 701 to 704 may be performed when the user logs out of the service system 1.

Step 701: the user terminal sends a logout request to the main SSO server in response to a logout operation triggered by the user.

The logout request carries Ticket1 and a logout domain name of the service system 1.

Step 702: the master SSO server determines the SSO-STORE1 corresponding to the logged out business system 1 domain name.

The main SSO server also pre-configures a corresponding relationship between each service system domain name and each SSO-STORE identifier, and the main SSO server can search for the SSO-STORE identifier corresponding to the service system 1 domain name in the corresponding relationship, and the SSO-STORE indicated by the found SSO-STORE identifier is the SSO-STORE 1.

Step 703: the master SSO server sends a delete instruction to SSO-STORE 1.

The deleting instruction carries Ticket 1;

step 704: SSO-STORE1 deletes the Ticket1 and the Token1 corresponding to Ticket1 stored locally.

The SSO-STORE1 can respond to the delete command to delete the Ticket1 and Token1 corresponding to the Ticket1 stored locally.

Referring to fig. 8, fig. 8 is a hardware structure diagram of a seed SSO server according to an exemplary embodiment of the present application.

The sub SSO server includes: a communication interface 801, a processor 802, a machine-readable storage medium 803, and a bus 804; wherein the communication interface 801, the processor 802, and the machine-readable storage medium 803 communicate with each other via the bus 404. The processor 802 may perform the single sign-on method described above by reading and executing machine-executable instructions in the machine-readable storage medium 803 corresponding to the single sign-on control logic.

The machine-readable storage medium 803 referred to herein may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like. For example, the machine-readable storage medium may be: volatile memory, non-volatile memory, or similar storage media. In particular, the machine-readable storage medium 803 may be a RAM (random Access Memory), a flash Memory, a storage drive (e.g., a hard drive), a solid state drive, any type of storage disk (e.g., a compact disk, a DVD, etc.), or similar storage medium, or a combination thereof.

Referring to fig. 9, fig. 9 is a block diagram of a single sign-on apparatus according to an exemplary embodiment of the present application. The single sign-on apparatus can be applied to the sub SSO server shown in fig. 8, and the single sign-on system further includes: a plurality of SSO-STOREs, a plurality of service systems and a main SSO server; one or more sub-SSO servers and one or more SSO-STOREs are corresponding to each service system, and the apparatus includes:

a receiving unit 901, configured to receive user information sent by the master SSO server; the user information is submitted by a user through a redirection page; the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a packet;

a generating unit 902, configured to generate a Ticket based on the user information after the user information passes verification;

an obtaining unit 903, configured to obtain user access data corresponding to the user information, and generate a first Token;

a storage unit 904, configured to STORE the Ticket and the first Token association to an SSO-STORE corresponding to the service system.

Optionally, the apparatus further comprises:

a returning unit 905, configured to return the Ticket to the user terminal, so that the user terminal adds the Ticket to the service access request and sends the service access request to the service system.

Optionally, the generating unit 902 is specifically configured to obtain a user identifier from the user information; randomly generating a random number with a designated number of bits; generating a Ticket based on the user identification and the random number.

the obtaining unit 903 is specifically configured to obtain a user login behavior record corresponding to the user information from the user server; and acquiring an accessible resource list corresponding to the user information from the authority server.

Optionally, the storage unit 904 is specifically configured to STORE the Ticket as a key and the first Token as a key value to the SSO-STORE.

Optionally, the receiving unit 901 is further configured to receive a Token update request from a user terminal forwarded by the primary SSO server; the Token updating request carries the socket, user information and the service system domain name;

the acquiring unit 903 is further configured to acquire user access data corresponding to the user information currently and generate a second Token;

the storage unit 904 is further configured to STORE the second Token and the Ticket in association with the SSO-STORE corresponding to the service system domain name.

Referring to fig. 10, fig. 10 is a hardware structure diagram of a main SSO server according to an exemplary embodiment of the present application.

The master SSO server includes: a communication interface 1001, a processor 1002, a machine-readable storage medium 1003, and a bus 1004; the communication interface 1001, the processor 1002 and the machine-readable storage medium 1003 communicate with each other via the bus 1004. The processor 1002 may perform the single sign-on method described above by reading and executing machine executable instructions in the machine readable storage medium 1003 corresponding to the single sign-on control logic.

The machine-readable storage medium 1003 referred to herein may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like. For example, the machine-readable storage medium may be: volatile memory, non-volatile memory, or similar storage media. In particular, the machine-readable storage medium 1003 may be a RAM (random Access Memory), a flash Memory, a storage drive (e.g., a hard disk drive), a solid state disk, any type of storage disk (e.g., a compact disk, a DVD, etc.), or similar storage medium, or a combination thereof.

Referring to fig. 11, fig. 11 is a block diagram of another single sign-on apparatus according to an exemplary embodiment of the present application. The single sign-on system further comprises: the system comprises a plurality of sub SSO servers, a plurality of SSO-STOREs, a user terminal and at least one service system; one or more sub-SSO servers and one or more SSO-STOREs are associated with each business system.

The device comprises:

an obtaining unit 1101, configured to obtain user information submitted by a user through a redirection page; the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a packet;

a first determining unit 1102, configured to determine a sub-SSO server corresponding to the service system;

the first forwarding unit 1103 is configured to forward the user information to the sub-SSO server, so that the sub-SSO server obtains user access data corresponding to the user information and generates a first Token after the user information is checked, and STOREs the generated Ticket and the first Token in association with the SSO-STORE corresponding to the domain name of the service system.

Optionally, the apparatus further comprises:

a first receiving unit 1104, configured to receive a Token update request sent by the user terminal; the Token updating request carries user information and the domain name of the service system; the Token updating request is sent by the user terminal after receiving an invalid message returned by the service system, or is sent by the user terminal after receiving a message for indicating that the user access data is updated;

a second forwarding unit 1105, configured to forward the Token update request to the sub-SSO server corresponding to the service system, so that the sub-SSO server obtains the user access data currently corresponding to the user information and generates a second Token, and STORE the second Token and the Ticket in association with the SSO-STORE corresponding to the service system.

Optionally, the apparatus further comprises:

a second receiving unit 1106, configured to receive a logout request sent by the user terminal; the logout request carries a socket and a domain name of a logout service system;

a second determining unit 1107, configured to determine an SSO-STORE corresponding to the logged-out service system;

a deleting unit 1108, configured to delete the Ticket and the Token associated therewith carried by the logout request in the found SSO-STORE.

Referring to fig. 12, fig. 12 is a hardware structure diagram of a service system according to an exemplary embodiment of the present application.

The service system includes: a communication interface 1201, a processor 1202, a machine-readable storage medium 1203, and a bus 1204; the communication interface 1201, the processor 1202, and the machine-readable storage medium 1203 are in communication with each other via a bus 1204. The processor 1202 may perform the single sign-on method described above by reading and executing machine-executable instructions in the machine-readable storage medium 1203 corresponding to the single sign-on control logic.

The machine-readable storage medium 1203 referred to herein may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like. For example, the machine-readable storage medium may be: volatile memory, non-volatile memory, or similar storage media. In particular, the machine-readable storage medium 1203 may be a RAM (random Access Memory), a flash Memory, a storage drive (e.g., a hard disk drive), a solid state disk, any type of storage disk (e.g., a compact disk, a DVD, etc.), or similar storage medium, or a combination thereof.

Referring to fig. 13, fig. 13 is a block diagram of another single sign-on apparatus according to an exemplary embodiment of the present application. The apparatus can be applied to the business system shown in fig. 12. The single sign-on system further comprises: the system comprises a plurality of sub SSO servers, a plurality of SSO-STOREs, a user terminal and a main SSO server; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the device comprises:

a receiving unit 1301, configured to receive a service access request sent by the user terminal;

a detecting unit 1302, configured to detect whether the service access request carries a packet;

and a returning unit 1303, configured to, if not, return a link pointing to a redirection page of the main SSO server to the user terminal, so that the main SSO server is configured to send user information submitted by the user through the redirection page to a sub-SSO server corresponding to the service system, the sub-SSO server verifies the user information, and after the verification passes, generate a Ticket based on the user information, acquire user access data corresponding to the user information and generate a first Token, and STORE the generated Ticket and the first Token in association with the SSO-re corresponding to the service system.

Optionally, the apparatus further comprises:

a searching unit 1304, configured to search, if yes, whether a first Token corresponding to the Ticket exists in the SSO-STORE corresponding to the service system; if yes, returning the resource accessed by the service access request to the user terminal; if the Token does not exist, returning an invalid message for indicating that the first Token is invalid to the user terminal, so that the user terminal sends a Token updating request carrying the Ticket, the user information and the service system to the main SSO server, the main SSO server forwards the Token updating request to the sub SSO server, the sub SSO server obtains user access data currently corresponding to the user information and regenerates a second Token, and the second Token and the Ticket are stored in an SSO-STORE corresponding to the service system in an associated manner.

The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A single sign-on system is characterized in that the system comprises a main single sign-on SSO server, a plurality of sub SSO servers, a plurality of service systems and a plurality of single sign-on warehouse SSO-STOREs; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the service system is used for detecting whether a Ticket is carried in a service access request after the service access request sent by a user terminal is received; if not, returning a link pointing to the redirection page of the main SSO server to the user terminal;

and the sub SSO server is used for verifying the user information, generating a socket based on the user information after the user information passes the verification, acquiring user access data corresponding to the user information, generating a first Token based on the acquired user access data, and storing the generated socket and the first Token into the SSO-STORE corresponding to the service system in an associated manner.

2. The system of claim 1,

and the sub SSO server is also used for returning the Ticket to the user terminal so that the user terminal adds the Ticket to the service access request and sends the service access request to the service system.

3. The system of claim 1,

the service system is further configured to, when it is detected that the service access request carries a Ticket, search whether a first Token corresponding to the Ticket exists in an SSO-STORE corresponding to the service system; if yes, the resource accessed by the service access request is returned to the user terminal.

4. The system of claim 3,

the service system is further configured to return an invalid message for indicating that the first Token is invalid to the user terminal when the first Token corresponding to the Ticket is not found in the SSO-STORE corresponding to the service system;

5. The system of claim 1,

and the main SSO server is also used for determining the SSO-STORE corresponding to the domain name of the service system carried by the logout request after receiving the logout request sent by the user terminal, and deleting the Ticket carried by the logout request and the associated Token in the searched SSO-STORE.

6. The system of any of claims 1 to 5, wherein said user accessing data comprises: user login behavior records and accessible resource lists.

7. A single sign-on method is characterized in that the method is applied to any sub SSO server in a single sign-on system; the single sign-on system further comprises: the system comprises a plurality of single sign-on warehouses SSO-STOREs, a plurality of service systems and a main SSO server; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the method comprises the following steps:

receiving user information sent by the main SSO server; the user information is submitted by a user through a redirection page; the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a Ticket;

acquiring user access data corresponding to the user information, and generating a first Token based on the acquired user access data;

8. The method of claim 7, wherein after the generating a Ticket based on the user information, the method further comprises:

9. The method of claim 7, wherein generating the Ticket based on the user information comprises:

acquiring a user identifier from the user information;

randomly generating a random number with a designated number of bits;

generating a Ticket based on the user identification and the random number.

10. The method of claim 7, wherein the user accessing data comprises: recording user login behaviors and accessible resource lists;

11. The method of claim 7, wherein storing the Ticket and the first Token association to an SSO-STORE corresponding to a domain name of the business system comprises:

12. The method of claim 7, further comprising:

and storing the second Token and the Ticket association to the SSO-STORE corresponding to the service system.

13. A single sign-on method is applied to a main SSO server in a single sign-on system, and the single sign-on system further comprises: the system comprises a plurality of sub SSO servers, a plurality of single sign-on warehouses SSO-STORE, a user terminal and at least one service system; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the method comprises the following steps:

acquiring user information submitted by a user through a redirection page; the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a Ticket;

determining a sub SSO server corresponding to the service system;

and forwarding the user information to the sub SSO server, so that the sub SSO server acquires user access data corresponding to the user information after the user information is verified, generates a first Token based on the acquired user access data, and STOREs the generated Ticket and the first Token in association with the SSO-STORE corresponding to the service system.

14. The method of claim 13, further comprising:

15. The method of claim 13, further comprising:

determining an SSO-STORE corresponding to the logged-out service system;

16. A single sign-on method is applied to any business system in a single sign-on system, and the single sign-on system further comprises: the system comprises a plurality of sub SSO servers, a plurality of single sign-on warehouses SSO-STORE, a user terminal and a main SSO server; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the method comprises the following steps:

receiving a service access request sent by the user terminal;

detecting whether the service access request carries a Ticket or not;

if not, returning a link pointing to the redirection page of the main SSO server to the user terminal, sending user information submitted by the user through the redirection page to a sub SSO server corresponding to the service system by the main SSO server, verifying the user information by the sub SSO server, generating a socket based on the user information after the verification is passed, acquiring user access data corresponding to the user information, generating a first Token based on the acquired user access data, and storing the generated socket and the first Token in association with the SSO-RE corresponding to the service system.

17. The method of claim 16, further comprising:

18. A single sign-on device is characterized in that the device is applied to any sub SSO server in a single sign-on system; the single sign-on system further comprises: the system comprises a plurality of single sign-on warehouses SSO-STOREs, a plurality of service systems and a main SSO server; one or more sub-SSO servers and one or more SSO-STOREs are corresponding to each service system, and the apparatus includes:

a receiving unit, configured to receive user information sent by the master SSO server; the user information is submitted by a user through a redirection page; the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a Ticket;

the acquisition unit is used for acquiring user access data corresponding to the user information and generating a first Token based on the acquired user access data;

19. The apparatus of claim 18, further comprising:

20. The apparatus according to claim 18, wherein the generating unit is specifically configured to obtain a user identifier from the user information; randomly generating a random number with a designated number of bits; generating a Ticket based on the user identification and the random number.

21. The apparatus of claim 18, wherein the user access data comprises: recording user login behaviors and accessible resource lists;

22. The apparatus according to claim 18, wherein the storage unit is specifically configured to STORE the Ticket as a key and the first Token as a key value to the SSO-STORE.

23. The apparatus of claim 18,

the receiving unit is further configured to receive a Token update request from the user terminal forwarded by the primary SSO server; the Token updating request carries the socket, user information and the service system domain name;

24. A single sign-on apparatus, applied to a primary SSO server in a single sign-on system, the single sign-on system further comprising: the system comprises a plurality of sub SSO servers, a plurality of single sign-on warehouses SSO-STORE, a user terminal and at least one service system; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the device comprises:

the acquiring unit is used for acquiring user information submitted by a user through a redirection page; the link of the redirection page is sent by the service system when detecting that the service access request sent by the user terminal does not carry a Ticket;

and the first forwarding unit is used for forwarding the user information to the sub-SSO server, so that the sub-SSO server acquires user access data corresponding to the user information after the user information is verified, generates a first Token based on the acquired user access data, and STOREs the generated Ticket and the first Token in association with the SSO-STORE corresponding to the domain name of the service system.

25. The apparatus of claim 24, further comprising:

26. The apparatus of claim 24, further comprising:

27. A single sign-on device, applied to any business system in a single sign-on system, the single sign-on system further comprising: the system comprises a plurality of sub SSO servers, a plurality of single sign-on warehouses SSO-STORE, a user terminal and a main SSO server; each service system corresponds to one or more sub SSO servers and one or more SSO-STOREs;

the device comprises:

the detection unit is used for detecting whether the service access request carries a Ticket;

and if not, returning a link pointing to a redirection page of the main SSO server to the user terminal, so that the main SSO server sends user information submitted by the user through the redirection page to a sub SSO server corresponding to the service system, the sub SSO server verifies the user information, generates a socket based on the user information after the verification is passed, acquires user access data corresponding to the user information, generates a first Token based on the acquired user access data, and STOREs the generated socket and the first Token in association with the SSO-STORE corresponding to the service system.

28. The apparatus of claim 27, further comprising: