The present invention relates generally to network application programs, and more specifically to a method and system for storing a Web browser application session cookie from a separate client application program, such as a virtual desktop client application program. The present invention also provides a method and system for providing a pre-authenticated launch of a Web browser application from such a separate client application program.
As it is generally known, the World Wide Web (“Web”) is made up of Web servers computer systems that store and disseminate Web pages over Internet connections. Web pages are documents containing many types of content, such as text, graphics, animations and videos. Uniform Resource Locators (“URL”) are the most common addresses used to define a route to a Web page on a Web server.
A URL is a type of Uniform Resource Identifier (URI) that uses the Hypertext Transfer Protocol (HTTP). A URI is the general addressing technology for identifying resources on the Internet or a private intranet. The “scheme” of a given URI indicates the way a Web resource identified by the URI is to be used or accessed. A URI scheme is associated with a prefix, such as HTTP within a URL for accessing a designated Web resource using HTTP. The URI rules of syntax are set forth in the Internet Engineering Task Force (IETF) Request for Comments 1630, from which was derived URI Generic Syntax Request for Comments 2396.
Based on the contents of a provided URI, the browser application program renders Web pages on screen and automatically invokes additional software as needed. For example, animations and special effects are often presented using browser plug-in programs, and audio and video may be played by media player software that either comes with the operating system or from a third party.
A problem with existing systems occurs when a non-browser application program uses a browser program to access a Web page, in that user specific information previously obtained by the non-browser program may not be available to the service being accessed through desired Web page. For example, a user may begin a session with a non-browser application program, and during that session the non-browser program may collect various information regarding the user and the current session. Such user specific information may be used by the non-browser application program to provide a user experience customized to the user. However, if the non-browser program launches a browser program, for example in response to a user clicking on a hyperlink for a given URL, the user specific information for that user session is not accessible to the Web page(s) accessed by the browser. This results in a discontinuity of experience between when the user is using the non-browser client application, and when the user is accessing a Web page through the browser, even though the browser may have been launched through the non-browser program.
Another significant problem in existing systems occurs after a user has been authenticated through a non-browser client application program, and subsequently launches the browser through the non-browser application to access a secure Web page indicated by a URL. The user may be required to re-authenticate themselves by the secure Web page accessed through the browser, even through they may have already been authenticated for that page previously while using the non-browser application. The result is redundant authentication steps by the user, reducing the likelihood of a satisfactory user experience.
For the above reasons and others, it would be desirable to have a new system for making user specific session information accessible to Web pages accessed through a browser program launched from within a non-browser application program. The new system should further eliminate the need for redundant authentication steps by the user when accessing secure Web pages using the browser launched from within the non-browser application program.
To address the above described and other shortcomings of previous systems, a method and system for storing a Web browser application session cookie from another client application program are disclosed. A separate client application is allowed to launch an external browser, and to supply the browser with a session cookie containing user specific session information.
In a first aspect of the disclosed system, the browser is extended to support a new URI scheme. The new URI scheme provides for indication of a name and value of a session cookie to be embedded into the browser, as well as an embedded URI to be processed by the browser after the session cookie has been embedded. After the browser has been extended to handle the new URI scheme, a URI using the new scheme is passed to the browser as a command line parameter by a separate application program. The disclosed system may use the browser's built-in inter-process communication mechanism to route the URI to a currently running browser instance, or may launch a new browser instance. In either case the URI may be passed as a command line parameter.
The extended browser processes the new scheme URI, extracting the session cookie data and an embedded URI to be subsequently loaded. A destination host is parsed from the embedded URI, and the extended browser loads the provided session cookie, for use in future operations, such as HTTP requests to the specified host during the current browser session. Finally, the extended browser loads the extracted URI.
In another aspect of the disclosed system, a client application separate from the browser may allow the user to access a secure Web site either by launching the browser from the non-browser application, or by using a currently running browser instance, without requiring that the user provide redundant authentication credentials. In this regard, the disclosed system operates to pre-authenticate the user prior to the user accessing the secure Web page through the browser. The results of such background authentication steps, which are performed transparently with regard to the user, are then provided to the browser from the non-browser program, in order that the user need not re-supply them. For example, a single sign on token or other information may be loaded by the non-browser application into the browser program on behalf of the user. Subsequently, when the user requests access to a secure Web page using the browser, they are granted access without having to re-authenticate. In one embodiment, user authentication credentials may be passed to the browser through a session cookie indicated to the browser using the new URI scheme disclosed herein. However, the disclosed system is not so limited, and any other appropriate mechanism may be used in the alternative to load the user's authentication credentials to the browser program.
The use of a session cookie by the disclosed system is advantageous for storing potentially sensitive user data in the browser, as opposed to using a persistent cookie, since it avoids the user data being written to disk, and allows for the deletion and expiration of the cookie to be intrinsically handled by the browser. This invention enables a session cookie to be embedded into a Web browser from a separate client application program. Moreover, the disclosed system enables this functionality independent of whether or not the browser is already running.
Thus there is disclosed a new system for making user specific session information accessible to Web pages accessed through a browser program launched from within a non-browser application program. The new system also eliminates the need for redundant authentication steps by the user when accessing secure Web pages using a browser launched from within the non-browser application program.
In order to facilitate a fuller understanding of the present invention, reference is now made to the appended drawings. These drawings should not be construed as limiting the present invention, but are intended to be exemplary only.
As shown in
As further shown in
During a user session in which the application user 18 uses the application client 22, the application client collects information regarding the session and/or application user 18. Such user information may, for example, include information such as password, single sign on (SSO) token, encrypted data, or any other type of application specific data. For example, a single sign on token may be generated using the application client 22 by way of an authentication process between the application client and software executing on the server computer system 14 that permits the application user 18 to enter one user name and password in order to access multiple applications. Such a single sign on may be requested at the initiation of the application user 18's session with application client 22, and may authenticate the application user 18 to access all the applications they have been given the rights to executing on the server computer system(s) 14, eliminating further authentication prompts when the user switches applications during that particular session. Credentials established for use by the application user 18 during such authentication steps may be stored as part of a single sign on token that may be subsequently used to authenticate the application user 18 on multiple application programs executing on server computer system(s) 14 during the current user session. Such credentials may, for example, include a user name, password, or any other specific kind of user authentication information, and may be encrypted in some embodiments.
The user information established by the application client 22 is passed a session cookie 22 to a Web browser 24. The session cookie 22 is relatively small data file that is temporarily stored on the client computer system 10 for the duration of the current user session. The session cookie 22 may be stored in memory, but not written permanently to a hard disk on the client compute system 22, as would be the case for a persistent cookie.
The session cookie 22 includes a range of URLs for which it is valid, such as all the Web pages within a given domain. After the session cookie 22 is passed to the Web browser 22, when the Web browser 22 sends an HTTP request or the like to a Web server including those URLs, it also sends along the session cookie. Accordingly, if the application user 18 indicates a secure Web page to be accessed, for example by clicking on a hyperlink within the application user interface 20 provided by the application client 22, the application client can invoke the Web browser 24 by passing the URL for that hyperlink to the Web browser 24. The Web browser 24 responds by sending an HTTP request for the secure Web page, and, in the case where the URL is within the range of URLs for the session cookie 23, includes both the URL and the session cookie 23 in the request. In this way, the user data collected by the application client 22 is seamlessly and transparently provided to the Web browser 24. After the session cookie 23 is passed to the Web browser 24, the Web browser 24 may assume control over the session cookie 23, and is responsible for deleting the session cookie 23 upon termination of the current user session, and/or termination of the use of Web browser 24 by the application user 18.
In one embodiment of the disclosed system, the session cookie 23, including user data collected by the application client 22, is passed from the application client 22 to the Web browser 24 using a URI having a format following a new URI scheme, as further described below. In such an embodiment, the URL of the desired Web page is passed to the Web browser 24 as an embedded URI within the URI conformant with the new URI scheme. The URI handler 26 of the Web browser 26 recognizes and processes the URI based on the new URI scheme, at least in part by storing an indication of the session cookie 23, and loading the embedded URI into the Web browser 26. This results in a request for the desired Web page being issued to a server system, with the request including the user data information from the session cookie 23.
At step 34 the disclosed system passes a URI based on the new URI scheme from a client application program to the Web browser as a command line parameter. The URI based on the new URI scheme may, for example, be intercepted and processed by a URI handler routine that was part of the extension of the Web browser performed at step 32. At step 36, the extended Web browser extracts session cookie data and an embedded URI from the URI in the new URI scheme. The URI extracted from the URI in the new URI scheme is to be subsequently loaded into the Web browser program as a destination Web page to be requested.
The Web browser stores the session cookie data for future access at step 38. As noted above, the session cookie data may include any specific type of user data collected by the client application program passing the session cookie data to the Web browser. At step 39, the embedded URI that was extracted at step 36 is loaded into the Web browser. For example, the embedded URI loaded at step 39 may be a URL of a Web page that was requested by a user of the client application program that previously passed the session cookie to the Web browser. As a result of the loading of the embedded URI at step 39, the Web browser may, for example, issue an HTTP request for the Web page identified by the embedded URI, and also including user data information from the session cookie data extracted at step 36. At step 40, the Web browser detects that the current user session has terminated, and deletes the session cookie data extracted at step 36. Thus the information passed in the session cookie data is not persistent, in that it is not stored to hard disk at the end of the user session.
The URI scheme 42 is shown further including an embedded URI 46. The embedded URI 46 may, for example, consist of a URL having a <scheme> value equal to “https”, and a <urlpath> indicating a Web page. Additionally, the URI scheme 42 includes session cookie data 48, which stores user data to be used when accessing the resource indicated by the embedded URI 46. One example of a URI conformant with the new URI scheme 42 is as follows:
x-set-cookie:https://www.abz.com/root/profile;SSOToken=ssotokevalue
where the embedded URI value is the path “https://www.abz.com/root/profile”, and the session cookie data is the name value pair “SSOToken=ssotokenvalue”, for example indicating a name and value of a single sign on token to be used when accessing the path in the embedded URI.
Pre-Authenticated Browser Launch
Those skilled in the art will recognize that
Those skilled in the art should readily appreciate that programs defining the functions of the present invention can be delivered to a computer in many forms; including, but not limited to: (a) information permanently stored on non-writable storage media (e.g. read only memory devices within a computer such as ROM or CD-ROM disks readable by a computer I/O attachment); (b) information alterably stored on writable storage media (e.g. floppy disks and hard drives); or (c) information conveyed to a computer through communication media for example using wireless, baseband signaling or broadband signaling techniques, including carrier wave signaling techniques, such as over computer or telephone networks via a modem.
While the invention is described through the above exemplary embodiments, it will be understood by those of ordinary skill in the art that modification to and variation of the illustrated embodiments may be made without departing from the inventive concepts herein disclosed. Moreover, while the preferred embodiments are described in connection with various illustrative program command structures, one skilled in the art will recognize that they may be embodied using a variety of specific command structures.