WO2014048749A1

WO2014048749A1 - Inter-domain single sign-on

Info

Publication number: WO2014048749A1
Application number: PCT/EP2013/068819
Authority: WO
Inventors: Yan Liu; Kang Liu; Chen Huang
Original assignee: Siemens Aktiengesellschaft
Priority date: 2012-09-29
Filing date: 2013-09-11
Publication date: 2014-04-03
Also published as: CN103716292A

Abstract

Disclosed in the present invention is an inter-domain SSO method and device. The method comprises: an SSO initiator of a first domain sending SSO authentication information of a user, who has passed authentication by the first domain, to an SSO center of a second domain; the SSO initiator receiving inter- domain SSO authentication information of the user from the SSO center of the second domain once the SSO authentication information has passed authentication, wherein the inter-domain SSO authentication information includes signature information of the SSO center of the second domain; and the SSO initiator sending the inter-domain SSO authentication information to an SSO receiver of the second domain. Adopting the solution of the present invention enables inter-domain SSO to be achieved. The solution is easy to deploy with no need to make excessive changes to existing systems.

Description

Inter-domain Single Sign-On method and device

Technical field

The present invention relates to a method and device for Single Sign-on, in particular to an inter-domain Single Sign-on method and device.

Background art

At present, following the development of application systems and information technology, users in large enterprises often need to switch from one application system to another. The user is required to input a username and password to log in to each application system. This requirement to input a username and password when logging in to each application system results in very low working efficiency; moreover, the need to remember several passwords leads to many users using the same password, thereby lowering the security of the application systems.

The emergence of the Single Sign-on (SSO) mechanism has solved the above problem very effectively. The SSO mechanism enables a user to access all application systems which trust each other in a plurality of application systems by simply logging in once. It is currently one of the more popular solutions for business integration in enterprises.

At the present time, several solutions for SSO mechanisms have already been proposed. These solutions can broadly be divided into two main types: password synchronization schemes and ticket schemes.

In password synchronization schemes, an SSO processing module stores one master password for a user, and multiple corresponding secondary passwords for multiple application systems, in a database in advance. When the user inputs the master password, it is first translated by the SSO processing module into a secondary password for a specific application system, this secondary password then being used to complete a corresponding authentication process. Thus a user can access multiple application systems by inputting one master password.

In ticket schemes, when a user logs in for the first time, e.g. to access an application system 1, an SSO authentication server checks the user's identity on the basis of log-in information provided by the user; if the user's identity passes the check, the SSO authentication server returns a ticket to the user. When the user logs in for the second time, e.g. to access an application system 2, this ticket will be carried in the log-in request as evidence of user authentication; after receiving the log-in request, application system 2 will send the ticket to the SSO authentication server for checking, so as to check the ticket's legitimacy. If the check is passed, the user can access application system 2 without inputting a username and password again.

However, large enterprises and agencies generally include organizational structures at multiple levels, each organizational structure having its own independent application system and trusted authentication center. For example, a large enterprise will generally have a head office organizational structure, province- level organizational structures, and even city-level organizational structures, these organizational structures being in different authentication domains, i.e. each organizational structure having its own trusted authentication center. If a user who has already logged in to a province- level organizational structure wishes to obtain data from a study system in the head office organizational structure, the user can only do so after inputting the username and password for the head office organizational structure to log in to the same. Thus there is still a need in the prior art for a scheme which supports inter-domain SSO.

Content of the invention

In view of the above, an object of the present invention is to provide an SSO scheme to be used for inter-domain SSO.

Another object of the present invention is to provide an easily-deployed inter-domain SSO mechanism without making excessive changes to an existing system.

According to one aspect of the embodiments of the present invention, a Single Sign-on (SSO) method is provided, comprising : an SSO initiator of a first domain sending SSO authentication information of a user, who has passed authentication by the first domain, to an SSO center of a second domain; the SSO initiator receiving inter-domain SSO authentication information of the user from the SSO center of the second domain once the SSO authentication information has passed authentication, wherein the inter-domain SSO authentication information includes signature information of the SSO center of the second domain; the SSO initiator sending the inter-domain SSO authentication information to an SSO receiver of the second domain.

In the embodiments of the present invention, since SSO authentication information of a user can be authenticated and signed by the SSO center of the second domain, and the SSO center in the second domain is trusted by the SSO receiver in the second domain, the user's identity can be authenticated by the SSO receiver in the second domain, thereby achieving inter- domain SSO, meeting the requirements of large enterprises and organizational structures with multiple levels, and improving working efficiency. Furthermore, the embodiments of the present invention are easy to deploy, and can stimulate the development of popularized commercial systems while improving user experience .

Preferably, before the SSO initiator sends the inter-domain SSO authentication information to the SSO receiver of the second domain, the method further comprises: the SSO initiator encrypting the inter-domain SSO authentication information.

Since the inter-domain SSO authentication information transmitted is encrypted in the embodiments of the present invention, security during transmission of inter-domain SSO authentication information is improved, and the security of SSO is further improved at the same time.

Preferably, before the SSO initiator sends the SSO authentication information of the user, who has passed authentication by the first domain, to the SSO center of the second domain, the method further comprises: the SSO initiator applying to an SSO center in the first domain for the SSO authentication information, wherein the SSO authentication information includes an authentication level of the user.

Since an authentication level is added in the embodiments of the present invention, a user is only allowed to access an application system if the authentication level of the user is higher than the authentication level of the application system, so that the performance of the system as a whole is perfected. For example, certain special systems (such as financial systems) can only be accessed by specified users, so a higher authentication level can be set for such systems to prevent access by users with a lower authentication level.

Preferably, when the SSO initiator receives the inter-domain SSO authentication information of the user from the SSO center of the second domain, the SSO initiator also receives a session identifier of the user from the SSO center of the second domain; and when sending the inter-domain SSO authentication information to the SSO receiver of the second domain, the SSO initiator also sends the session identifier to the SSO receiver of the second domain.

Since a session identifier is added in the embodiments of the present invention, a user is only allowed to access an application system once the session identifier received has passed authentication. This can prevent replay attacks, and hence improves the security of inter-domain SSO, providing the user with a more secure network environment and improving user experience .

Preferably, before the SSO initiator sends the session identifier to the SSO receiver of the second domain, the method further comprises: the SSO initiator encrypting the session identifier.

Since the session identifier transmitted is encrypted in the embodiments of the present invention, security during transmission of the session identifier is improved, and the security of SSO is further improved at the same time.

According to another aspect of the embodiments of the present invention, an SSO device is provided, the device comprising: a sending module, for sending SSO authentication information of a user, who has passed authentication by a first domain, to an SSO center of a second domain; a receiving module, for receiving, by the SSO initiator, inter- domain SSO authentication information of the user from the SSO center of the second domain once the SSO authentication information has passed authentication, wherein the inter-domain SSO authentication information includes signature information of the SSO center of the second domain; a processing module, for sending the inter-domain SSO authentication information to the SSO receiver of the second domain .

Description of the accompanying drawings

The above characteristics, technical features and advantages of the present invention as well as embodiments thereof are illustrated further below in a clear and easily understandably way by describing preferred embodiments with reference to the accompanying drawings, wherein:

Fig. 1A is a flow chart of the SSO method in the embodiments of the present invention;

Fig. IB is a flow chart of a first method for performing inter- domain SSO in the embodiments of the present invention;

Fig. 2 is a flow chart of a second method for performing inter- domain SSO in the embodiments of the present invention;

Fig. 3 is a flow chart of a third method for performing inter- domain SSO in the embodiments of the present invention;

Fig. 4 is a schematic diagram of an application environment in the embodiments of the present invention; Fig. 5A is a flow chart of a fourth method for performing inter-domain SSO in the embodiments of the present invention;

Fig. 5B is a schematic diagram of the structure of SSO authentication information in the embodiments of the present invention .

Fig. 5C is a schematic diagram of SSO in the embodiments of the present invention;

Fig. 6 is a schematic diagram of the structure of the SSO device in the embodiments of the present invention.

Particular embodiments

As Fig. 1A shows, the SSO method in the embodiments of the present invention comprises the following steps: an SSO initiator of a first domain sending SSO authentication information of a user, who has passed authentication by the first domain, to an SSO center of a second domain; the SSO initiator receiving inter-domain SSO authentication information of the user from the SSO center of the second domain once the SSO authentication information has passed authentication, wherein the inter-domain SSO authentication information includes signature information of the SSO center of the second domain; the SSO initiator sending the inter-domain SSO authentication information to an SSO receiver of the second domain.

In the embodiments of the present invention, the SSO initiator sends the inter-domain SSO authentication information to the SSO receiver of the second domain in order to make the SSO receiver of the second domain allow the user access if the inter-domain SSO authentication information passes authentication .

Here, the signature information of the SSO center of the second domain included in the inter-domain SSO authentication information may be authenticated by the SSO receiver of the second domain, or the SSO center of the second domain may authenticate the signature information of the SSO center of the second domain included in the inter-domain SSO authentication information and report the result to the SSO receiver of the second domain.

To improve security of transmission, the SSO initiator of the first domain may encrypt the inter-domain SSO authentication information, and then send the encrypted inter-domain SSO authentication information to the SSO receiver of the second domain. The SSO receiver of the second domain then decrypts the encrypted inter-domain SSO authentication information to obtain inter-domain SSO authentication information.

The SSO authentication information of a user who has passed authentication by the first domain may include the authentication level of the user. Correspondingly, the SSO initiator may send inter-domain SSO authentication information including the user's authentication level to the SSO receiver of the second domain, for the purpose of instructing the SSO receiver of the second domain to authenticate the user's authentication level, and allow the user access once authentication is passed.

Preferably, when the SSO initiator receives the inter-domain SSO authentication information of a user from the SSO center of the second domain, the SSO initiator also receives a session identifier of the user from the SSO center of the second domain; when sending the inter-domain SSO authentication information to the SSO receiver of the second domain, the SSO initiator also sends the session identifier to the SSO receiver of the second domain. Since an attacker cannot find out the session identifier, he will not be able to access the SSO receiver even if he steals the SSO authentication information, and so replay attacks by attackers can be prevented, increasing the security of the network.

Similarly, the SSO initiator may also encrypt the session identifier; the SSO receiver of the second domain decrypts the encrypted session identifier correspondingly.

In the embodiments of the present invention, the SSO initiator of the first domain may be a user terminal, for instance a browser or some other client with SSO functionality; it may also be an application system with SSO functionality, such as a portal device. A user may accomplish SSO in more than one way. For instance, the user may log in to an application system A successfully by inputting a username and password, thereby completing one log- in operation. The user then clicks on a hyperlink provided on the page of application system A to request access to an application system B. At this point, application system A which sends the request for access is referred to as the SSO initiator, while application system B which receives the request for access is referred to as the SSO receiver. Optionally, the user may also perform authentication with an SSO center directly via his user terminal with SSO functionality (i.e. complete one log-in operation); if authentication is successful, his terminal directly requests access to various application systems. In this case, the user terminal which sends out a request for access is referred to as the SSO initiator, while the various application systems which receive the request for access are referred to as SSO receivers. Furthermore, any application system which has already successfully authenticated a user's identity can serve as an SSO initiator and request access to another application system, i.e. an SSO receiver. The embodiments of the present invention are illustrated below by way of an example in which the SSO initiator of the first domain is a portal device. In this example, the client may be a browser of the user. The embodiment in which the SSO initiator of the first domain is a user terminal has the same technical principles as the following example, which could be adapted by those skilled in the art.

As shown in Fig. IB, a first method for performing inter-domain SSO in the embodiments of the present invention comprises the following steps: step 101: a user sends log-in request information to a portal device in a first domain via his client; step 102: after receiving the log-in request information from the client, and once the user's identity has been verified, the portal device in the first domain requests SSO authentication information for the user (SSO ticket) from an SSO center in the first domain; step 103: the SSO center in the first domain returns the SSO authentication information for the user to the portal device of the first domain; step 104: the user sends a request to access an application system of a second domain to the portal device in the first domain via his client; step 105: the portal device in the first domain sends the SSO authentication information for the user to an SSO center in the second domain; step 106: the SSO center in the second domain authenticates the SSO authentication information, and if authentication is passed, places signature information of the second domain in the SSO authentication information; step 107: the SSO center in the second domain returns the SSO authentication information containing the signature information of the second domain to the portal device in the first domain; step 108: the portal device in the first domain sends the SSO authentication information containing the signature information of the second domain to the application system in the second domain; step 109: the application system in the second domain authenticates the signature information of the second domain in the SSO authentication information received; step 110: the application system in the second domain allows the user access to the application system if the signature information of the second domain in the SSO authentication information passes authentication.

In step 102, when requesting SSO authentication information for the user from the SSO center in the first domain, the portal device in the first domain can send a user identifier to the SSO center of the first domain; correspondingly, in step 103, the SSO center of the first domain can place an authentication level of the user to whom the user identifier corresponds in the SSO authentication information for the user.

Thus in step 108, the portal device of the first domain can send the SSO authentication information including the user's identification level to the application system in the second domain .

The portal device in the first domain can determine whether the SSO receiver is in the first domain or the second domain according to the access request sent by the client in step 104. The access request sent by the client may include a URL address to which access is requested, the identifier of an application system to be accessed, or other information by which the SSO receiver may be determined. If the client requests access to a URL address, the portal device in the first domain can determine whether the URL address is in the same authentication domain as itself on the basis of the URL address; if the request sent by the client includes the identifier of the application system to be accessed, the portal device in the first domain can determine which authentication domain the application system to be accessed belongs to on the basis of a correspondence relationship between application system identifiers and authentication domains.

In step 105, the portal device in the first domain may also send the identifier of the application system which the user needs to access (APP ID) to the SSO center in the second domain, to allow the SSO center in the second domain to determine the application system to be accessed.

In step 106, when authenticating the SSO authentication information received, the SSO center in the second domain may authenticate signature information of the first domain in the SSO authentication information, and once authentication is passed, if the SSO authentication information contains the time of creation of the SSO authentication information and the time of expiry of the SSO authentication information, the SSO center in the second domain may also authenticate the time of creation of the SSO authentication information and the time of expiry of the SSO authentication information, to check whether the SSO authentication information is still valid.

Apart from signature information, the SSO authentication information may as required also comprise other information by which the legitimacy of the user SSO authentication information can be verified; the SSO center in the second domain may then also verify the SSO authentication information on the basis of that information. To further increase the security of inter-domain SSO, the SSO additionally includes a session ID. Fig. 2 shows a second method for performing inter-domain SSO in the embodiments of the present invention, wherein steps 201 to 205 are the same as steps 101 to 105 in Fig. 1 and are not repeated superfluously here. Only the differences are set out here: step 206: the SSO center in the second domain authenticates the SSO authentication information received, and if authentication is passed, places signature information of the second domain in the SSO authentication information and allocates a session identifier (session) ID to the user; step 207: the SSO center in the second domain returns the session ID and the SSO authentication information containing the signature information of the second domain to the portal device in the first domain; step 208: the portal device in the first domain returns the session ID and the SSO authentication information containing the signature information of the second domain to the client; step 209: the client sends the session ID and inter-domain SSO authentication information received to the application system in the second domain; step 210: the application system in the second domain sends the session ID and inter-domain SSO authentication information to the SSO center in the second domain; step 211: the SSO center in the second domain authenticates the session ID and inter-domain SSO authentication information, and returns an authentication result in step 212; step 213: the application system in the second domain allows the user to access the application system if authentication is passed . In this embodiment, the portal device of the first domain can send the inter-domain SSO information for the user to the application system in the second domain via the client using URL redirection and HTTP POST in steps 208 and 209 according to actual requirements.

The session ID may be a randomly generated figure or timestamp, or some other information capable of uniquely identifying a session. Since an attacker cannot find out the session ID, he will not be able to access the application system, so the security of the network environment is improved.

The session ID need not be transmitted together with the SSO authentication information; all that is necessary is to ensure that the application system is able to receive the session ID before step 210.

To improve the security of the session ID during transmission, preferably, in step 208, the portal device in the first domain encrypts the session ID and returns the encrypted session ID to the client; correspondingly, in step 209, the client sends the encrypted session ID to the application system in the second domain; and in step 210, the application system in the second domain decrypts the encrypted session ID received.

Fig. 3 is a third method for performing inter-domain SSO in the embodiments of the present invention, wherein all steps except steps 303 and 309 are the same as the corresponding steps in Fig. 1, and are not repeated superfluously here. Only the differences are set out here: step 303: the SSO center in the first domain returns SSO authentication information including a user authentication level to the portal device in the first domain; step 309: the application system in the second domain allows the user to access the application system if the signature information of the second domain in the SSO authentication information passes authentication and the user's authentication level is in compliance with the authentication level of the application system.

Authentication levels may be divided into multiple levels as required. For example, an authentication level of "0" indicates: static password authentication; an authentication level of "1" indicates: single-use password authentication; and an authentication level of "2" indicates: certificate authentication. Of course, more authentication levels may be included according to specific requirements. In step 303, the SSO center in the first domain determines a suitable authentication level on the basis of the user's authentication method. For instance, if the user logs in successfully using a single-use password, the user's authentication level is determined to be "1" .

Different application systems may have different authentication levels. If the authentication level required by an application system is "single-use password authentication", a user who has passed "static password authentication" cannot access the application system, but a user who has passed "single-use password authentication" or "certificate authentication" can access the application system.

The embodiments of the present invention are illustrated below taking the application environment shown in Fig. 4 as an example .

As Fig. 5A shows, the specific steps of the fourth method for performing inter-domain SSO in the embodiments of the present invention comprise the following, wherein Fig. 5B may be referred to for information regarding the structure of the SSO authentication information: step 501: the client sends log-in request information to a provincial portal device; step 502: the provincial portal device requests SSO authentication information for the user from a provincial SSO center; step 503: the provincial SSO center returns SSO authentication information including a user authentication level to the provincial portal device; step 504: the client sends information requesting access to the head office application system to the provincial portal device; step 505: the provincial portal device sends the SSO authentication information of the user to a head office SSO center, and applies for a session ID; step 506: the head office SSO center authenticates the SSO authentication information received, and once authentication is passed, places head office signature information in the SSO authentication information; step 507: the head office SSO center allocates a session ID to the user; step 508: the head office SSO center returns the session ID and the SSO authentication information containing the head office signature information to the provincial portal device; step 509: the provincial portal device upgrades the SSO authentication information, updating the SSO authentication information of the user to SSO authentication information containing the head office signature; step 510: the provincial portal device encrypts the session ID; step 511: the provincial portal device returns the encrypted session ID and SSO authentication information to the client; step 512: the client sends the encrypted session ID and SSO authentication information to the head office application system; step 513: the head office application system decrypts the session ID received; step 514: the head office application system authenticates the head office signature information in the SSO authentication information received; step 515: the head office application system sends the session ID to the head office SSO center once the head office signature information passes authentication; step 516: the head office SSO center authenticates the session ID; step 517: the head office SSO center returns the authentication result ; step 518: after determining that the session ID has passed authentication on the basis of the authentication result, the head office application system compares the authentication level of the user with the authentication level of the application system; step 519: the head office application system allows the user to access the application system if the authentication level of the user is in compliance with the authentication level of the application system. The embodiments of the present invention are illustrated below taking the application environment shown in Fig. 5C as an example .

1. A user accesses a provincial portal website, and passes authentication .

2. The provincial portal website carries out SSO for the user via a provincial SSO center;

3. The user logs in by SSO to an ERP (enterprise resource planning) system.

4. The user wishes to log in by SSO to a study system located in the head office; the provincial portal website applies via a head office SSO center for a session ID and SSO authentication information containing head office signature information.

5. The user can log in by SSO to the head office study system on the basis of the session ID and the SSO authentication information containing head office signature information.

Based on the same inventive concept, the embodiments of the present invention also provide an SSO device corresponding to the SSO method. Since the principles by which the device solves problems are similar to those of the SSO method, the examples of the method of the present invention may be referred to for information regarding the embodiments of the device; characteristics common to both the method and the device will not be repeated here superfluously.

As Fig. 6 shows, the SSO device in the embodiments of the present invention comprises: a sending module 61, a receiving module 62 and a processing module 63. The sending module 61 is used for sending SSO authentication information of a user, who has passed authentication by a first domain, to an SSO center of a second domain.

The receiving module 62 is used for receiving, by the SSO initiator, inter-domain SSO authentication information of the user from the SSO center of the second domain once the SSO authentication information has passed authentication, wherein the inter-domain SSO authentication information includes signature information of the SSO center of the second domain.

The processing module 63 is used for sending the inter-domain SSO authentication information to the SSO receiver of the second domain.

Preferably, the device further comprises: a first encrypting module 64 : for encrypting the inter-domain SSO authentication information before the processing module 63 sends the inter- domain SSO authentication information to the SSO receiver of the second domain.

Preferably, the sending module 61 is further used for: applying to an SSO center in the first domain for the SSO authentication information before sending the SSO authentication information of the user who has passed authentication by the first domain to the SSO center of the second domain, wherein the SSO authentication information includes an authentication level of the user.

Preferably, the receiving module 62 is further used for: receiving a session ID of the user from the SSO center of the second domain when receiving the inter-domain SSO authentication information of the user from the SSO center of the second domain; and the processing module 63 is further used for sending the session ID to the SSO receiver of the second domain when sending the inter-domain SSO authentication information to the SSO receiver of the second domain. Preferably, the device further comprises: a second encrypting module 65: for encrypting the session ID before the processing module 63 sends the session ID to the SSO receiver of the second domain.

It must be explained that not all of the steps and modules in the above procedures and structural diagrams of systems are necessary; some steps or modules may be omitted according to actual requirements. The order in which the steps are performed is not fixed, but may be adjusted as required. The system structures described in the above examples may be physical structures or logic structures, i.e. some modules may be realized as the same physical entity, or as multiple physical entities separately, or as certain components in multiple independent devices jointly.

In the above examples, the hardware units may be realized mechanically or electrically. For example, a hardware unit may comprise a permanent dedicated circuit or logic (such as a special processor, FPGA or ASIC) to complete corresponding operations. Hardware units may also comprise programmable logic or circuits (such as universal processors or other programmable processors) , which can be set up temporarily by software to complete corresponding operations. The specific form of realization (mechanical, dedicated permanent circuit or circuit set up temporarily) may be determined on the basis of cost and time considerations.

The present invention also provides a machine-readable medium which stores commands for making a machine execute the SSO method described in this text. Specifically, a system or apparatus equipped with a storage medium may be provided, wherein software program code realizing the functions of any one of the above examples is stored on the storage medium, and a computer (or CPU or MPU) of the system or apparatus reads and executes the program code stored on the storage medium. In this case, the program code read from the storage medium is itself capable of realizing the functions of any one of the above examples, hence the program code and the storage medium on which the program code is stored form part of the present invention .

Examples of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (eg. CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW) , magnetic tape, non-volatile memory cards and ROM. Optionally, a communication network may download program code from a server computer .

In addition, it should be clear that not only can part or all of an actual operation be completed by executing program code read out by a computer, but an operating system operating on a computer can also be made to complete part or all of the actual operation by means of commands based on the program code, so as to realize the function of any one of the above examples.

In addition, it can be appreciated that program code read out from the storage medium is written into a memory installed in an expansion board inserted in the computer, or written into a memory installed in an expansion unit connected to the computer, and thereafter commands based on the program code make a CPU etc. installed on the expansion board or expansion unit execute part or all of an actual operation, so as to realize the function of any one of the above embodiments.

The present invention is presented and explained in detail above by way of accompanying drawings and preferred embodiments, but is not limited to these disclosed embodiments. Other solutions derived therefrom by those skilled in the art shall also be included in the scope of protection of the present invention.

Claims

1. A Single Sign-on (SSO) method, comprising:

an SSO initiator of a first domain sending SSO authentication information of a user, who has passed authentication by the first domain, to an SSO center of a second domain;

the SSO initiator receiving inter-domain SSO authentication information of the user from the SSO center of the second domain once the SSO authentication information has passed authentication, wherein the inter-domain SSO authentication information includes signature information of the SSO center of the second domain;

the SSO initiator sending the inter-domain SSO authentication information to an SSO receiver of the second domain .

2. The method as claimed in claim 1, characterized in that before the SSO initiator sends the inter-domain SSO authentication information to the SSO receiver of the second domain, the method further comprises:

the SSO initiator encrypting the inter-domain SSO authentication information.

3. The method as claimed in claim 1, characterized in that before the SSO initiator sends the SSO authentication information of the user, who has passed authentication by the first domain, to the SSO center of the second domain, the method further comprises:

the SSO initiator applying to an SSO center in the first domain for the SSO authentication information, wherein the SSO authentication information includes an authentication level of the user.

4. The method as claimed in claim 1, characterized in that when the SSO initiator receives the inter-domain SSO authentication information of the user from the SSO center of the second domain, the SSO initiator also receives a session identifier of the user from the SSO center of the second domain; and

when sending the inter-domain SSO authentication information to the SSO receiver of the second domain, the SSO initiator also sends the session identifier to the SSO receiver of the second domain.

5. The method as claimed in claim 4, characterized in that before the SSO initiator sends the session identifier to the SSO receiver of the second domain, the method further comprises :

the SSO initiator encrypting the session identifier.

6. The method as claimed in any one of claims 1 to 5, characterized in that the SSO authentication information is an SSO ticket.

7. An SSO device, comprising:

a sending module, for sending SSO authentication information of a user, who has passed authentication by a first domain, to an SSO center of a second domain;

a receiving module, for receiving, by the SSO initiator, inter-domain SSO authentication information of the user from the SSO center of the second domain once the SSO authentication information has passed authentication, wherein the inter-domain SSO authentication information includes signature information of the SSO center of the second domain;

a processing module, for sending the inter-domain SSO authentication information to the SSO receiver of the second domain .

8. The device as claimed in claim 7, characterized by further comprising :

a first encrypting module, for encrypting the inter-domain SSO authentication information before the processing module sends the inter-domain SSO authentication information to the SSO receiver of the second domain.

9. The device as claimed in claim 7, characterized in that the sending module is further used for:

applying to an SSO center in the first domain for the SSO authentication information before sending the SSO authentication information of the user who has passed authentication by the first domain to the SSO center of the second domain, wherein the SSO authentication information includes an authentication level of the user.

10. The device as claimed in claim 7, characterized in that the receiving module is further used for:

receiving a session identifier of the user from the SSO center of the second domain when receiving the inter-domain SSO authentication information of the user from the SSO center of the second domain; and

the processing module is further used for sending the session identifier to the SSO receiver of the second domain when sending the inter-domain SSO authentication information to the SSO receiver of the second domain.

11. The device as claimed in claim 10, characterized by further comprising :

a second encrypting module, for encrypting the session identifier before the processing module sends the session identifier to the SSO receiver of the second domain.