US20050050317A1 - A system and method of exploiting the security of a secure communication channel to secure a non-secure communication channel - Google Patents

Abstract

The present invention features a system and method for establishing a secure communication channel between a client and an application server. In one embodiment, a ticket service generates a ticket having an identifier and a session key. A communications device obtains the ticket from the ticket service and transmits the ticket to a client over a secure communication channel. The client transmits the identifier of the ticket to an application server over an application communication channel. The application server then obtains a copy of the session key of the ticket from the ticket service. Communications exchanged between the client and the application server over the application communication channel are then encrypted using the session key to establish the application communication channel as a secure communication channel.

Description

CROSS REFERENCE TO RELATED APPLICATIONS
• This Application is a Continuation of application Ser. No. 09/706117 filed on Nov. 3, 2000.
FIELD OF THE INVENTION
• The invention relates generally to client-server computer networks. More specifically, the invention relates to a system and method for securely accessing software applications using a remote display protocol.
BACKGROUND OF THE INVENTION
• Software applications that are requested to be remotely displayed on a client computer, or client, are commonly accessed with a graphical or windowing terminal session. When a user requests an application on a client computer, the application executes on a server and typically the input information (e.g., mouse and keyboard information) and display information are transmitted from the server computer to the client computer. Graphical or windowing terminal sessions often make use of unauthenticated connections between the client and the server. Alternatively, the graphical or windowing terminal session may authenticate the connection between the client and the server with the user supplying his password to the server.
• The aforementioned techniques employed by the terminal sessions have various shortcomings. For example, transmitting information, such as password information, to an unauthenticated server allows the information to be viewed by a server that is not trusted by the client. The non-secure connection permits an eavesdropper to intercept a user's password for future use.
• To avoid these problems, the client and server are typically authenticated using conventional cryptographic techniques. One type of cryptographic technique used by networks is a ticket-based authentication scheme. Most current ticket-based authentication schemes transmit a ticket. The ticket, which can typically be used only one time, may contain an encryption key to be used in future communications and/or may contain a secret password to support the future communications. When the client and the server both have the encryption key, they can communicate securely.
• However, the current ticket-based authentication schemes are limited in several areas. First, the ticket is typically transmitted to the client over a non-secure communication channel, thereby allowing an eavesdropper to intercept the ticket and retrieve the encryption key. Using the encryption key, the eavesdropper can pose as the server to the client or as the client to the server. Second, the current schemes do not take advantage of secure web pages. For example, current ticket-based authentication schemes make transactions over the internet, such as purchases, unsafe because proprietary information, such as a purchaser's credit card information, can be transmitted to a non-secure web page. Third, software applications executing on a server are commonly transmitted over a nonsecure communication channel for display on a remote display protocol on a client machine. For instance, networks may consist of specialized application servers (e.g., Metaframe for Windows, manufactured by Citrix Systems, Inc. of Ft. Lauderdale, Fla.), to execute specific applications which are typically transmitted to a remote display service over a non-secure communication channel. Fourth, although the ticket can typically be used only one time (i.e., making it a “one-time use” ticket) and having no further value after its first use, the one-time use ticket does not protect the user's password (which is used for login into an operating system or an application) from an eavesdropper on the ticket's first transmission. Therefore, the user's password is still not completely protected from interception and the server is consequently not authenticated to the client.
SUMMARY OF THE INVENTION
• The present invention features a system and method for establishing a secure communication channel between a client and an application server. A ticket service generates a ticket having an identifier and a session key. A communications device obtains the ticket from the ticket service and transmits the ticket to a client over a secure communication channel. The client transmits the identifier of the ticket to an application server over an application communication channel. The application server then obtains a copy of the session key of the ticket from the ticket service. Communications exchanged between the client and the application server over the application communication channel are then encrypted using the session key to establish the application communication channel as a secure communication channel.
• In one embodiment, a web browser executing on a client establishes communications with a web server over a secure web communication channel. The client receives a ticket having an identifier and a session key from the web server over the secure web communication channel. The client then transmits the identifier of the ticket to the application server over the application communication channel to provide the application server with information for obtaining a copy of the session key.
• In one aspect, the invention relates to a method for establishing a secure communication channel between a client and an application server. The client receives a ticket having an identifier and a session key from a web server over a secure web communication channel. The client then transmits the identifier of the ticket to the application server over an application communication channel to provide the application server with information for obtaining a copy of the session key. The client establishes a secure communication channel over the application communication channel by using the session key to encrypt and decrypt communications to and from the application server. The identifier is a nonce. In one embodiment, the client and the web server use secure socket layer technology to establish the secure web communication channel.
• In another aspect, the invention relates to a communications system that establishes a secure communication channel. The communications system includes a client, an application server, a communications device, and a ticket service. The ticket service generates a ticket having an identifier and a session key. The communications device is in communication with the ticket service to obtain the ticket. The client is in communication with the communications device over a secure communication channel to receive the ticket from the communications device. The application server is in communication with the client over an application communication channel to receive the identifier of the ticket from the client and in communication with the ticket service to obtain a copy of the session key from the ticket service. The application server and the client exchange communications over the application communication channel as a secure communication channel. In one embodiment, the ticket service resides on the communications device. In one embodiment, the communications device is a web server.
DESCRIPTION OF THE DRAWINGS
• FIG. 1 shows a block diagram of an embodiment of acommunication system100 including aclient10 in communication with anapplication server15 over anapplication communication channel25 and in communication with acommunications device20 over acommunication channel30. Thecommunication channel30 and theapplication communication channel25 pass through anetwork27. In other embodiments, thecommunication channel30 and theapplication channel25 pass through other, different networks. For example, thecommunication channel30 can pass through a first network (e.g., the World Wide Web) and theapplication communication channel30 can pass through a second network (e.g., a direct dial-up modem connection). Thecommunication channel30 is a secure communication channel in that communications are encrypted. Theapplication server15 is additionally in communication with thecommunications device20 over aserver communication channel35. Theapplication server15 and thecommunications device20 are part of aserver network33. By exploiting the security of the secure communications between theclient10 and thecommunications device20 over thesecure communication channel30, thecommunication system100 establishes a secure communication link over the non-secureapplication communication channel25 to remotely display desktop applications securely on theclient10.
• Thenetwork27 and theserver network33 can be a local-area network (LAN) or a wide area network (WAN), or a network of networks such as the Internet or the World Wide Web (i.e., web). Thecommunication channel30 can be any secure communication channel. In one embodiment, the communication channel30 (hereafter web communication channel30) supports communications over the web. In one embodiment, theserver network33 is a protected network that is inaccessible by the public. Theserver communication channel35 traverses theserver network33 and therefore can be a non-secure communication channel. Example embodiments of thecommunication channels25,30,35 include standard telephone lines, LAN or WAN links (e.g., T1, T3, 56 kb, X.25), broadband connections (ISDN, Frame Relay, ATM), and wireless connections. The connections over thecommunication channels25,30,35 can be established using a variety of communication protocols (e.g., HTTP, TCP/IP, IPX, SPX, Net-BIOS, Ethernet, RS232, and direct asynchronous connections).
• Theclient10 can be any personal computer (e.g., 286, 386, 486, Pentium, Pentium II, Macintosh computer), Windows-based terminal, Network Computer, wireless device (e.g., cellular phone), information appliance, RISC Power PC, X-device, workstation, mini computer, main frame computer, personal digital assistant, or other communications device that is capable of communicating over the secureweb communication channel30. In one embodiment, theclient10 operates according to a server-based computing model. In a server-based computing model, the execution of application programs occurs entirely on theapplication server15 and the user interface, keystrokes, and mouse movements are transmitted over theapplication communication channel25 to theclient10. The user interface can be text driven (e.g., DOS) or graphically driven (e.g., Windows). Platforms that can be supported by theclient10 include DOS and Windows CE for windows-based terminals.
• In one embodiment, theclient10 includes aweb browser40, such as Internet Explorer™ developed by Microsoft Corporation in Redmond, Wash., to connect to the web. In a further embodiment, theweb browser40 uses the existing Secure Socket Layer (SSL) support, developed by Netscape in Mountain View, Calif., to establish the secureweb communication channel30 to communications devices such as thecommunications device20. Theweb browser40 also has a user interface that may be text driven or graphically driven. The output of an application executing on theapplication server15 can be displayed at theclient10 via the user interface of theclient10 or the user interface of theweb browser40. Additionally, theclient10 includes anapplication client41 for establishing and exchanging communications with theapplication server15 over theapplication communication channel25. In one embodiment, theapplication client41 is the Independent Computing Architecture (ICA) client, developed by Citrix Systems, Inc. of Fort Lauderdale, Fla., and is hereafter referred to asICA client41. Other embodiments of theapplication client41 include the Remote Display Protocol (RDP), developed by Microsoft Corporation of Redmond, Wash., X-Windows, developed by Massachusetts Institute of Technology of Cambridge, Mass., a data entry client in a traditional client/server application, and a Java applet.
• Theapplication server15 hosts one or more application programs that can be accessed by theclient10. Applications made available to theclient10 for use are referred to as published applications. Examples of such applications include word processing programs such as MICROSOFT WORD® and spreadsheet programs such as MICROSOFT EXCEL®, both manufactured by Microsoft Corporation of Redmond, Wash., financial reporting programs, customer registration programs, programs providing technical support information, customer database applications, or application set managers. In another embodiment, theapplication server15 is a member of a server farm (not shown). A server farm is a logical group of one or more servers that are administered as a single entity.
• In one embodiment, the communications device20 (hereafter web server20) is a computer that delivers web pages to theclient10. In other embodiments, thecommunications device20 can be any personal computer (e.g., 286, 386, 486, Pentium, Pentium II, Macintosh computer), Windows-based terminal, Network Computer, wireless device (e.g., cellular phone), information appliance, RISC Power PC, X-device, workstation, mini computer, main frame computer, personal digital assistant, or other communications device that is capable of establishing the secureweb communication channel30 with theclient10.
• In one embodiment, theweb server20 also includes aticket service60. Theticket service60 controls communication security. Theticket service60 generates a ticket containing an encryption key. The ticket is transmitted to the client10 (i.e., the web browser40) over the secureweb communication channel30. The transmission of the ticket to theclient10 over the secureweb communication channel30 facilitates the establishment of secure communications over theapplication communication channel25 between theclient10 and theapplication server15 in accordance with the principles of the invention. In another embodiment, theticket service60′ resides on anotherserver20′. Theserver20′ (andticket service60′) is in communication with theweb server20 and theapplication server15 over aserver communication channel35′. In yet another embodiment, theticket service60 is a separate component (not shown) of theserver network33. Theweb browser40 then sends the ticket to theICA client41. A technique often used to transmit application data from applications executing on theapplication server15 over a secure connection to theclient10 is to transmit the application data to theclient10 through theweb server20 over the secure connection between theclient10 and theweb server20. This technique is inefficient in that communication between theapplication server15 and theclient10 takes an additional “hop”; namely theweb server20. The present invention uses the ticketing mechanism to establish a secure communication link directly between theapplication server15 and theclient10, thereby eliminating the intermediate transmission of application data from theapplication server15 to theweb server20.
• A client user requesting an application or server desktop, for example, to be remotely displayed on theclient10 first establishes acommunication link32 with theweb server20 over theweb communication channel30 and passes login and password information to theweb server20. In one embodiment, the client user uses theweb browser40 to request an application from theweb server20 that is listed on a web page displayed by theweb browser40.
• In a further embodiment, theweb browser40 uses SSL to establish the secureweb communication channel30. To use the SSL protocol to establish the secureweb communication channel30, theweb browser40 or an application executing on theclient10 attempts to connect to a secure web page on theweb server20. Theweb server20 then asserts the web server's identity to theclient10 by transmitting a secure web server certificate to theclient10. A certification authority (CA) issues the secure web server certificate to theweb server20.Web browsers40 have a list of trusted CAs (i.e., public key of the CA) embedded within the software of theweb browser40. Theclient10 verifies the web server certificate by decrypting the signature of the CA in the web server's certificate with the public key of the CA embedded in the web browser40 (or application). Therefore, in order to establish a secure communication channel using SSL, theweb browser40 or the application executing on theclient10 has the public key of the CA embedded in the software prior to attempting to connect to the secure web page. Besides using the SSL protocol to establish the secureweb communication channel30, theweb browser40 can connect to theweb server20 over theweb communication channel30 using other security protocols, such as, but not limited to, Secure Hypertext Transfer Protocol (SHTTP) developed by Terisa Systems of Los Altos, Calif., HTTP over SSL (HTTPS), Private Communication Technology (PCT) developed by Microsoft Corporation of Redmond, Wash., Secure Electronic Transfer (SET), developed by Visa International, Incorporated and Mastercard International, Incorporated of Purchase, N.Y., Secure-MIME (S/MIME) developed by RSA Security of Bedford, Mass., and the like.
• Once thecommunication link32 is established, theweb server20 generates a ticket for the communication session. The ticket includes a first portion and a second portion. In one embodiment, the first portion, also referred to as a session identifier (ID) or nonce, is a cryptographic random number that can be used within a certain time period determined by theweb server20. The second portion is an encryption key, hereafter referred to as a session key. Theweb server20 stores the ticket in local memory and then transmits (arrow34) a copy of the ticket to theweb browser40 on theclient10.
• In one embodiment, the ticket includes additional information, such as the network address of theapplication server15. In another embodiment, theweb server20 independently transmits the address of theapplication server15 to theclient10. For example, if theclient10 requests an application by name from theweb server20, theweb server20 converts the application name into the network address of the application. Examples of the additional information included in the ticket are, but not limited to, the time that the ticket is valid, the screen size of the application when displayed on theclient10, the bandwidth limits of theweb communication channel30 and/or theapplication communication channel25, and billing information. As described more fully below, theweb server20 also associates the user's login information, such as the user's password, with the ticket stored in local memory for future retrieval by theapplication server15.
• TheICA client41 obtains the ticket from theweb browser40 and subsequently transmits (arrow42) the session ID (i.e., the first potion) of the ticket to theapplication server15. The session ID can be transmitted in encrypted or cleartext form. Theapplication server15 decrypts the session ID, if encrypted, and transmits (arrow44) a request to theweb server20 for a session key that corresponds to the session ID received from theclient10. Theweb server20 verifies the session ID, as described below, and sends (arrow48) the corresponding session key to theapplication server15 over theserver communication channel35.
• Both theapplication server15 and the client10 (i.e., the ICA client41) now possess a copy of the session key without requiring the transmission of the ticket or the session key over the non-secureapplication communication channel25. By using the session key to encrypt and decrypt the communications over the previously non-secureapplication communication channel25, theclient10 and theapplication server25 establish (arrow50) asecure communication link50 over theapplication communication channel25. Moreover, the user's login information (e.g., password) is not transmitted between theclient10 and theapplication server15 over the non-secureapplication communication channel25. Therefore, the present invention strengthens (arrow50) the security of thecommunication link50 over the non-secureapplication communication channel25 by not exposing sensitive information, such as the user's password, to eavesdroppers intercepting communications over the non-secureapplication communication channel25. Additionally, because theapplication server15 and theclient10 communicate with the same session key, they share a secret that was transmitted by theticket service60. Theticket service60 indirectly authenticates theapplication server15 and theclient10, and theticket service60 is vouching for each. Therefore, theauthentication server15 and theclient10 perform mutual authentication. In one embodiment, theclient10 again transmits the user's password over theweb communication channel30 to theweb server20 to provide compatibility with legacy systems (e.g., an unmodified operating system login sequence on theweb server20 that requires theclient10 to transmit the user's password multiple times).
• In more detail,FIG. 2 shows embodiments of a process performed by thecommunications system100 to establish asecure communication link50 over theapplication communication channel25 between theclient10 and theapplication server15. Theweb browser40 lists (step200) web links to software applications or server desktops on the web page that the user of theclient10 views. The client user, using theweb browser40, requests (step205) a software application from theweb server20. In one embodiment, theweb browser40 establishes the secureweb communication channel30 using the previously described SSL protocol. In this embodiment, the client10 (e.g., the web browser40) authenticates theweb server20 using a public key (e.g., X509) certificate. In a further embodiment, theclient10 is also authenticated to theweb server20 using a public key certificate.
• In another embodiment, theweb server20 authenticates the user when the user uses theweb browser40 to request an application from theweb server20. For example, theweb server20 requests the user's login information, which includes the user's login name and password, with a request displayed on theweb browser40. The user provides (step210) the user's login information to theweb browser40. Theweb browser40 subsequently transmits (step220) the user's login name and password to theweb server20 over the secureweb communication channel30. In another embodiment, the user's login information is any code or method that theweb server20 accepts to identify the user's account on theweb server20.
• Theweb server20 transmits (step230) the user's login information to theticket service60. Theticket service60 verifies (step240) the user's login information and determines whether the user is entitled to access the requested application. Depending on the declared communication security policy for that application, theticket service60 either refuses or grants access to the application by the user. If theticket service60 denies access, theweb browser40 displays an HTML error or an error web page on theclient10. When theticket service60 grants access to the requested application, theticket service60 generates (step245) a ticket for the session and transmits (step250) the ticket to theweb server20.
• As described above, the ticket includes a session ID and a session key. The session ID can be used once within a certain time period and makes the ticket a “one-time use” ticket having no further value after its first use. Theweb server20 then stores (step253) the ticket in local memory. In a further embodiment, theweb server20 associates the login information provided by the user instep210 and other security information used to authorize the session, such as the requested application name, with the stored ticket for later retrieval by theapplication server15. Theweb server20 subsequently transmits (step255) the ticket to theclient10 over the secureweb communication channel30.
• Theweb browser40 extracts (step260) the session ID from the ticket and presents (step265) the session ID to theapplication server15. Theapplication server15 checks the session ID to ensure that the session ID has not been used previously with thisclient10. In one embodiment, theapplication server15 monitors (e.g., stores in local memory) each ticket (i.e., session ID) that theclient10 transmits to theapplication server15. In another embodiment, theticket service60 checks the session ID to ensure that the session ID has not been used previously with thisclient10. In yet another embodiment, the ticket service monitors each ticket that theticket service60 transmits to theweb server20 to ensure that each session ID is transmitted to theticket service60 only once.
• Theapplication server15 then uses the session ID to determine the session key associated with the presented session ID. To accomplish this, theapplication server15 transmits the session ID to theticket service60 and requests (step270) the session key from theticket service60 of theweb server20 in response to the session ID. Theticket service60 accesses local memory and uses the session ID as an index to retrieve the ticket information associated with the session ID. Theticket service60 then returns (step280) the session key associated with the session ID to theapplication server15.
• To increase optimization of the communications between theapplication server15 and theweb server20, in an alternate embodiment theweb server20 transmits (shown as phantom step266) to theapplication server15 additional information (e.g., the requested application name, the user's login information) that was previously associated with the ticket instep253. Theapplication server15 retrieves (phantom step267) the additional ticket information and authorizes the communication session from this additional information. This additional information, such as the user's password and/or the name of the requested application, was not transmitted to theapplication server15 by theclient10 over the non-secureapplication communication channel25, thereby protecting the information from potential attackers. In this embodiment, theapplication server15 verifies (phantom step268) the additional information. If the additional information is not valid, theapplication server15 refuses (phantom step269) access to the requested application by the user. If the additional information is valid, theapplication server15 grants access to the requested application and, as described above, requests (step270) the session key from theticket service60.
• In another embodiment, theticket service60 performs additional checks on the session ID. For example, theticket service60 performs checks on the session ID for early detection of replay (i.e., checking that the session ID has not been previously transmitted to the ticket service60) and/or Denial of Service (DoS) attacks (i.e., flooding and eventually disabling a remote server with illegitimate packets of data). In yet another embodiment, theweb server20 transmits the first and second portion of the ticket to theapplication server15 before theapplication server15 requests it (step270), thus eliminating the request instep270. In this embodiment, theapplication server15 stores the session key in its local memory and retrieves from its local memory the session key after theclient10 presents (step265) the session ID to theapplication server15.
• After theapplication server15 obtains (step280) the session key, theapplication server15 uses the session key to encrypt communications to theclient10 and to decrypt communications from theclient10 over theapplication communication channel25. Similarly, theclient10 uses the session key that theclient10 obtained from the ticket transmitted over the secureweb communication channel30 to decrypt communications from theapplication server15 and to encrypt communications to theapplication server15. Because theclient10 and theapplication server15 use the session key to encrypt and decrypt communications over theapplication communication channel25, theclient10 and theapplication server15 establish (step290) thesecure communication link50 over the previously non-secureapplication communication channel25. Moreover, because theclient10 and theapplication server15 have the session key without transmitting the ticket over the non-secure application communication channel25 (and thus potentially revealing the session key to third parties), theclient10 and theapplication server15 strengthen the security of thecommunication link50 over the previously non-secureapplication communication channel25.
• In one embodiment, the application communication channel is made secure using the SSL protocol. In this embodiment, theticket service60 substitutes an application server certificate for the session key in the ticket. Theclient10 uses the application server certificate to communicate with theapplication server15. The application server certificate is downloaded to theclient10 over theweb communication channel30 in response to a request for the ticket. Therefore, because the application server certificate is downloaded to theclient10 over a secure link (i.e., the web communication channel30), the application server certificate does not need to be signed by a well-known public CA. Although theclient10 did not have the application server's certificate or the CA key in advance, an authenticated secure connection is established over theapplication communication channel25 using the application server certificate included in the ticket.
• For example, if theclient10 requests another SSL component (e.g., a separate instance or implementation of the requested software application) and theclient10 does not have the CA certificate in its local memory (e.g., database, local disk, RAM, ROM), theclient10 can use the application server certificate transmitted in the ticket to establish an authenticated secure connection over theapplication communication channel25. More specifically, theclient10 uses the application server certificate transmitted in the ticket when theclient10 does not have a CA root certificate stored in its local memory that is associated with the requested SSL component (or when theclient10 has an incomplete list of CA certificates that does not include a CA certificate for the requested SSL component) and theclient10 cannot access the CA database of theweb browser40. Furthermore, because a signed CA certificate is needed for theweb server20 but is not needed for an application server15 (i.e., eachapplication server15 that is a member of a server farm), the costs (and overhead) of obtaining the required number of signed CA certificates for secure communication is reduced. In another embodiment, theapplication server15 stores a private key for decryption of messages that are encrypted with a corresponding public key. Theticket service60 consequently transmits the corresponding public key of theapplication server15 to theclient10 to encrypt communications.
• In this embodiment, the session ID still provides additional value, in that it ensures that theclient10 can gain access to the requested application and can gain access one time because ticket service60 (or web server20) monitors the ticket (i.e., the session ID). Furthermore, if theapplication server15 and theclient10 use different session keys to encrypt and decrypt communications over theapplication communication channel25, an eavesdropper cannot modify the session ID transmitted by theclient10 to theapplication server15 because the session ID and the cryptographic checksum do not match the checksum expected by the application server15 (i.e., integrity check). Therefore, theclient10 and theapplication server15 determine when different session keys are used (e.g., “man-in-the-middle” attack) by theapplication server15 and theclient10 to encrypt and decrypt communications over theapplication communication channel25.
• In a further embodiment, the session key is substantially equivalent to a null value (i.e., the ticket contains only a nonce or a nonce and a constant value for the session key). When the session key is substantially equivalent to a null value, theclient10 does not transmit the user's login information (e.g., password) between theclient10 and theapplication server15 over the non-secureapplication communication channel25. Therefore, because the ticket is only valid for a single use and only grants access to a previously authorized resource (e.g., the ICA client41), the external password exposure can be avoided and individual session level access control can be achieved, even with a null or fixed session key value.
• Additionally, because no information is pre-configured into theweb browser40 or theclient10 in order to remotely display the requested application (i.e., because theclient10 does not need to be populated with a server certificate or a CA certificate), the present method is a “zero-install” solution for secure access to desktop applications over the web. Further, theweb browser40 receives the ticket and theICA client41 from theweb server20 over thecommunication channel30. In this embodiment, theweb server20 transmits the ticket and a MIME type document, as described above, specifying that the data includes a “document” for the ICA client41 (as a helper application). The MIME type document invokes theICA client41 and theweb browser40 transfers the ticket to theICA client41, thus allowing the exploitation of the security of thecommunication channel30 to secure theapplication communication channel25 without having theICA client41 pre-installed on theclient10. Having described certain embodiments of the invention, it will now become apparent to one of skill in the art that other embodiments incorporating the concepts of the invention may be used. Therefore, the invention should not be limited to certain embodiments, but rather should be limited only by the spirit and scope of the following claims.
DETAILED DESCRIPTION OF THE INVENTION
• FIG. 1 shows a block diagram of an embodiment of acommunication system100 including aclient10 in communication with anapplication server15 over anapplication communication channel25 and in communication with acommunications device20 over acommunication channel30. Thecommunication channel30 and theapplication communication channel25 pass through anetwork27. In other embodiments, thecommunication channel30 and theapplication channel25 pass through other, different networks. For example, thecommunication channel30 can pass through a first network (e.g., the World Wide Web) and theapplication communication channel30 can pass through a second network (e.g., a direct dial-up modem connection). Thecommunication channel30 is a secure communication channel in that communications are encrypted. Theapplication server15 is additionally in communication with thecommunications device20 over aserver communication channel35. Theapplication server15 and thecommunications device20 are part of aserver network33. By exploiting the security of the secure communications between theclient10 and thecommunications device20 over thesecure communication channel30, thecommunication system100 establishes a secure communication link over the non-secureapplication communication channel25 to remotely display desktop applications securely on theclient10.
• Thenetwork27 and theserver network33 can be a local-area network (LAN) or a wide area network (WAN), or a network of networks such as the Internet or the World Wide Web (i.e., web). Thecommunication channel30 can be any secure communication channel. In one embodiment, the communication channel30 (hereafter web communication channel30) supports communications over the web. In one embodiment, theserver network33 is a protected network that is inaccessible by the public. Theserver communication channel35 traverses theserver network33 and therefore can be a non-secure communication channel. Example embodiments of thecommunication channels25,30,35 include standard telephone lines, LAN or WAN links (e.g., T1, T3, 56 kb, X.25), broadband connections (ISDN, Frame Relay, ATM), and wireless connections. The connections over thecommunication channels25,30,35 can be established using a variety of communication protocols (e.g., HTTP, TCP/IP, IPX, SPX, Net-BIOS, Ethernet, RS232, and direct asynchronous connections).
• Theclient10 can be any personal computer (e.g., 286, 386, 486, Pentium, Pentium II, Macintosh computer), Windows-based terminal, Network Computer, wireless device (e.g., cellular phone), information appliance, RISC Power PC, X-device, workstation, mini computer, main frame computer, personal digital assistant, or other communications device that is capable of communicating over the secureweb communication channel30. In one embodiment, theclient10 operates according to a server-based computing model. In a server-based computing model, the execution of application programs occurs entirely on theapplication server15 and the user interface, keystrokes, and mouse movements are transmitted over theapplication communication channel25 to theclient10. The user interface can be text driven (e.g., DOS) or graphically driven (e.g., Windows). Platforms that can be supported by theclient10 include DOS and Windows CE for windows-based terminals.
• In one embodiment, theclient10 includes aweb browser40, such as Internet Explorer™ developed by Microsoft Corporation in Redmond, Wash., to connect to the web. In a further embodiment, theweb browser40 uses the existing Secure Socket Layer (SSL) support, developed by Netscape in Mountain View, Calif., to establish the secureweb communication channel30 to communications devices such as thecommunications device20. Theweb browser40 also has a user interface that may be text driven or graphically driven. The output of an application executing on theapplication server15 can be displayed at theclient10 via the user interface of theclient10 or the user interface of theweb browser40. Additionally, theclient10 includes anapplication client41 for establishing and exchanging communications with theapplication server15 over theapplication communication channel25. In one embodiment, theapplication client41 is the Independent Computing Architecture (ICA) client, developed by Citrix Systems, Inc. of Fort Lauderdale, Fla., and is hereafter referred to asICA client41. Other embodiments of theapplication client41 include the Remote Display Protocol (RDP), developed by Microsoft Corporation of Redmond, Wash., X-Windows, developed by Massachusetts Institute of Technology of Cambridge, Mass., a data entry client in a traditional client/server application, and a Java applet.
• Theapplication server15 hosts one or more application programs that can be accessed by theclient10. Applications made available to theclient10 for use are referred to as published applications. Examples of such applications include word processing programs such as MICROSOFT WORD® and spreadsheet programs such as MICROSOFT EXCEL®, both manufactured by Microsoft Corporation of Redmond, Wash., financial reporting programs, customer registration programs, programs providing technical support information, customer database applications, or application set managers. In another embodiment, theapplication server15 is a member of a server farm (not shown). A server farm is a logical group of one or more servers that are administered as a single entity.
• In one embodiment, the communications device20 (hereafter web server20) is a computer that delivers web pages to theclient10. In other embodiments, thecommunications device20 can be any personal computer (e.g., 286, 386, 486, Pentium, Pentium II, Macintosh computer), Windows-based terminal, Network Computer, wireless device (e.g., cellular phone), information appliance, RISC Power PC, X-device, workstation, mini computer, main frame computer, personal digital assistant, or other communications device that is capable of establishing the secureweb communication channel30 with theclient10.
• In one embodiment, theweb server20 also includes aticket service60. Theticket service60 controls communication security. Theticket service60 generates a ticket containing an encryption key. The ticket is transmitted to the client10 (i.e., the web browser40) over the secureweb communication channel30. The transmission of the ticket to theclient10 over the secureweb communication channel30 facilitates the establishment of secure communications over theapplication communication channel25 between theclient10 and theapplication server15 in accordance with the principles of the invention. In another embodiment, theticket service60′ resides on anotherserver20′. Theserver20′ (andticket service60′) is in communication with theweb server20 and theapplication server15 over aserver communication channel35′. In yet another embodiment, theticket service60 is a separate component (not shown) of theserver network33. Theweb browser40 then sends the ticket to theICA client41. A technique often used to transmit application data from applications executing on theapplication server15 over a secure connection to theclient10 is to transmit the application data to theclient10 through theweb server20 over the secure connection between theclient10 and theweb server20. This technique is inefficient in that communication between theapplication server15 and theclient10 takes an additional “hop”; namely theweb server20. The present invention uses the ticketing mechanism to establish a secure communication link directly between theapplication server15 and theclient10, thereby eliminating the intermediate transmission of application data from theapplication server15 to theweb server20.
• A client user requesting an application or server desktop, for example, to be remotely displayed on theclient10 first establishes acommunication link32 with theweb server20 over theweb communication channel30 and passes login and password information to theweb server20. In one embodiment, the client user uses theweb browser40 to request an application from theweb server20 that is listed on a web page displayed by theweb browser40.
• In a further embodiment, theweb browser40 uses SSL to establish the secureweb communication channel30. To use the SSL protocol to establish the secureweb communication channel30, theweb browser40 or an application executing on theclient10 attempts to connect to a secure web page on theweb server20. Theweb server20 then asserts the web server's identity to theclient10 by transmitting a secure web server certificate to theclient10. A certification authority (CA) issues the secure web server certificate to theweb server20.Web browsers40 have a list of trusted CAs (i.e., public key of the CA) embedded within the software of theweb browser40. Theclient10 verifies the web server certificate by decrypting the signature of the CA in the web server's certificate with the public key of the CA embedded in the web browser40 (or application). Therefore, in order to establish a secure communication channel using SSL, theweb browser40 or the application executing on theclient10 has the public key of the CA embedded in the software prior to attempting to connect to the secure web page. Besides using the SSL protocol to establish the secureweb communication channel30, theweb browser40 can connect to theweb server20 over theweb communication channel30 using other security protocols, such as, but not limited to, Secure Hypertext Transfer Protocol (SHTTP) developed by Terisa Systems of Los Altos, CA, HTTP over SSL (HTTPS), Private Communication Technology (PCT) developed by Microsoft Corporation of Redmond, Wash., Secure Electronic Transfer (SET), developed by Visa International, Incorporated and Mastercard International, Incorporated of Purchase, N.Y., Secure-MIME (S/MIME) developed by RSA Security of Bedford, Mass., and the like.
• Once thecommunication link32 is established, theweb server20 generates a ticket for the communication session. The ticket includes a first portion and a second portion. In one embodiment, the first portion, also referred to as a session identifier (ID) or nonce, is a cryptographic random number that can be used within a certain time period determined by theweb server20. The second portion is an encryption key, hereafter referred to as a session key. Theweb server20 stores the ticket in local memory and then transmits (arrow34) a copy of the ticket to theweb browser40 on theclient10.
• In one embodiment, the ticket includes additional information, such as the network address of theapplication server15. In another embodiment, theweb server20 independently transmits the address of theapplication server15 to theclient10. For example, if theclient10 requests an application by name from theweb server20, theweb server20 converts the application name into the network address of the application. Examples of the additional information included in the ticket are, but not limited to, the time that the ticket is valid, the screen size of the application when displayed on theclient10, the bandwidth limits of theweb communication channel30 and/or theapplication communication channel25, and billing information. As described more fully below, theweb server20 also associates the user's login information, such as the user's password, with the ticket stored in local memory for future retrieval by theapplication server15.
• TheICA client41 obtains the ticket from theweb browser40 and subsequently transmits (arrow42) the session ID (i.e., the first potion) of the ticket to theapplication server15. The session ID can be transmitted in encrypted or cleartext form. Theapplication server15 decrypts the session ID, if encrypted, and transmits (arrow44) a request to theweb server20 for a session key that corresponds to the session ID received from theclient10. Theweb server20 verifies the session ID, as described below, and sends (arrow48) the corresponding session key to theapplication server15 over theserver communication channel35.
• Both theapplication server15 and the client10 (i.e., the ICA client41) now possess a copy of the session key without requiring the transmission of the ticket or the session key over the non-secureapplication communication channel25. By using the session key to encrypt and decrypt the communications over the previously non-secureapplication communication channel25, theclient10 and theapplication server25 establish (arrow50) asecure communication link50 over theapplication communication channel25. Moreover, the user's login information (e.g., password) is not transmitted between theclient10 and theapplication server15 over the non-secureapplication communication channel25. Therefore, the present invention strengthens (arrow50) the security of thecommunication link50 over the non-secureapplication communication channel25 by not exposing sensitive information, such as the user's password, to eavesdroppers intercepting communications over the non-secureapplication communication channel25. Additionally, because theapplication server15 and theclient10 communicate with the same session key, they share a secret that was transmitted by theticket service60. Theticket service60 indirectly authenticates theapplication server15 and theclient10, and theticket service60 is vouching for each. Therefore, theauthentication server15 and theclient10 perform mutual authentication. In one embodiment, theclient10 again transmits the user's password over theweb communication channel30 to theweb server20 to provide compatibility with legacy systems (e.g., an unmodified operating system login sequence on theweb server20 that requires theclient10 to transmit the user's password multiple times).
• In more detail,FIG. 2 shows embodiments of a process performed by thecommunications system100 to establish asecure communication link50 over theapplication communication channel25 between theclient10 and theapplication server15. Theweb browser40 lists (step200) web links to software applications or server desktops on the web page that the user of theclient10 views. The client user, using theweb browser40, requests (step205) a software application from theweb server20. In one embodiment, theweb browser40 establishes the secureweb communication channel30 using the previously described SSL protocol. In this embodiment, the client10 (e.g., the web browser40) authenticates theweb server20 using a public key (e.g., X509) certificate. In a further embodiment, theclient10 is also authenticated to theweb server20 using a public key certificate.
• In another embodiment, theweb server20 authenticates the user when the user uses theweb browser40 to request an application from theweb server20. For example, theweb server20 requests the user's login information, which includes the user's login name and password, with a request displayed on theweb browser40. The user provides (step210) the user's login information to theweb browser40. Theweb browser40 subsequently transmits (step220) the user's login name and password to theweb server20 over the secureweb communication channel30. In another embodiment, the user's login information is any code or method that theweb server20 accepts to identify the user's account on theweb server20.
• Theweb server20 transmits (step230) the user's login information to theticket service60. Theticket service60 verifies (step240) the user's login information and determines whether the user is entitled to access the requested application. Depending on the declared communication security policy for that application, theticket service60 either refuses or grants access to the application by the user. If theticket service60 denies access, theweb browser40 displays an HTML error or an error web page on theclient10. When theticket service60 grants access to the requested application, theticket service60 generates (step245) a ticket for the session and transmits (step250) the ticket to theweb server20.
• As described above, the ticket includes a session ID and a session key. The session ID can be used once within a certain time period and makes the ticket a “one-time use” ticket having no further value after its first use. Theweb server20 then stores (step253) the ticket in local memory. In a further embodiment, theweb server20 associates the login information provided by the user instep210 and other security information used to authorize the session, such as the requested application name, with the stored ticket for later retrieval by theapplication server15. Theweb server20 subsequently transmits (step255) the ticket to theclient10 over the secureweb communication channel30.
• Theweb browser40 extracts (step260) the session ID from the ticket and presents (step265) the session ID to theapplication server15. Theapplication server15 checks the session ID to ensure that the session ID has not been used previously with thisclient10. In one embodiment, theapplication server15 monitors (e.g., stores in local memory) each ticket (i.e., session ID) that theclient10 transmits to theapplication server15. In another embodiment, theticket service60 checks the session ID to ensure that the session ID has not been used previously with thisclient10. In yet another embodiment, the ticket service monitors each ticket that theticket service60 transmits to theweb server20 to ensure that each session ID is transmitted to theticket service60 only once.
• Theapplication server15 then uses the session ID to determine the session key associated with the presented session ID. To accomplish this, theapplication server15 transmits the session ID to theticket service60 and requests (step270) the session key from theticket service60 of theweb server20 in response to the session ID. Theticket service60 accesses local memory and uses the session ID as an index to retrieve the ticket information associated with the session ID. Theticket service60 then returns (step280) the session key associated with the session ID to theapplication server15.
• To increase optimization of the communications between theapplication server15 and theweb server20, in an alternate embodiment theweb server20 transmits (shown as phantom step266) to theapplication server15 additional information (e.g., the requested application name, the user's login information) that was previously associated with the ticket instep253. Theapplication server15 retrieves (phantom step267) the additional ticket information and authorizes the communication session from this additional information. This additional information, such as the user's password and/or the name of the requested application, was not transmitted to theapplication server15 by theclient10 over the non-secureapplication communication channel25, thereby protecting the information from potential attackers. In this embodiment, theapplication server15 verifies (phantom step268) the additional information. If the additional information is not valid, theapplication server15 refuses (phantom step269) access to the requested application by the user. If the additional information is valid, theapplication server15 grants access to the requested application and, as described above, requests (step270) the session key from theticket service60.
• In another embodiment, theticket service60 performs additional checks on the session ID. For example, theticket service60 performs checks on the session ID for early detection of replay (i.e., checking that the session ID has not been previously transmitted to the ticket service60) and/or Denial of Service (DoS) attacks (i.e., flooding and eventually disabling a remote server with illegitimate packets of data). In yet another embodiment, theweb server20 transmits the first and second portion of the ticket to theapplication server15 before theapplication server15 requests it (step270), thus eliminating the request instep270. In this embodiment, theapplication server15 stores the session key in its local memory and retrieves from its local memory the session key after theclient10 presents (step265) the session ID to theapplication server15.
• After theapplication server15 obtains (step280) the session key, theapplication server15 uses the session key to encrypt communications to theclient10 and to decrypt communications from theclient10 over theapplication communication channel25. Similarly, theclient10 uses the session key that theclient10 obtained from the ticket transmitted over the secureweb communication channel30 to decrypt communications from theapplication server15 and to encrypt communications to theapplication server15. Because theclient10 and theapplication server15 use the session key to encrypt and decrypt communications over theapplication communication channel25, theclient10 and theapplication server15 establish (step290) thesecure communication link50 over the previously non-secureapplication communication channel25. Moreover, because theclient10 and theapplication server15 have the session key without transmitting the ticket over the non-secure application communication channel25 (and thus potentially revealing the session key to third parties), theclient10 and theapplication server15 strengthen the security of thecommunication link50 over the previously non-secureapplication communication channel25.
• In one embodiment, theapplication communication channel25 is made secure using the SSL protocol. In this embodiment, theticket service60 substitutes an application server certificate for the session key in the ticket. Theclient10 uses the application server certificate to communicate with theapplication server15. The application server certificate is downloaded to theclient10 over theweb communication channel30 in response to a request for the ticket. Therefore, because the application server certificate is downloaded to theclient10 over a secure link (i.e., the web communication channel30), the application server certificate does not need to be signed by a well-known public CA. Although theclient10 did not have the application server's certificate or the CA key in advance, an authenticated secure connection is established over theapplication communication channel25 using the application server certificate included in the ticket.
• For example, if theclient10 requests another SSL component (e.g., a separate instance or implementation of the requested software application) and theclient10 does not have the CA certificate in its local memory (e.g., database, local disk, RAM, ROM), theclient10 can use the application server certificate transmitted in the ticket to establish an authenticated secure connection over theapplication communication channel25. More specifically, theclient10 uses the application server certificate transmitted in the ticket when theclient10 does not have a CA root certificate stored in its local memory that is associated with the requested SSL component (or when theclient10 has an incomplete list of CA certificates that does not include a CA certificate for the requested SSL component) and theclient10 cannot access the CA database of theweb browser40. Furthermore, because a signed CA certificate is needed for theweb server20 but is not needed for an application server15 (i.e., eachapplication server15 that is a member of a server farm), the costs (and overhead) of obtaining the required number of signed CA certificates for secure communication is reduced. In another embodiment, theapplication server15 stores a private key for decryption of messages that are encrypted with a corresponding public key. Theticket service60 consequently transmits the corresponding public key of theapplication server15 to theclient10 to encrypt communications.
• In this embodiment, the session ID still provides additional value, in that it ensures that theclient10 can gain access to the requested application and can gain access one time because ticket service60 (or web server20) monitors the ticket (i.e., the session ID). Furthermore, if theapplication server15 and theclient10 use different session keys to encrypt and decrypt communications over theapplication communication channel25, an eavesdropper cannot modify the session ID transmitted by theclient10 to theapplication server15 because the session ID and the cryptographic checksum do not match the checksum expected by the application server15 (i.e., integrity check). Therefore, theclient10 and theapplication server15 determine when different session keys are used (e.g.,“man-in-the-middle” attack) by theapplication server15 and theclient10 to encrypt and decrypt communications over theapplication communication channel25.
• In a further embodiment, the session key is substantially equivalent to a null value (i.e., the ticket contains only a nonce or a nonce and a constant value for the session key). When the session key is substantially equivalent to a null value, theclient10 does not transmit the user's login information (e.g., password) between theclient10 and theapplication server15 over the non-secureapplication communication channel25. Therefore, because the ticket is only valid for a single use and only grants access to a previously authorized resource (e.g., the ICA client41), the external password exposure can be avoided and individual session level access control can be achieved, even with a null or fixed session key value.
• Additionally, because no information is pre-configured into theweb browser40 or theclient10 in order to remotely display the requested application (i.e., because theclient10 does not need to be populated with a server certificate or a CA certificate), the present method is a “zero-install” solution for secure access to desktop applications over the web. Further, theweb browser40 receives the ticket and theICA client41 from theweb server20 over thecommunication channel30. In this embodiment, theweb server20 transmits the ticket and a MIME type document, as described above, specifying that the data includes a “document” for the ICA client41 (as a helper application). The MIME type document invokes theICA client41 and theweb browser40 transfers the ticket to theICA client41, thus allowing the exploitation of the security of thecommunication channel30 to secure theapplication communication channel25 without having theICA client41 pre-installed on theclient10. Having described certain embodiments of the invention, it will now become apparent to one of skill in the art that other embodiments incorporating the concepts of the invention may be used. Therefore, the invention should not be limited to certain embodiments, but rather should be limited only by the spirit and scope of the following claims.

Claims (90)

1. A method for establishing a secure communication channel between a client and an application server, the method comprising the steps of:

(a) obtaining, by a web server, a MIME type document and a ticket associated with a client, the MIME type document comprising a client application program, the ticket having an identifier and a session key;

(b) receiving, by a web browser, the MIME type document and the ticket from the web server;

(c) invoking, by the web browser, the received client application program;

(d) establishing an application communication channel between the client and the application server;

(e) transmitting, by the client application program, the identifier from the ticket to the application server over the application communication channel;

(f) obtaining, by the application server, a copy of the session key from the web server using the identifier; and

(g) encrypting communications between the client application program and the application server over the application communication channel using the session key.

2. The method ofclaim 1 wherein step (a) further consists of establishing a secure web communication channel between the web browser and the web server.

3. The method ofclaim 1 wherein step (c) further consists of transferring, by the web browser, the ticket to the client application program.

4. The method ofclaim 1 wherein step (g) further comprises decrypting communications between the client application program and the application server using the session key.

5. The method ofclaim 1 wherein step (a) further comprises receiving, at the web server, a request from the client to have an application program executed on the application server and to have output from the application program executing on the application server transmitted to the client application program.

6. The method ofclaim 5 wherein step (g) further comprises executing, by the application server, the application program identified in the request, and transmitting, by the application server, the output of the application program over the application communication channel via a remote display protocol.

7. The method ofclaim 1 wherein step (a) further comprises obtaining a MIME type document having a remote display client for the client application program.

8. The method ofclaim 1 wherein step (c) further comprises installing the client application program for a first time on the client.

9. The method ofclaim 1 wherein step (a) further comprises obtaining a ticket having an application server certificate for the identifier.

10. The method ofclaim 1 wherein step (a) further comprises obtaining a ticket having a session key substantially equivalent to a null value.

11. The method ofclaim 1 wherein step (a) further comprises obtaining a ticket granting access for a single use.

12. The method ofclaim 1 wherein step (a) further comprises obtaining a ticket granting access to a previously authorized resource.

13. The method ofclaim 1 wherein step (e) further comprises transmitting a password to the application server.

14. The method ofclaim 1 wherein step (a) further comprises obtaining the MIME type document from the application server.

15. The method ofclaim 6 wherein step (g) further comprises using the Independent Computing Architecture protocol for the remote display protocol.

16. The method ofclaim 6 wherein step (g) further comprises using the Remote Display Protocol for the remote display protocol.

17. A client system for establishing a secure communication channel with an application server, the client system comprising:

a web browser associated with a client;

a web server in communication with the web browser over a web communication channel, the web server obtaining a MIME type document and a ticket associated with the client, the MIME type document comprising a client application program, the ticket having an identifier and a session key;

the web browser receiving, from the web server, the ticket and the MIME type document,

the web browser invoking the received client application program;

an application server, in communication with the client over an application communication channel, receiving the identifier from the client application program, and the application server, in communication with the web server, obtaining a copy of the session key by using the identifier; and

the application server and the client application program encrypting communications over the application communication channel using the session key.

18. The system ofclaim 17 wherein the web communication channel is secure.

19. The system ofclaim 17 wherein the web browser transfers the ticket to the client application program.

20. The system ofclaim 17 wherein the application server and the client application program decrypt communications over the application communication channel using the session key.

21. The system ofclaim 17 wherein the web server receives a request from the client to have an application program executed on the application server and to have output from the application program executing on the application server transmitted to the client application program.

22. The system ofclaim 21 wherein the application server executes the application program identified in the request, and transmits the output of the application program to the client application program over the application communication channel via a remote display protocol.

23. The system ofclaim 17 wherein the client application program is a remote display client.

24. The system ofclaim 17 wherein the client application program is installed for a first time on the client.

25. The system ofclaim 17 wherein the identifier is an application server certificate.

26. The system ofclaim 17 wherein the session key is substantially equivalent to a null value.

27. The system ofclaim 17 wherein the ticket grants access for a single use.

28. The system ofclaim 17 wherein the ticket grants access to a previously authorized resource.

29. The system ofclaim 17 wherein the client transmits a password to the application server.

30. The system ofclaim 17 wherein the web server obtains the MIME type document from the application server.

31. The system ofclaim 22 wherein the remote display protocol is the Independent Computing Architecture protocol.

32. The system ofclaim 22 wherein the remote display protocol is the Remote Display Protocol.

33. A method for establishing a secure communication channel with an application server, the method comprising the steps of:

(a) receiving a MIME type document and a ticket from the web server, the ticket having an identifier and a session key, and the MIME type document comprising a client application program;

(b) invoking the received client application program;

(c) establishing an application communication channel with an application server;

(d) transmitting the identifier from the ticket to the application server over the application communication channel to provide the application server with information for obtaining a copy of the session key; and

(e) encrypting communications to the application server over the application communication channel using the session key.

34. The method ofclaim 33 wherein step (e) further comprises decrypting communications from the application server using the session key.

35. The method ofclaim 33 wherein step (a) further comprises establishing a secure web communication channel between a web browser and the web server.

36. The method ofclaim 35 wherein step (g) further comprises transferring the ticket from the web browser to the client application program.

37. The method ofclaim 33 wherein step (a) further comprises sending, to the web server, a request to have an application program executed on the application server and to receive output from the application program executing on the application server.

38. The method ofclaim 37 wherein step (e) further comprises executing, by the application server, the application program identified in the request, and transmitting, by the application server, the output of the application program over the application communication channel via a remote display protocol.

39. The method ofclaim 33 wherein step (e) further comprises obtaining a MIME type document having a remote display client for the client application program.

40. The method ofclaim 33 wherein step (a) further comprises installing the client application program for a first time.

41. The method ofclaim 33 wherein step (a) further comprises obtaining a ticket having an application server certificate for the identifier.

42. The method ofclaim 33 wherein step (a) further comprises obtaining a ticket having a session key substantially equivalent to a null value.

43. The method ofclaim 33 wherein step (a) further comprises obtaining a ticket granting access for a single use.

44. The method ofclaim 33 wherein step (a) further comprises obtaining a ticket granting access to a previously authorized resource.

45. The method ofclaim 33 wherein step (d) further comprises transmitting a password to the application server.

46. The method ofclaim 38 wherein step (e) further comprises using the Independent Computing Architecture protocol for the remote display protocol.

47. The method ofclaim 38 wherein step (e) further comprises using the Remote Display Protocol for the remote display protocol.

48. A client system for establishing a secure communication channel with a client, the client system comprising:

a web browser in communication with a web server over a web communication channel, the web browser receiving, from the web server, a MIME type document and a ticket, the MIME type document comprising a client application program, the ticket having an identifier and a session key;

a client application program invoked by the web browser; and

the client application program establishing an application communication channel with the application server, the client application program transmitting the identifier over the application communication channel, and the client application program encrypting communications to the application server over the application communication channel using the session key.

49. The system ofclaim 48 wherein the client application program decrypts communications from the application server over the application communication channel using the session key.

50. The system ofclaim 48 wherein the web browser transfers the ticket to the client application program.

51. The system ofclaim 48 wherein the web browser transmits a request to have an application program executed on the application server and to have output of the application program executing on the application server transmitted to the client application program.

52. The system ofclaim 51 wherein the application server executes the application program identified in the request, and transmits the output of the application program to the client application program over the application communication channel via a remote display protocol.

53. The system ofclaim 48 wherein the client application program is a remote display client.

54. The system ofclaim 48 wherein the client application program is installed for a first time on the client.

55. The system ofclaim 48 wherein the identifier is an application server certificate.

56. The system ofclaim 48 wherein the session key is substantially equivalent to a null value.

57. The system ofclaim 48 wherein the ticket grants access for a single use.

58. The system ofclaim 48 wherein the ticket grants access to a previously authorized resource.

59. The system ofclaim 52 wherein the remote display protocol is the Independent Computing Architecture protocol.

60. The system ofclaim 52 wherein the remote display protocol is the Remote Display Protocol.

61. A method for establishing a secure communication channel with a client, the method comprising the steps of:

(a) obtaining, by a web server, a MIME type document and a ticket associated with a client, the MIME type document comprising a client application program, the ticket having an identifier and a session key;

(b) transmitting, by the web server, the MIME type document and the ticket to a web browser over a web communication channel;

(c) invoking, by the web browser, the received client application program;

(d) establishing an application communication channel with the client;

(e) receiving, from the client application program, the identifier from the ticket over the application communication channel;

(f) obtaining a copy of the session key from the web server using the identifier; and

(g) encrypting communications to the client application program over the application communication channel using the session key.

62. The method ofclaim 61 wherein step (g) further comprises decrypting communications from the client application program using the session key.

63. The method ofclaim 61 wherein step (b) further comprises establishing a secure web communication channel between a web browser and the web server.

64. The method ofclaim 63 wherein step (b) further comprises transferring, by the web browser, the ticket to the client application program.

65. The method ofclaim 61 wherein step (a) further comprises receiving, at the web server, a request from the client to have an application program executed on the client's behalf and to have output from the application program, as it is executing, transmitted to the client application program.

66. The method ofclaim 65 wherein step (g) further comprises executing the application program identified in the request, and transmitting the output of the application program over the application communication channel via a remote display protocol.

67. The method ofclaim 61 wherein step (g) further comprises using a remote display client for the client application program.

68. The method ofclaim 61 wherein step (e) further comprises installing the client application program for a first time on the client.

69. The method ofclaim 61 wherein step (a) further comprises obtaining a ticket having an application server certificate for an identifier.

70. The method ofclaim 61 wherein step (b) further comprises obtaining a ticket having a session key substantially equivalent to a null value.

71. The method ofclaim 61 wherein step (a) further comprises obtaining a ticket granting access for a single use.

72. The method ofclaim 61 wherein step (a) further comprises obtaining a ticket granting access to a previously authorized resource.

73. The method ofclaim 61 wherein step (e) further comprises receiving a password from the client.

74. The method ofclaim 61 wherein step (a) further comprises obtaining the MIME type document from an application server.

75. The method ofclaim 66 wherein step (g) further comprises using the Independent Computing Architecture protocol for the remote display protocol.

76. The method ofclaim 66 wherein step (g) further comprises using the Remote Display Protocol for the remote display protocol.

77. A server system for establishing a secure communication channel with a client, the server system comprising:

a ticket service generating a ticket associated with a client, the ticket having an identifier and a session key;

a web server in communication with the ticket service, the web server transmitting a MIME type document and the ticket to the client over a web communication channel, the MIME type document comprising a client application program; and

an application server receiving the identifier from the ticket from the client, obtaining a copy of the session key from the web server, establishing an application communication channel with the client, and encrypting communications to the client over the application communication channel using the session key.

78. The system ofclaim 77 wherein the application server decrypts communications from the client over the application communication channel using the session key.

79. The system ofclaim 77 wherein the web server receives a request from the client to have an application program executed on the client's behalf and to have output from the application program, as it is executing, transmitted to the client.

80. The system ofclaim 77 wherein the application server executes the application program identified in the request, and transmits the output of the application program to the client application program over the application communication channel via a remote display protocol.

81. The system ofclaim 77 wherein the client application program is a remote display client.

82. The system ofclaim 77 wherein the client application program is installed for a first time on the client.

83. The system ofclaim 77 wherein the identifier is an application server certificate.

84. The system ofclaim 77 wherein the session key is substantially equivalent to a null value.

85. The system ofclaim 77 wherein the ticket grants access for a single use.

86. The system ofclaim 77 wherein the ticket grants access to a previously authorized resource.

87. The system ofclaim 77 wherein the application server receives a password from the client.

88. The system ofclaim 77 wherein the web server obtains the MIME type document from the application server.

89. The system ofclaim 80 wherein the remote display protocol is the Independent Computing Architecture protocol.

90. The system ofclaim 80 wherein the remote display protocol is the Remote Display Protocol.

Images