WO2014048769A1 - Single sign-on method, proxy server and system - Google Patents

Single sign-on method, proxy server and system Download PDF

Info

Publication number
WO2014048769A1
WO2014048769A1 PCT/EP2013/068986 EP2013068986W WO2014048769A1 WO 2014048769 A1 WO2014048769 A1 WO 2014048769A1 EP 2013068986 W EP2013068986 W EP 2013068986W WO 2014048769 A1 WO2014048769 A1 WO 2014048769A1
Authority
WO
WIPO (PCT)
Prior art keywords
application system
user
client
authentication
data packet
Prior art date
Application number
PCT/EP2013/068986
Other languages
French (fr)
Inventor
Yan Liu
Kang Liu
Chen Huang
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2014048769A1 publication Critical patent/WO2014048769A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity

Definitions

  • the present invention relates to the field of communications, in particular to a Single Sign-on method, proxy server and system.
  • SSO Single Sign-on
  • SSO methods can be broadly divided into two main types: ticket- based approaches and credential vault approaches.
  • Ticket -based approaches are more secure. They use the Kerberos protocol, which is founded on a password system of symmetric keys, and enables secure communication between different users in an insecure network system. However, ticket -based approaches generally necessitate alteration of the SSO application system to support authentication and decryption of tickets.
  • Credential vault approaches store user credentials (generally including a user' s usernames and passwords for different systems) safely; for example, storage may be effected by encrypting a database.
  • the user can log in to all application systems by inputting a username and password once, wherein a client tool can query the user' s credential information in the credential vault, and simulate user input by inputting a username and user password.
  • Credential vault approaches require no modification of the application systems in the SSO system, and are therefore used more widely.
  • credential vault approaches are accomplished by a client tool (also called a password manager) , which has a definite failing:
  • Password managers need to be configured on each user terminal, and this is liable to increase the complexity of management and maintenance .
  • the object of the present invention is to provide an SSO mechanism to be implemented in existing
  • an SSO method comprising the following steps: receiving a user login request sent by a client to an
  • a proxy server comprising: a receiving module, for receiving a login request sent by a client to an application system, and receiving an
  • a generating module for generating the authentication data packet on the basis of the received login request by analyzing a communication protocol between the client and the application system; and a sending module, for sending the authentication data packet to the application system, and returning the authentication result to the client .
  • an SSO system comprising: a client, for sending a user login request to an application system, and receiving an authentication result returned by a proxy server; the proxy server, for receiving the login request, generating an authentication data packet on the basis of the received login request by analyzing a communication protocol between the client and the application system, sending the authentication data packet to the application system, receiving an
  • Fig. 1 is a diagram of the main structure of the SSO system in the embodiments of the present invention in the case where the credential vault is located outside the proxy server;
  • Fig. 2 is a main flow chart of the SSO method in the
  • Fig. 3 is a flow chart of an SSO method based on the Telnet protocol in the embodiments of the present invention.
  • Fig. 4A is a flow chart of a login method used in the prior art under the FTP protocol ;
  • Fig. 4B is a flow chart of SSO under the FTP protocol in the embodiments of the present invention.
  • Fig. 5A is a flow chart of a login method used in the prior art under the SSH-1 protocol
  • Fig. 5B is a flow chart of SSO under the SSH-1 protocol in the embodiments of the present invention.
  • Fig. 1 is a diagram of the main structure of the SSO system in the embodiments of the present invention. It mainly comprises: a client 101, a proxy server 102 and an application system 103. The system may also comprise a credential vault 104. In Fig. 1, the credential vault 104 is located outside the proxy server 102.
  • the client 101 is used for sending a user login request to the application system 103; the proxy server 102 receives the login request, generates an authentication data packet on the basis of the login request received by analyzing a communication protocol between the client 101 and the application system 103, sends the authentication data packet to the application system 103, receives an authentication result returned by the
  • the client 101 may first conduct a handshake procedure with the application system 103 via the proxy server 102, wherein the specific number of handshakes must be determined according to the specific protocol, and the handshake procedure may be initiated either by the client 101 or by the application system 103. Once the handshake procedure is finished, an authentication process begins; the client 101 is used to send a login request for the user to sign on to the application system 103, the login request sent thereby being received by the proxy server 102.
  • the client 101 in the embodiments of the present invention may be a client of the application system; if the SSO system is a B/S (browser/server) architecture, the client 101 in the embodiments of the present invention may be a browser.
  • the client 101 in the embodiments of the present invention may be modified accordingly to suit the architecture of the SSO system. As long as the client 101 is able to interact with the application system 103 and is used to send a user login request, it will fall within the scope of protection of the present invention.
  • the application system 103 there may be multiple clients 101, and there may be various users who send login requests to the application system 103 via different clients 101; or multiple users may send login requests to the application system 103 via a single client 101.
  • the proxy server 102 is used for receiving the login request, generating an authentication data packet on the basis of the login request received by analyzing a communication protocol between the client 101 and the application system 103, sending the authentication data packet to the application system 103, receiving an authentication result returned by the application system 103, and sending the authentication result to the client 101.
  • credential information for user A in the application system 103 can be queried in the credential vault 104 according to a user identifier of user A, an authentication data packet for authenticating user identity can be generated on the basis of the credential information so obtained, and the
  • authentication data packet can be sent to the application system 103. If no credential information corresponding to user A was found in the credential vault 104, then authentication is impossible, and the proxy server 102 can return a message to the client 101 indicating that authentication is impossible.
  • the credential information may comprise a user identifier and user password of the user in the application system 103, or may comprise a ticket of the user in the application system 103, or may be other information.
  • the proxy server 102 may also be used for receiving an
  • the authentication response message sent by the application system 103. If a challenge-response authentication mechanism has been chosen, the authentication response message will comprise challenge data; for example, one form of realization of challenge data is a random number.
  • the proxy server 102 receives an authentication response message carrying a random number sent by the application system 103, and analyzes the authentication response message, the specific analysis
  • the protocol being used is identified by port number, e.g.: http (hypertext transfer protocol) generally uses port 80, FTP (file transfer protocol) generally uses port 21, telnet (remote login) protocol generally uses port 23, SSH (secure shell) protocol generally uses port 22, SMTP (simple mail transfer protocol) generally uses port 25, etc.
  • the protocol port number may also be negotiated between the client 101 and the application system 103, and if the proxy server 102 is deployed at this time, then the proxy server 102 is responsible for negotiating the port used by a protocol with the application system 103 on behalf of the client 101. Once the protocol used has been ascertained by means of the port, the proxy server 102 can use its protocol state machine to analyze messages exchanged by the client 101 and application system 103, and provide corresponding
  • the proxy server 102 If, based on protocol analysis, it is necessary to generate response data on the basis of the random number, the proxy server 102 generates response data and sends this response data to the application system 103.
  • the proxy server 102 Upon receiving an authentication successful message or an authentication failed message returned by the application system 103, the proxy server 102 can return this authentication result to the client 101.
  • the entire authentication process may be transparent as far as the user 101 and the application system 103 are concerned; the user and application system may be completely unaware of the existence of the proxy server 102.
  • the application system 103 is used for authenticating a received authentication data packet, and sending an
  • the application system 103 receives the authentication data packet sent by the proxy server 102, wherein the authentication data packet may include a user identifier and credential information
  • the application system 103 generates an authentication response message on the basis of the
  • the message may include random information which can be a form of realization of challenge data.
  • the challenge-response mechanism is an authentication mechanism of the application system 103 and can prevent replay attacks and brute force attacks .
  • the credential vault 104 may be located inside the proxy server 102, or may be a storage device located outside the proxy server 102, and is used for storing credential information of a user which is used when logging in to various systems .
  • the user identifier and credential information of each user can be stored in one-to-one correspondence in the credential vault 104. This enables the proxy server 102 to query the appropriate credential information on the basis of a user identifier.
  • the user identifier may also simply be the corresponding credential information, or part of the corresponding credential
  • the user identifier may simply be a username, and the proxy server 102 may query the corresponding user password on the basis of the username.
  • the credential vault 104 may be set up with a password, or have some other security measure in place, to ensure the security of the data stored therein.
  • the proxy server 102 is independent of the client 101 and the application system 103, and so is suitable for use with different types and versions of client application programs; moreover, the proxy server 102 is located between the client 101 and the application system 103, so there is no need to modify the configuration and application environment of the client 101 and the application system 103, so configuration is convenient .
  • the main procedure of the SSO method in the embodiments of the present invention is as follows, wherein the method may be applied to the proxy server 102 side:
  • Step 201 receiving a user login request sent by the client 101 to the application system 103.
  • Step 202 generating an authentication data packet on the basis of the login request received by protocol analysis, and sending the authentication data packet to the application system 103.
  • Step 203 receiving an authentication result returned by the application system 103, and returning the authentication result received to the client 101; wherein the authentication result is generated by the application system after authenticating the authentication data packet received.
  • the client 101 and application system 103 have a negotiated secret function f (wherein the application system 103 thinks that the secret function f was generated through negotiation between itself and the client 101, but in fact, during negotiation of the secret function, it was the proxy server 102 which received the information sent by the application system 103 and
  • the application system 103 can calculate r independently to verify whether the r returned by the proxy server 102 is correct, and if it is, return an authentication successful message to the client 101; the proxy server 102 can receive the authentication successful message.
  • the application system 103 can return an authentication failed message to the client 101; the proxy server 102 receives the authentication failed message, so the application system 103 effectively sends the authentication result to the proxy server 102.
  • the proxy server 102 can use a one-way Hash function to generate a byte string as response information on the basis of the username, credential information and random information, and send the byte string to the application system 103.
  • the application system 103 compares the response information with its own calculation result, and if the two are the same, can return an authentication successful message to the client 101, the authentication successful message being received by the proxy server 102; if the two are not the same,
  • the authentication process may not use a challenge-response mechanism; another authentication mechanism may be used as required.
  • the method is presented using the Telnet protocol as an example .
  • Step 1 a terminal sends a login request to an application system.
  • the handshake procedure is unrelated to the interactive process of user authentication, and is omitted here.
  • Step 2 the application system responds to the terminal with a login prompt message.
  • Step 3 the terminal user inputs a username.
  • Step 4 the application system generates a "password" prompt message, and prompts the terminal user to input a user
  • Step 5 the terminal inputs a user password.
  • Step 6 the application system verifies user identity
  • each terminal may have a client application program of a different type and version, which increases the difficulty of operation .
  • Fig. 3 is the detailed procedure of an SSO method under the Telnet protocol in the embodiments of the present invention:
  • Step 301 a client 101 sends a user login request to an application system 103.
  • the client 101 sends the login request to the
  • the application system 103 via a proxy server 102, and the proxy server 102 receives the login request.
  • Step 302 the proxy server 102 forwards the login request directly .
  • Step 303 the application system 103 prompts the client 101 with a "login” message.
  • the proxy server 102 receives the "login” message. For instance, the "login” message may prompt the user to input a username.
  • Step 304 on the basis of a user identifier of a user in the login request received, the proxy server 102 queries the credential vault 104 for the corresponding credential
  • Step 305 the proxy server 102 generates a response data packet on the basis of the username, and sends this response data packet to the application system 103.
  • Step 306 the server prompts the client 101 with a "Password” message.
  • the proxy server 102 receives the "password” message.
  • the "Password” message may prompt the user to input a user password.
  • Step 307 the proxy server 102 generates a second response data packet on the basis of the user password, and sends this second response data packet to the application system 103.
  • Step 308 the application system 103 authenticates the user information, and returns an authentication result to the client 101.
  • the proxy server 102 receives the authentication result. If authentication is successful, a "welcome" message can be returned to the client 101; if authentication fails, an authentication failed message can be returned to the client 101. The authentication process ends.
  • Step 309 the proxy server 102 returns the authentication result received to the client 101.
  • Two the method is presented using the FTP protocol as an example .
  • FIG. 4A a login method used in the prior art under the FTP protocol is first presented briefly:
  • Step 1 a terminal sends a login request to an application system.
  • the handshake procedure is unrelated to the interactive process of user authentication, and is omitted here.
  • Step 2 the application system negotiates with the terminal.
  • Step 3 once negotiation is complete, the application system replies to the terminal with a response message.
  • the response message may prompt the terminal to input a username.
  • Step 4 the terminal inputs a username to the application system.
  • Step 5 the application system replies with a response message
  • the response message may prompt the terminal to input a password .
  • Step 6 the terminal inputs a user password.
  • Step 7 the application system verifies the user identity authentication information, and responds to the terminal with a "welcome” message. The authentication process is complete.
  • Fig. 4B is the detailed procedure of an SSO method under the FTP protocol in the embodiments of the present invention :
  • Step 401 a client 101 sends a user login request to an application system 103.
  • the client 101 sends the login request to the
  • the application system 103 via a proxy server 102, and the proxy server 102 forwards the login request directly.
  • Step 402 the application system 103 negotiates with the client 101 via the proxy server 102.
  • Step 403 when negotiation is complete, the application system 103 replies to the client 101 with a response message.
  • the proxy server 102 receives the response message, which may prompt the user to input a username .
  • the application system 103 prompts the client 101 with a "login” message.
  • the proxy server 102 receives the "login” message.
  • Step 404 on the basis of a user identifier of a user in the login request received, the proxy server 102 queries the credential vault 104 for the corresponding credential
  • Step 405 the proxy server 102 generates a response data packet on the basis of the username, and sends this response data packet to the application system 103.
  • Step 406 the application system 103 replies to the client 101 with a response message.
  • the proxy server 102 receives the response message, which may prompt the user to input a
  • the application system 103 prompts the client 101 with a "Password” message.
  • the proxy server 102 receives the "password” message.
  • Step 407 the proxy server 102 generates a second response data packet on the basis of the user password, and sends this second response data packet to the application system 103.
  • Step 408 the application system 103 authenticates the user information, and returns an authentication result to the client 101.
  • the proxy server 102 receives the authentication result.
  • Step 409 the proxy server 102 returns the authentication result received to the client 101.
  • the authentication process ends.
  • a login method used in the prior art under the SSH-1 protocol is first presented briefly:
  • Step 1 a terminal and application program conduct version negotiation .
  • Step 2 the terminal and application program negotiate the operating rules.
  • Step 3 the terminal inputs a username.
  • Step 4 the application program replies with a response message.
  • the response message may prompt the terminal to input a password.
  • Step 5 the terminal inputs a user password.
  • Step 6 the application system verifies the user identity authentication information, and replies to the terminal with a "welcome” message. The authentication process is complete.
  • Fig. 5B is the detailed procedure of an SSO method under the SSH-1 protocol in the embodiments of the present invention:
  • Step 501 the client 101 negotiates the version with the application program 103 via the proxy server 102.
  • Step 502 the client 101 negotiates the operating rules with the application program 103 via the proxy server 102.
  • Step 503 the proxy server 102 receives a response message returned by the application program 103 to the client 101.
  • the response message may prompt the user to input a username.
  • the application system 103 prompts the client 101 with an "SSH_CMSG_USER" message.
  • the proxy server 102 receives the "SSH_CMSG_USER” message.
  • Step 504 the proxy server 102 generates a response data packet on the basis of the username, and sends this response data packet to the application system 103.
  • Step 505 the proxy server receives a response message returned by the application system 103 to the client 101.
  • the response message may prompt the user to input a password.
  • the application system 103 prompts the client 101 with an "SSH_CMSG_PASSWORD" message.
  • the proxy server 102 receives the "SSH_CMSG_PASSWORD" message.
  • Step 506 the proxy server 102 generates a second response data packet on the basis of the user password, and sends this second response data packet to the application system 103.
  • Step 507 the application system 103 authenticates the user information, and returns an authentication result to the client 101. The proxy server 102 receives the authentication result.
  • Step 508 the proxy server 102 returns the authentication result received to the client 101.
  • the authentication process ends.
  • the proxy server 102 may comprise a receiving module, a generating module and a sending module.
  • the receiving module is used for receiving a login request sent by the client 101 to the application system 103, and for receiving the authentication result returned by the application system 103.
  • the generating module is used for generating an authentication data packet on the basis of the login request received by analyzing a communication protocol between the client and the application system.
  • the generating module may specifically be used for querying a credential vault for credential information of the user in the application system 103 on the basis of a user identifier in the login request received, and for generating the authentication data packet on the basis of the credential information of the user.
  • the sending module is used for sending the authentication data packet to the application system 103, and for returning an authentication result to the client 101.
  • a proxy server 102 is provided between the client 101 and the application system 103, the proxy server 102 being able to obtain corresponding credential information on behalf of the client 101 by protocol analysis, and hence solving the problem in the prior art that separate client tools need to be deployed at different clients 101.
  • the login process can be completed through information exchange between the proxy server 102 and the application system 103.
  • There is no need to configure a password manager on the client 101 and only one proxy server 102 need be maintained and managed, bringing savings in terms of maintenance and management steps and costs.
  • the absence of a password manager means that the restrictions which client application programs place on password managers are eliminated, making operation simpler. Authentication of different terminals is possible, with no increase in the complexity of management and maintenance.
  • the hardware units may be realized mechanically or electrically.
  • 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 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.
  • 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 embodiments 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 in the storage medium.
  • the program code read from the storage medium is itself capable of realizing the functions of any one of the above embodiments, hence the program code and the storage medium on which the program code is stored form part of the present invention.
  • Embodiments of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (e.g. CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD- RW, DVD+RW) , magnetic tape, non-volatile memory cards and ROM.
  • a communication network may download program code from a server computer.
  • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Disclosed in the present invention is a SSO method, involving: receiving a user login request sent by a client (101) to an application system (103); generating an authentication data packet on the basis of the login request received by analyzing a communication protocol between the client (101) and the application system (103), and sending the authentication data packet to the application system (103); and receiving an authentication result returned by the application system (103), and returning the authentication result received to the client (101); wherein the authentication result is generated by the application system (103) after authenticating the authentication data packet received. Also disclosed are a proxy server (102) and SSO system used to realize the method. The present invention is easily implemented in existing application systems, being simple to realize and having reduced implementation costs.

Description

Description
Single Sign-on method, proxy server and system
Technical field
The present invention relates to the field of communications, in particular to a Single Sign-on method, proxy server and system.
Background art
Different application systems may have different hardware platforms, operating systems and authentication modes, but in the Single Sign-on (SSO) mechanism, a user can access all application systems which trust each other by simply logging in once (i.e. inputting a user name and user password once) . This mechanism is one of the more popular solutions for business integration in enterprises.
SSO methods can be broadly divided into two main types: ticket- based approaches and credential vault approaches.
Ticket -based approaches are more secure. They use the Kerberos protocol, which is founded on a password system of symmetric keys, and enables secure communication between different users in an insecure network system. However, ticket -based approaches generally necessitate alteration of the SSO application system to support authentication and decryption of tickets.
Credential vault approaches store user credentials (generally including a user' s usernames and passwords for different systems) safely; for example, storage may be effected by encrypting a database. The user can log in to all application systems by inputting a username and password once, wherein a client tool can query the user' s credential information in the credential vault, and simulate user input by inputting a username and user password. Credential vault approaches require no modification of the application systems in the SSO system, and are therefore used more widely.
In most cases, credential vault approaches are accomplished by a client tool (also called a password manager) , which has a definite failing:
Password managers need to be configured on each user terminal, and this is liable to increase the complexity of management and maintenance .
Content of the invention
In view of the above, the object of the present invention is to provide an SSO mechanism to be implemented in existing
application systems, which is simple to realize and has reduced implementation costs.
According to one embodiment of the present invention, an SSO method is provided, comprising the following steps: receiving a user login request sent by a client to an
application system; generating an authentication data packet on the basis of the received login request by analyzing a communication protocol between the client and the application system, and sending the authentication data packet to the application system; receiving an authentication result returned by the application system, and returning the received authentication result to the client; wherein the authentication result is generated by the application system after authenticating the received
authentication data packet. According to one embodiment of the present invention, a proxy server is provided, comprising: a receiving module, for receiving a login request sent by a client to an application system, and receiving an
authentication result returned by the application system;
wherein the authentication result is generated by the
application system after authenticating an received
authentication data packet; a generating module, for generating the authentication data packet on the basis of the received login request by analyzing a communication protocol between the client and the application system; and a sending module, for sending the authentication data packet to the application system, and returning the authentication result to the client .
According to one embodiment of the present invention, an SSO system is provided, comprising: a client, for sending a user login request to an application system, and receiving an authentication result returned by a proxy server; the proxy server, for receiving the login request, generating an authentication data packet on the basis of the received login request by analyzing a communication protocol between the client and the application system, sending the authentication data packet to the application system, receiving an
authentication result returned by the application system, and returning the authentication result to the client; and the application system, for authenticating the received authentication data packet, and returning the authentication result to the client. 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 understandable way by describing preferred embodiments with reference to the accompanying drawings, wherein:
Fig. 1 is a diagram of the main structure of the SSO system in the embodiments of the present invention in the case where the credential vault is located outside the proxy server;
Fig. 2 is a main flow chart of the SSO method in the
embodiments of the present invention;
Fig. 3 is a flow chart of an SSO method based on the Telnet protocol in the embodiments of the present invention;
Fig. 4A is a flow chart of a login method used in the prior art under the FTP protocol ;
Fig. 4B is a flow chart of SSO under the FTP protocol in the embodiments of the present invention;
Fig. 5A is a flow chart of a login method used in the prior art under the SSH-1 protocol;
Fig. 5B is a flow chart of SSO under the SSH-1 protocol in the embodiments of the present invention.
Particular embodiments
In order that the technical features, object and effects of the present invention may be understood more clearly, particular embodiments of the present invention are now explained with reference to the accompanying drawings, in which identical labels indicate identical parts. To clearly show the relationships between the various components, the proportions thereof with respect to one another in the drawings are merely schematic, and by no means indicate the proportions in the actual structure.
Fig. 1 is a diagram of the main structure of the SSO system in the embodiments of the present invention. It mainly comprises: a client 101, a proxy server 102 and an application system 103. The system may also comprise a credential vault 104. In Fig. 1, the credential vault 104 is located outside the proxy server 102.
The client 101 is used for sending a user login request to the application system 103; the proxy server 102 receives the login request, generates an authentication data packet on the basis of the login request received by analyzing a communication protocol between the client 101 and the application system 103, sends the authentication data packet to the application system 103, receives an authentication result returned by the
application system 103, and returns the authentication result to the client 101.
Before sending the login request, the client 101 may first conduct a handshake procedure with the application system 103 via the proxy server 102, wherein the specific number of handshakes must be determined according to the specific protocol, and the handshake procedure may be initiated either by the client 101 or by the application system 103. Once the handshake procedure is finished, an authentication process begins; the client 101 is used to send a login request for the user to sign on to the application system 103, the login request sent thereby being received by the proxy server 102.
If the SSO system is a C/S (client/server) architecture, the client 101 in the embodiments of the present invention may be a client of the application system; if the SSO system is a B/S (browser/server) architecture, the client 101 in the embodiments of the present invention may be a browser.
Moreover, those skilled in the art should be aware that if the SSO system employs a different architecture, the client 101 in the embodiments of the present invention may be modified accordingly to suit the architecture of the SSO system. As long as the client 101 is able to interact with the application system 103 and is used to send a user login request, it will fall within the scope of protection of the present invention.
In one SSO system, there may be multiple clients 101, and there may be various users who send login requests to the application system 103 via different clients 101; or multiple users may send login requests to the application system 103 via a single client 101. In the embodiments of the present invention, no matter whether the application scenario involves multiple clients 101, or multiple users using a single client 101, they may all share a single proxy server 102; there is no need to add extra equipment, and so the complexity and costs involved in realizing the system are reduced.
The proxy server 102 is used for receiving the login request, generating an authentication data packet on the basis of the login request received by analyzing a communication protocol between the client 101 and the application system 103, sending the authentication data packet to the application system 103, receiving an authentication result returned by the application system 103, and sending the authentication result to the client 101. When the proxy server 102 receives a login request from a user A, credential information for user A in the application system 103 can be queried in the credential vault 104 according to a user identifier of user A, an authentication data packet for authenticating user identity can be generated on the basis of the credential information so obtained, and the
authentication data packet can be sent to the application system 103. If no credential information corresponding to user A was found in the credential vault 104, then authentication is impossible, and the proxy server 102 can return a message to the client 101 indicating that authentication is impossible.
In the embodiments of the present invention, the credential information may comprise a user identifier and user password of the user in the application system 103, or may comprise a ticket of the user in the application system 103, or may be other information.
The proxy server 102 may also be used for receiving an
authentication response message sent by the application system 103. If a challenge-response authentication mechanism has been chosen, the authentication response message will comprise challenge data; for example, one form of realization of challenge data is a random number. The proxy server 102 receives an authentication response message carrying a random number sent by the application system 103, and analyzes the authentication response message, the specific analysis
procedure being different for different protocols.
For example, in general, the protocol being used is identified by port number, e.g.: http (hypertext transfer protocol) generally uses port 80, FTP (file transfer protocol) generally uses port 21, telnet (remote login) protocol generally uses port 23, SSH (secure shell) protocol generally uses port 22, SMTP (simple mail transfer protocol) generally uses port 25, etc. Of course, the protocol port number may also be negotiated between the client 101 and the application system 103, and if the proxy server 102 is deployed at this time, then the proxy server 102 is responsible for negotiating the port used by a protocol with the application system 103 on behalf of the client 101. Once the protocol used has been ascertained by means of the port, the proxy server 102 can use its protocol state machine to analyze messages exchanged by the client 101 and application system 103, and provide corresponding
credential information to the application server 103 on behalf of the client 101. If, based on protocol analysis, it is necessary to generate response data on the basis of the random number, the proxy server 102 generates response data and sends this response data to the application system 103.
Upon receiving an authentication successful message or an authentication failed message returned by the application system 103, the proxy server 102 can return this authentication result to the client 101.
The entire authentication process may be transparent as far as the user 101 and the application system 103 are concerned; the user and application system may be completely unaware of the existence of the proxy server 102.
The application system 103 is used for authenticating a received authentication data packet, and sending an
authentication result to the proxy server 102. The application system 103 receives the authentication data packet sent by the proxy server 102, wherein the authentication data packet may include a user identifier and credential information
corresponding to the user. The application system 103 generates an authentication response message on the basis of the
authentication data packet received, and if a challenge- response mechanism was chosen, the message may include random information which can be a form of realization of challenge data. The challenge-response mechanism is an authentication mechanism of the application system 103 and can prevent replay attacks and brute force attacks .
The credential vault 104 may be located inside the proxy server 102, or may be a storage device located outside the proxy server 102, and is used for storing credential information of a user which is used when logging in to various systems . The user identifier and credential information of each user can be stored in one-to-one correspondence in the credential vault 104. This enables the proxy server 102 to query the appropriate credential information on the basis of a user identifier. The user identifier may also simply be the corresponding credential information, or part of the corresponding credential
information. For example, the user identifier may simply be a username, and the proxy server 102 may query the corresponding user password on the basis of the username. In the embodiments of the present invention, the credential vault 104 may be set up with a password, or have some other security measure in place, to ensure the security of the data stored therein.
When the technical solution of the embodiments of the present invention is adopted, only one proxy server 102 need be maintained and managed; there is no need to reconfigure the client 101, so the maintenance and management procedures are simpler while costs are reduced. In the embodiments of the present invention, the proxy server 102 is independent of the client 101 and the application system 103, and so is suitable for use with different types and versions of client application programs; moreover, the proxy server 102 is located between the client 101 and the application system 103, so there is no need to modify the configuration and application environment of the client 101 and the application system 103, so configuration is convenient .
In order to better illustrate the idea of the present
invention, the SSO method in the embodiments of the present invention is presented below through the implementation procedure thereof .
Referring to Fig. 2, the main procedure of the SSO method in the embodiments of the present invention is as follows, wherein the method may be applied to the proxy server 102 side:
Step 201: receiving a user login request sent by the client 101 to the application system 103. Step 202: generating an authentication data packet on the basis of the login request received by protocol analysis, and sending the authentication data packet to the application system 103.
Step 203 : receiving an authentication result returned by the application system 103, and returning the authentication result received to the client 101; wherein the authentication result is generated by the application system after authenticating the authentication data packet received.
In the embodiments of the present invention, suppose that the client 101 and application system 103 have a negotiated secret function f (wherein the application system 103 thinks that the secret function f was generated through negotiation between itself and the client 101, but in fact, during negotiation of the secret function, it was the proxy server 102 which received the information sent by the application system 103 and
exchanged information with the application system to negotiate the generation of the secret function f, hence the secret function f was in fact generated through negotiation between the proxy server 102 and the application system 103) .
Challenge-response authentication process: the challenge process involves the application system 103 sending a random message m to the client 101; the response process involves the proxy server 102 receiving the random message m, performing a calculation on the basis of the random information, and replying to the application system 103 with r = f (m) , a modification of m. The application system 103 can calculate r independently to verify whether the r returned by the proxy server 102 is correct, and if it is, return an authentication successful message to the client 101; the proxy server 102 can receive the authentication successful message. If the r returned by the proxy server is not correct, the application system 103 can return an authentication failed message to the client 101; the proxy server 102 receives the authentication failed message, so the application system 103 effectively sends the authentication result to the proxy server 102. For instance, the proxy server 102 can use a one-way Hash function to generate a byte string as response information on the basis of the username, credential information and random information, and send the byte string to the application system 103. After receiving the response information from the proxy server 102, the application system 103 compares the response information with its own calculation result, and if the two are the same, can return an authentication successful message to the client 101, the authentication successful message being received by the proxy server 102; if the two are not the same,
authentication fails and the application system can return an authentication failed message to the client 101, the
authentication failed message being received by the proxy server 102. Alternatively, the authentication process may not use a challenge-response mechanism; another authentication mechanism may be used as required.
The SSO method in the embodiments of the present invention is presented below through examples of the implementation
procedure thereof .
One: the method is presented using the Telnet protocol as an example .
First of all, a login method used in the prior art under the Telnet protocol is presented briefly:
Step 1: a terminal sends a login request to an application system. Under the Telnet protocol, the handshake procedure is unrelated to the interactive process of user authentication, and is omitted here.
Step 2: the application system responds to the terminal with a login prompt message.
Step 3: the terminal user inputs a username. Step 4: the application system generates a "password" prompt message, and prompts the terminal user to input a user
password .
Step 5: the terminal inputs a user password.
Step 6: the application system verifies user identity
authentication information, and responds to the terminal with a "welcome" message. The authentication process is complete.
During the authentication process, there may be different terminals requiring authentication, so it may be necessary to configure a password manager on each terminal, increasing the complexity of management and maintenance. If there are multiple terminals requiring authentication, although each terminal has the same target server and operates under the same protocol, each terminal may have a client application program of a different type and version, which increases the difficulty of operation .
Referring to Fig. 3, which is the detailed procedure of an SSO method under the Telnet protocol in the embodiments of the present invention:
Step 301: a client 101 sends a user login request to an application system 103.
In fact, the client 101 sends the login request to the
application system 103 via a proxy server 102, and the proxy server 102 receives the login request. There may be different users who send login requests to the application system 103 via a single client 101, each user having his own credential information which can be stored together with a corresponding user identifier in a credential vault 104.
Step 302: the proxy server 102 forwards the login request directly . Step 303: the application system 103 prompts the client 101 with a "login" message. The proxy server 102 receives the "login" message. For instance, the "login" message may prompt the user to input a username.
Step 304: on the basis of a user identifier of a user in the login request received, the proxy server 102 queries the credential vault 104 for the corresponding credential
information, such as username and password, of the user in the application system 103.
Step 305: the proxy server 102 generates a response data packet on the basis of the username, and sends this response data packet to the application system 103.
Step 306: the server prompts the client 101 with a "Password" message. The proxy server 102 receives the "password" message. For example, the "Password" message may prompt the user to input a user password.
Step 307: the proxy server 102 generates a second response data packet on the basis of the user password, and sends this second response data packet to the application system 103.
Step 308: the application system 103 authenticates the user information, and returns an authentication result to the client 101. The proxy server 102 receives the authentication result. If authentication is successful, a "welcome" message can be returned to the client 101; if authentication fails, an authentication failed message can be returned to the client 101. The authentication process ends.
Step 309: the proxy server 102 returns the authentication result received to the client 101. Two: the method is presented using the FTP protocol as an example .
Referring to Fig. 4A, a login method used in the prior art under the FTP protocol is first presented briefly:
Step 1: a terminal sends a login request to an application system. Under the FTP protocol, the handshake procedure is unrelated to the interactive process of user authentication, and is omitted here.
Step 2: the application system negotiates with the terminal.
Step 3: once negotiation is complete, the application system replies to the terminal with a response message. The response message may prompt the terminal to input a username.
Step 4: the terminal inputs a username to the application system.
Step 5: the application system replies with a response message The response message may prompt the terminal to input a password .
Step 6: the terminal inputs a user password.
Step 7 : the application system verifies the user identity authentication information, and responds to the terminal with a "welcome" message. The authentication process is complete.
Referring to Fig. 4B, which is the detailed procedure of an SSO method under the FTP protocol in the embodiments of the present invention :
Step 401: a client 101 sends a user login request to an application system 103. In fact, the client 101 sends the login request to the
application system 103 via a proxy server 102, and the proxy server 102 forwards the login request directly. There may be different users who send login requests to the application system 103 via a single client 101, each user having his own credential information which can be stored together with a corresponding user identifier in a credential vault 104.
Step 402: the application system 103 negotiates with the client 101 via the proxy server 102.
Step 403: when negotiation is complete, the application system 103 replies to the client 101 with a response message. The proxy server 102 receives the response message, which may prompt the user to input a username .
For example, the application system 103 prompts the client 101 with a "login" message. The proxy server 102 receives the "login" message.
Step 404: on the basis of a user identifier of a user in the login request received, the proxy server 102 queries the credential vault 104 for the corresponding credential
information, such as username and password, of the user in the application system 103.
Step 405: the proxy server 102 generates a response data packet on the basis of the username, and sends this response data packet to the application system 103.
Step 406: the application system 103 replies to the client 101 with a response message. The proxy server 102 receives the response message, which may prompt the user to input a
password . For example, the application system 103 prompts the client 101 with a "Password" message. The proxy server 102 receives the "password" message.
Step 407: the proxy server 102 generates a second response data packet on the basis of the user password, and sends this second response data packet to the application system 103.
Step 408: the application system 103 authenticates the user information, and returns an authentication result to the client 101. The proxy server 102 receives the authentication result.
Step 409: the proxy server 102 returns the authentication result received to the client 101.
The authentication process ends.
Three: the method is presented using the SSH-1 protocol as an example .
Referring to Fig. 5A, a login method used in the prior art under the SSH-1 protocol is first presented briefly:
Step 1: a terminal and application program conduct version negotiation .
Step 2: the terminal and application program negotiate the operating rules.
Step 3: the terminal inputs a username.
Step 4: the application program replies with a response message. The response message may prompt the terminal to input a password.
Step 5: the terminal inputs a user password. Step 6: the application system verifies the user identity authentication information, and replies to the terminal with a "welcome" message. The authentication process is complete.
Referring to Fig. 5B, which is the detailed procedure of an SSO method under the SSH-1 protocol in the embodiments of the present invention:
Step 501: the client 101 negotiates the version with the application program 103 via the proxy server 102.
Step 502: the client 101 negotiates the operating rules with the application program 103 via the proxy server 102.
Step 503 : the proxy server 102 receives a response message returned by the application program 103 to the client 101. The response message may prompt the user to input a username.
For example, the application system 103 prompts the client 101 with an "SSH_CMSG_USER" message. The proxy server 102 receives the "SSH_CMSG_USER" message.
Step 504 : the proxy server 102 generates a response data packet on the basis of the username, and sends this response data packet to the application system 103.
Step 505: the proxy server receives a response message returned by the application system 103 to the client 101. The response message may prompt the user to input a password.
For example, the application system 103 prompts the client 101 with an "SSH_CMSG_PASSWORD" message. The proxy server 102 receives the "SSH_CMSG_PASSWORD" message.
Step 506 : the proxy server 102 generates a second response data packet on the basis of the user password, and sends this second response data packet to the application system 103. Step 507: the application system 103 authenticates the user information, and returns an authentication result to the client 101. The proxy server 102 receives the authentication result.
Step 508 : the proxy server 102 returns the authentication result received to the client 101.
The authentication process ends.
According to the embodiments of the present invention, the proxy server 102 may comprise a receiving module, a generating module and a sending module.
The receiving module is used for receiving a login request sent by the client 101 to the application system 103, and for receiving the authentication result returned by the application system 103.
The generating module is used for generating an authentication data packet on the basis of the login request received by analyzing a communication protocol between the client and the application system.
In the embodiments of the present invention, the generating module may specifically be used for querying a credential vault for credential information of the user in the application system 103 on the basis of a user identifier in the login request received, and for generating the authentication data packet on the basis of the credential information of the user.
The sending module is used for sending the authentication data packet to the application system 103, and for returning an authentication result to the client 101.
In the embodiments of the present invention, a proxy server 102 is provided between the client 101 and the application system 103, the proxy server 102 being able to obtain corresponding credential information on behalf of the client 101 by protocol analysis, and hence solving the problem in the prior art that separate client tools need to be deployed at different clients 101.
With the proxy server 102 added between the client 101 and the application system 103, the login process can be completed through information exchange between the proxy server 102 and the application system 103. There is no need to configure a password manager on the client 101, and only one proxy server 102 need be maintained and managed, bringing savings in terms of maintenance and management steps and costs. Moreover, the absence of a password manager means that the restrictions which client application programs place on password managers are eliminated, making operation simpler. Authentication of different terminals is possible, with no increase in the complexity of management and maintenance.
In the prior art, it is very likely that different users will log in to a target device using different types and versions of client terminal programs. Although these password managers have the same target device and operate under the same protocol, it is nevertheless necessary to configure the password managers according to different types and versions of client terminal programs, which increases the difficulty of operation.
Moreover, most password managers only support client terminal programs based on the Microsoft Windows platform (an operating system) , and not Linux X-Window (an operating system) or other types of client terminal programs. When the method of the present invention is adopted, since there is no need to install a password manager on the client, there is therefore no need to configure password managers according to different client terminal programs, which reduces the amount of work. There is also no need to take into account the problem of password managers not supporting certain types of client terminal programs, so versatility is enhanced. It must be explained that not all of the steps and modules in the above procedures and structural diagrams of devices 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 module structures described in the above embodiments 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 embodiments, 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 embodiments 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 in 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 embodiments, hence the program code and the storage medium on which the program code is stored form part of the present invention.
Embodiments of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (e.g. 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 embodiments.
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

Claims
1. A Single Sign-on method, comprising the following steps: receiving a user login request sent by a client to an application system;
generating an authentication data packet on the basis of the received login request by analyzing a communication protocol between the client and the application system, and sending the authentication data packet to the application system; and
receiving an authentication result returned by the application system, and returning the received authentication result to the client; wherein the authentication result is generated by the application system after authenticating the received authentication data packet.
2. The method as claimed in claim 1, characterized in that the step of generating an authentication data packet on the basis of the login request received and sending the authentication data packet to the application system comprises: querying a credential vault for credential information of the user in the application system on the basis of a user identifier in the login request received, generating an authentication data packet on the basis of the credential information of the user, and sending the authentication packet to the application system.
3. The method as claimed in claim 2, characterized in that the credential information comprises a user identifier and user password of the user in the application system; or the credential information comprises a ticket of the user in the application system.
4. A proxy server, comprising:
a receiving module, for receiving a login request sent by a client to an application system, and receiving an authentication result returned by the application system; wherein the authentication result is generated by the
application system after authenticating an authentication data packet received;
a generating module, for generating the authentication data packet on the basis of the received login request by analyzing a communication protocol between the client and the application system; and
a sending module, for sending the authentication data packet to the application system, and returning the
authentication result to the client.
5. The proxy server as claimed in claim 4, characterized in that the generating module is specifically used for querying a credential vault for credential information of the user in the application system on the basis of a user identifier in the login request received, and for generating the authentication data packet on the basis of the credential information of the user .
6. The proxy server as claimed in claim 5, characterized in that the credential information comprises a user identifier and user password of the user in the application system; or the credential information comprises a ticket of the user in the application system.
7. A Single Sign-on system, comprising:
a client, for sending a user login request to an
application system, and receiving an authentication result returned by a proxy server;
the proxy server, for receiving the login request, generating an authentication data packet on the basis of the received login request by analyzing a communication protocol between the client and the application system, sending the authentication data packet to the application system, receiving an authentication result returned by the application system, and returning the authentication result to the client; and the application system, for authenticating the authentication data packet received, and returning the
authentication result to the client.
8. The system as claimed in claim 7, further comprising:
a credential vault, for storing user identifiers and corresponding credential information in association with each other;
the proxy server being further used for querying the credential vault for credential information of the user in the application system on the basis of a user identifier in the received login request, and generating an authentication data packet on the basis of the credential information of the user.
9. The system as claimed in claim 8, characterized in that the credential information comprises a user identifier and user password of the user in the application system; or the
credential information comprises a ticket of the user in the application system.
10. The system as claimed in claim 7, characterized in that the application system is further used for authenticating the authentication data packet received using a challenge-response mechanism .
11. The system as claimed in claim 10, characterized in that the application system is further used for sending challenge data to the client, and comparing received response data with self -generated response data; if the two are the same, the user authentication succeeds, otherwise authentication fails;
the proxy server is further used for receiving the challenge data, generating response data on the basis of the received challenge data, and sending the response data to the application system.
PCT/EP2013/068986 2012-09-29 2013-09-13 Single sign-on method, proxy server and system WO2014048769A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201210376039.4 2012-09-29
CN201210376039.4A CN103716285A (en) 2012-09-29 2012-09-29 Single sign on method, proxy server and single sign on system

Publications (1)

Publication Number Publication Date
WO2014048769A1 true WO2014048769A1 (en) 2014-04-03

Family

ID=49223756

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/068986 WO2014048769A1 (en) 2012-09-29 2013-09-13 Single sign-on method, proxy server and system

Country Status (2)

Country Link
CN (1) CN103716285A (en)
WO (1) WO2014048769A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015167591A1 (en) * 2014-04-30 2015-11-05 Citrix Stsyems, Inc. Enterprise system authentication and authorization via gateway
CN111314366A (en) * 2020-02-25 2020-06-19 广州致远电子有限公司 MQTT protocol-based secure login system and method
CN112769826A (en) * 2021-01-08 2021-05-07 深信服科技股份有限公司 Information processing method, device, equipment and storage medium
CN114021094A (en) * 2021-11-29 2022-02-08 北京深思数盾科技股份有限公司 Remote server login method, electronic device and storage medium
EP3996342A1 (en) * 2020-11-09 2022-05-11 Bull SAS Method and system for access to a remote application
CN114584353A (en) * 2022-02-23 2022-06-03 上海外服云信息技术有限公司 Single sign-on method for mobile terminal to access CAS

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106506498B (en) * 2016-11-07 2020-07-28 安徽四创电子股份有限公司 Data call authorization authentication method between systems
CN107154936B (en) * 2017-04-27 2018-11-06 腾讯科技（深圳）有限公司 Login method, device and system
CN110177111B (en) * 2019-06-06 2021-09-14 北京芯盾时代科技有限公司 Information verification method, system and device
CN112749182B (en) * 2019-10-30 2023-01-31 深圳市傲冠软件股份有限公司 Method for accessing Oracle database by proxy, audit terminal, device and computer readable storage medium
CN114285897A (en) * 2021-12-22 2022-04-05 杭州安恒信息技术股份有限公司 Application docking method, device, system, electronic equipment and readable storage medium

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0991242A2 (en) * 1998-09-29 2000-04-05 Phone.Com Inc. Method and apparatus for caching credentials in proxy servers for wireless user agents
US20110154464A1 (en) * 2009-12-23 2011-06-23 Puneet Agarwal Systems and methods for intercepting and automatically filling in forms by the appliance for single-sign on
US20110265166A1 (en) * 2010-04-26 2011-10-27 Research In Motion Limited Integrated authentication

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1805336A (en) * 2005-01-12 2006-07-19 北京航空航天大学 Single entering method and system facing ASP mode
JP4867482B2 (en) * 2006-06-06 2012-02-01 富士ゼロックス株式会社 Control program and communication system
CN101902329A (en) * 2009-05-31 2010-12-01 西门子（中国）有限公司 Method and device for single sign on
CN101938356A (en) * 2009-06-30 2011-01-05 西门子（中国）有限公司 Method and device used for certificating user identity
CN102111410B (en) * 2011-01-13 2013-07-03 中国科学院软件研究所 Agent-based single sign on (SSO) method and system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0991242A2 (en) * 1998-09-29 2000-04-05 Phone.Com Inc. Method and apparatus for caching credentials in proxy servers for wireless user agents
US20110154464A1 (en) * 2009-12-23 2011-06-23 Puneet Agarwal Systems and methods for intercepting and automatically filling in forms by the appliance for single-sign on
US20110265166A1 (en) * 2010-04-26 2011-10-27 Research In Motion Limited Integrated authentication

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015167591A1 (en) * 2014-04-30 2015-11-05 Citrix Stsyems, Inc. Enterprise system authentication and authorization via gateway
US9584515B2 (en) 2014-04-30 2017-02-28 Citrix Systems, Inc. Enterprise system authentication and authorization via gateway
CN106471783A (en) * 2014-04-30 2017-03-01 思杰系统有限公司 Business system certification and mandate via gateway
CN106471783B (en) * 2014-04-30 2019-08-23 思杰系统有限公司 Via the business system certification and authorization of gateway
CN111314366A (en) * 2020-02-25 2020-06-19 广州致远电子有限公司 MQTT protocol-based secure login system and method
EP3996342A1 (en) * 2020-11-09 2022-05-11 Bull SAS Method and system for access to a remote application
CN112769826A (en) * 2021-01-08 2021-05-07 深信服科技股份有限公司 Information processing method, device, equipment and storage medium
CN114021094A (en) * 2021-11-29 2022-02-08 北京深思数盾科技股份有限公司 Remote server login method, electronic device and storage medium
CN114584353A (en) * 2022-02-23 2022-06-03 上海外服云信息技术有限公司 Single sign-on method for mobile terminal to access CAS

Also Published As

Publication number Publication date
CN103716285A (en) 2014-04-09

Similar Documents

Publication Publication Date Title
WO2014048769A1 (en) Single sign-on method, proxy server and system
US20220255918A1 (en) Single sign on for a remote user session
CN110770695B (en) Internet of things (IOT) device management
CN107239688B (en) The purview certification method and system in Docker mirror image warehouse
US10630489B2 (en) Apparatus and method for managing digital certificates
WO2017186005A1 (en) Method, server, and terminal for cloud desktop authentication
EP2283669B1 (en) Trusted device-specific authentication
WO2016202139A1 (en) Method, device and system for realizing cross-platform account resource sharing
CN106452772B (en) Terminal authentication method and device
Carretero et al. Federated identity architecture of the European eID system
CN102624720B (en) Method, device and system for identity authentication
WO2014048749A1 (en) Inter-domain single sign-on
KR20170056566A (en) System and method for integrating an authentication service within a network architecture
CN101534192B (en) System used for providing cross-domain token and method thereof
CN112491881A (en) Cross-platform single sign-on method, system, electronic equipment and storage medium
EP2544397B1 (en) Method and communication device for accessing to devices in security
CN112491776B (en) Security authentication method and related equipment
CN106230594B (en) Method for user authentication based on dynamic password
JP2009032070A (en) Authentication system and authentication method
CN114301617A (en) Identity authentication method and device for multi-cloud application gateway, computer equipment and medium
JP2008539482A (en) Method, system, and program product for connecting client to network
CN113872992A (en) Method for realizing strong security authentication of remote Web access in BMC system
US10425395B2 (en) Single sign on system for secure networks
CN109587098A (en) A kind of Verification System and method, authorization server
CN104767728A (en) Identity authentication method and system based on home-based elderly care

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13765330

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13765330

Country of ref document: EP

Kind code of ref document: A1