US20040163087A1 - Computer program code and method for delivering external data to a process running on a virtual machine - Google Patents

Abstract

A method and system for delivering external data to a process running on a virtual machine, said virtual machine running on an operating system. The method includes the steps of executing instructions on the virtual machine that obtain state data related to the process; querying the virtual machine to obtain component data related to the state data; and manipulating the component data to deliver the external data to the process. In one example, the system provides a single sign-on application that passes user credentials to a Java applet running on a Java virtual machine.

Description

BACKGROUND OF THE INVENTION
• 1. Field of the Invention[0001]
• The present invention relates to computer program code and a method for communicating with a process running on a virtual machine. By way of illustrative example of a preferred embodiment of the present invention reference will be made to a single sign-on application that passes user credentials to a Java applet running on a Java Virtual Machine. It is to be understood however that the present invention is applicable for communicating with a process running on a virtual machine in contexts other than single sign on applications.[0002]
• It is also to be understood that the term “process” it to be understood as having a broad meaning encompassing any executable computer code or data, whether compiled or interpreted, including but not limited to threads, procedures, scripts and programs.[0003]
• 2. Discussion of the Related Art[0004]
• When computers were first deployed, such as in a work environment, there was generally a single computer, (such as mainframe or minicomputer) shared by a number of users, who accessed the computer via “dumb” terminals. A user would authenticate their identity when logging in by entering a user name and password into their terminal and thereby gaining access to the resources (ie. programs and data) of the computer. Since there was only a single computer, the authentication process only had to be performed once per user session.[0005]
• With the establishment of local area networks linking PCs and/or workstations, minicomputers and mainframes, users often had to authenticate themselves to their own workstation to gain initial access to the network, and then separately to each network node on which a required resource resided. However, the maximum number of nodes on local area networks was fairly constrained, meaning that the number of different log-in names and passwords that a user needed to know was manageable.[0006]
• Most local area networks are now connected to wide area networks and principally the Internet. With Internet connectivity users have access to effectively limitless resources residing on globally dispersed network nodes. For example, as illustrated in FIG. 1, a[0007]user workstation100, such as a PC, is connected to anetwork102. Typically theworkstation100 is connected to a local area network (LAN). In turn, the LAN is connected via an Internet Service Provider (ISP) (not shown) to a router (not shown) that provides access to the Internet. The LAN may also be connected via the telephone system to other LANs to form extranets. Thenetwork102 illustrated in FIG. 1, refers to LANs (including extranets), wide area networks and the Internet.
• Network connectivity allows user access to resources residing on an[0008]Application Server104 that runs applications for the user and delivers output to theuser workstation100. Applications may also run directly on the user workstation and have access tofile servers106,print servers108 andemail servers110 residing on the LAN or on other networks including the Internet.
• The[0009]user workstation100 also has access to resources on a mainframe/Unix Host112 that are accessed via terminal emulator software, using a protocol such as TN3270, running on the user workstation. Network connectivity also allows access to any number ofservices114 available on the World Wide Web, such as internet banking, online auctions, online retailers, commercial databases (such as Lexis or Dialog) and web mail
• Potentially, a user may have to authenticate themselves each time they wish to access a particular resource, meaning that a large volume of authentication credentials (such as user names, and passwords) needs to be remembered. Additionally, for security purposes, many services require that a password be changed on a regular basis, thus adding to the confusion and difficulty in managing authentication credentials.[0010]
• In an attempt to better manage authentication of user credentials Single Sign On (SSO) systems have been developed. SSO allows automation of the authentication process, whereby users authenticate themselves once, with the SSO system then managing subsequent authentications if and when required. In some cases, SSO is provided by an[0011]authentication server116, accessible to theuser work station100 over thenetwork102. Alternatively, the SSO system can run directly on theuser workstation100 or on both theworkstation100 andserver116. A database (such as an X.500 based Directory) ofauthentication credentials118 is accessible to the SSO system. For security purposes the authentication credentials are stored in encrypted form.
• An overview of an SSO system is given by reference to FIG. 2. Generally, the SSO system runs as a background process on the[0012]user workstation100 instep202. Atstep204, data that is indicative of the state of a user interface (hereinafter referred to as “user interface state data”) presented on the user workstation is examined to detect whether there is a log-in opportunity. This step is typically implemented via services provided by the operating system as understood by those skilled in the art. For example the Windows operating system provides application programming interfaces (API's) that allow an application to be notified of various user interface events. This mechanism, known as “Windows hooking”, allows the application to determine when a window is created, what the window contains and properties of the window such as its title, position and others. After detecting a log-in opportunity atstep206, the SSO system determines the particular resource related to the log-in opportunity (such as application, mainframe, web service etc) and retrieves the relevant authentication credentials from thedatabase118. These credentials are then applied atstep210 to the user interface object, such as by entering the user name and password to thereby complete the authentication process. The user is thus relieved from having to remember and enter the correct user name and password to access a particular resource.
• The resources accessed by the SSO system may exist on the[0013]user workstation100 as an application program, as is illustrated in FIG. 3. In this case, an application program300 (for example a terminal emulator or email client) usesoperating system302 services such as auser interface304 to perform its tasks. TheSSO system200 is also an application program that, as noted above, uses operating system services to authenticate the user to particular resources.
• However, some resources do not exist as an application program running directly on the[0014]operating system302, but rather as a process running on avirtual machine304. A virtual machine can be described as a software simulated machine providing the operational equivalent of a real machine that does not exist as a physical entity per se. Avirtual machine304 takes instructions from aprocess306 and converts them to instructions that are recognisable by theoperating system302 andhardware308 on which thevirtual machine304 runs.
• For example, as illustrated in FIG. 4 a[0015]web browser310 such as Microsoft Internet Explorer exists as an application program running on an operating system302 (such as Microsoft Windows), which in turn is running on particular hardware308 (such as an Intel processor with memory and peripherals). Theweb browser310 implements avirtual machine304 on which processes may be run. In particular, a Javaapplet306 delivered as part of a web page to theweb browser310 over theinternet102, exists as a process that runs on the virtual machine304 (for example the JVM developed by Sun Microsystems).
• The Java applet uses services provided by the virtual machine, to instructions recognisable by the[0016]operating system302 andhardware308 implementing thevirtual machine304. The Java programming language was developed by Sun Microsystems and has been successful due to its cross platform portability, in that a single Java program may be written for any platform that implements the JVM. Thus, the same applet may be written for and run on a platform employing, for example, the Microsoft, Unix, Linux or Macintosh operating system or indeed any platform that implements a JVM.
• Numerous web based services provide authentication prompts, such as requests for user names and passwords via a Java applet that is downloaded to the user's browser and runs on a virtual machine. An effective SSO system would allow authentication to any resource, irrespective of how the resource exists on a[0017]user workstation100. Whilst current SSO systems allow accurate authentication to a resource existing as an application program, they are less successful where the resource exists as a process running on a virtual machine. Thus SSO systems could be improved to allow authentication into a virtual machine. Also, it would be advantageous to communicate with processes running on virtual machines for other purposes.
SUMMARY OF THE INVENTION
• 1. Object of the Invention[0018]
• The present invention aims to provide an alternative to known software products and methods of the type referred to above. More particularly, the invention aims to provide a computer software product and method that allows communication with a process running on a virtual machine.[0019]
• 2. Disclosure of the Invention According to a first aspect of the present invention there is provided a method for delivering external data to a process running on a virtual machine, said virtual machine running on an operating system, the method including the steps of:[0020]
• executing instructions on the virtual machine that obtain state data related to the process;[0021]
• querying the virtual machine to obtain component data related to the state data; and[0022]
• manipulating the component data to deliver the external data to the process.[0023]
• Typically the process implements a user interface and the state data is user interface state data. The user interface is generally a graphical user interface (GUI) and the user interface state data preferably indicates the creation of a top level window in the GUI.[0024]
• Optionally the instructions utilise an applications program interface (API) running on the virtual machine to obtain the state data. It has been found that an accessibility API is a suitable API and that the state data may be obtained by using an accessibility API to hook the virtual machine process.[0025]
• The process may for example be an applet or an application.[0026]
• Prior to the querying step, the method may include the optional steps of calling a second process that executes outside the virtual machine and obtaining attribute data relating to the state data from the second process.[0027]
• The attribute data may include any one or more of:[0028]
• a location indicator specifying a directory containing a main Class file of the applet,[0029]
• a name of the main Class file,[0030]
• a unique identifier allocated by the operating system to a parent window of the applet, and[0031]
• a time value representing the time when GUI objects created by the applet were loaded and displayed.[0032]
• Preferably the attribute data is forwarded for use by the instructions executing on the virtual machine and may be forwarded in a UDP packet.[0033]
• The instructions executing on the virtual machine may be additionally operative to:[0034]
• determine the unique identifier allocated by the operating system to a parent window of the applet; and[0035]
• confirm that the unique identifier determined by the virtual machine instructions matches the unique identifier allocated externally by the operating system.[0036]
• The external data is preferably delivered to the parent window identified by the unique identifier.[0037]
• The external data could, for example be a login script for entering authentication credentials into the process.[0038]
• According to a second aspect of the present invention there is provided computer program code for carrying out the method of the first aspect of the invention.[0039]
• According to a third aspect of the present invention there is provided a Single Sign On System including:[0040]
• a computer terminal;[0041]
• an operating system installed on said computer terminal;[0042]
• a virtual machine running on the operating system;[0043]
• a server communicatively coupled to the computer terminal;[0044]
• a Java applet stored at the server, the applet including instructions that when executed on a virtual machine define a user interface[0045]
• a browser installed on said computer terminal operative to download the Java applet from the server and run the Java applet on the virtual machine;[0046]
• a database of authentication credentials accessible to the computer terminal; and[0047]
• instructions executable on the virtual machine operative to:[0048]
• obtain user interface state data from the Java applet;[0049]
• query the virtual machine to obtain component data related to the user interface state data; and[0050]
• manipulate the component data so as to deliver authentication credentials to the Java applet.[0051]
• The software product method and system of the present invention allows communication with a process running on a virtual machine and can be used to implement an SSO system. In addition the present invention could be utilised in any situation where communication with virtual machine processes is required, such as for testing software code written to be executed on a virtual machine.[0052]
BRIEF DESCRIPTION OF THE DRAWINGS
• A preferred embodiment of the present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout and wherein:[0053]
• FIG. 1 is a block diagram illustrating the resources available to a user workstation via network connectivity as occurs in the prior art;[0054]
• FIG. 2 is a flow chart illustrating the operation of an SSO system as occurs in the prior art;[0055]
• FIG. 3 is a block diagram illustrating an application program running on an operating system and a Java applet running on a Virtual Machine inside a Web Browser;[0056]
• FIG. 4 is a block diagram illustrating the components of the software product of the present invention;[0057]
• FIG. 5 is a flow chart illustrating a high level view of the process carried out by the software product of the present invention;[0058]
• FIG. 6 is flow chart illustrating the process carried out by the SSO Hook in receiving user interface state data and calling the other components of the software product;[0059]
• FIG. 7 is a flow chart illustrating the process carried out by the Browser Helper Object after being called by the SSO Hook;[0060]
• FIG. 8 is a flow chart illustrating the process carried out by the SSO Hook after receiving a discovery packet from the Browser Helper Object;[0061]
• FIG. 9 is a flowchart illustrating the process carried out by the SSO Hook in passing a login script to a Window opened by the Java Applet running on the virtual machine;[0062]
• FIG. 10 is a flow chart illustrating the process carried out by the JNI DLL after being called by the SSO Hook.[0063]
DESCRIPTION OF THE PREFERRED EMBODIMENTS
• Turning to FIG. 4, there is illustrated the[0064]user workstation100, which is a PC havingconventional hardware308, on which anOperating System302, such as Microsoft
• Windows is running. Two application programs, being a[0065]web browser310 and anSSO system200 are running on theOperating System302. Avirtual machine304 such as the JVM is implemented within theweb browser310 that allows aJava applet306, downloaded from the Internet with aweb page410 to run on the user workstation. Theapplet310 is written in the Java programming language and uses services provided by the virtual machine to perform its tasks and actually runs on thevirtual machine304 as a thread inside thebrowser process302. The program instructions of the applet will be converted by thevirtual machine304 into instructions that can be executed by theoperating system302. The conversion process, however, is hidden from theapplet306 that needs only to call services that are provided by the virtual machine. In turn, theoperating system302 implements the necessary routines from thehardware308 to execute the converted instructions.
• The task of the[0066]applet306 in this example is to request the entry of a user name and password from the user of theworkstation100, to allow the user access to resources provided at the web server from which theweb page410 was obtained. To accomplish this task, a user interface object such as a window with text entry boxes to receive a user name and password must be created in a graphical user interface. Application programs running on theoperating system302 utiliseAPIs412 provided by theoperating system302 to create such objects. In the case of Microsoft's32 bit Windows Operating Systems the relevant APIs are known as “Win32” and application programs that rely on these APIs are known as Win32 applications. Also, as was noted above, theoperating system302 may also provide APIs that allow an application program to be notified of user interface events, such as the creation of a window in the graphical user interface (GUI).
• However, in recent Java graphical user interface (GUI) frameworks only the[0067]browser310 window that contains the top level Java window (“the applet frame window”) is a Win32 window, with other user interface objects appearing to the operating system as a privately managed screen area. Thus where a window, other than an applet frame window, is created by theJava applet306 running inside thevirtual machine304, data that is indicative of the state of a user interface (the “user interface state data”), except for title of the Window, is not accessible to application programs, including theSSO system200. It is for this reason that current SSO systems are not suited to authenticating users to services that exist as processes running on a virtual machine.
• To provide access to this user interface state data, an[0068]Accessibility API402 also runs on thevirtual machine304. An example of an Accessibility API that is suitable for implementing the present invention is the Java Accessibility API that was designed by Sun Microsystems to allow third party applications and in particular those used by the disabled (for example Braille readers, speech synthesisers, image enlargers etc) to interact with Java applets. It has been surprisingly found that an Accessibility API provides access to crucial user interface state data that can be used by theSSO system200 to pass data from a process running outside the virtual machine (“external data”) into the applet.
• The present invention works best with versions[0069]6 and above of Microsoft's Internet Explorer having the Javasoft Runtime Environment (“JRE”) plugin with Accessibility API installed. Accessibility should be appropriately enabled through the awt.properties and Accessibility.properties files residing on the appropriate JRE.
• An[0070]SSO Hook400, written in the Java programming language, also runs on thevirtual machine304 with theapplet306 and theAccessibility API402. TheSSO Hook400 can be registered with theAccessibility API402 to obtain state data relevant to theapplet306. Additionally theSSO Hook400 also includes instructions for forwarding external data from theSSO System200, to theapplet306 by manipulating the state data obtained from theAccessibility API402.
• Also running on the[0071]virtual machine304 is a Java Native Interface (“JNI”) Component the functionality of which is detailed below.
• Outside the virtual machine is a Win[0072]32 Component Object Model (“COM”) component known as a Browser Helper Object (BHO)406, again having functionality that is detailed further below.
• A high level view of the operation of the components of the invention described in FIG. 4 is given by reference to FIG. 5. At[0073]step500, theSSO System200 causes theSSO Hook400 to execute on thevirtual machine304 as a background process. User Interface State Data is then received atstep504 and examined by theSSO Hook400. At step504 a test is carried out to determine whether the User Interface State Data defines a login opportunity related to theJava applet306, running on thevirtual machine304. In the event that a login opportunity is defined the relevant authentication credentials are retrieved from thedatabase118 atstep506. These credentials are then applied to the Java applet instep508 to effect the authentication.
• The initial stage of the process commences when the[0074]SSO Hook400 executes on thevirtual machine304 and this stage is illustrated in more detail by reference to FIG. 6. Atstep600, theSSO Hook400 uses the Accessibility API to determine if there is any relevant user interface state data from theJava applet306 running on thevirtual machine304. Specifically, the Accessibility API will notify the SSO Hook whenever a top level window (being the main window in the window hierarchy for the applet) is created by a Java applet. Although the creation of a top level Window is often discoverable using the standard Win32 hooking mechanisms only the title of the window is available to an application. This is not the case where an Accessibility API is used. Upon notification by the Accessibility API theSSO Hook400 examines various attributes of the top level window discovered by the Accessibility API including but not limited to its title, class, child windows and controls.
• In the case of a Java Application Program, as opposed to an applet, it has been found that sufficient component data can be obtained from the state data to enable sign on data to be passed to the Application Program at this point. Where the process is an applet, further steps need to be taken, as is further described below.[0075]
• A test is performed at[0076]step602 to determine whether the user interface state data received from theAccessibility API402 indicates that a top level window has been created by the applet. In the event that such a window has been created a job is created on an internal queue and a thread is triggered for that job atstep604. TheBHO406 is then called atstep606, followed by theJNI component407 atstep608. Subsequent to calling these components theSSO Hook400 waits atstep610 to receive attribute data from theBHO406 and theJNI component407. After receiving the attribute data atstep612 theSSO Hook400 is ready to pass external data to theJava applet306.
• As just noted, the[0077]BHO406 is called by theSSO Hook400 after theSSO Hook400 has detected the opening of a top level window by theapplet306. The processes carried out by theBHO406 are described in more detail by reference to FIG. 7. TheBHO406 checks atstep700 whether a new job has been placed on the queue by theSSO Hook400. For each new job theBHO406 obtains attribute data about the relevant applet atstep702. The BHO hooks into thebrowser304 running thevirtual machine304 to obtain the discovery information. The practice of hooking was discussed above and uses an interface supplied by the Microsoft Corporation that is documented in the Microsoft Developer Network Manuals, the contents of which are hereby incorporated by reference.
• The attribute data such hooked from the[0078]browser302 includes firstly a full URL that completely specifies the directory containing the main Class file of theapplet306. A correct URL of the applet is required to know which credentials from thedatabase118 to apply to theapplet306.
• Secondly, the attribute data includes the “Codebase” attribute of the applet which is the name of the main Class file located in the directory identified by the URL. Actual execution of the[0079]applet306 on thevirtual machine304 begins with the main Class file.
• Thirdly, the attribute data includes a unique identifier, allocated by the[0080]operating system302 of the frame window of thebrowser304 housing theapplet306 which is also the parent window of theapplet306. In the case of a Windows Operating System this identifier is a variable of type HWND and is also know as a “window handle”. This data is particularly important where there is more than one browser running at once as it ensure that the user credentials from the database are forwarded to the correct window.
• Fourthly, the attribute data includes the exact time when the GUI objects created by the[0081]applet306 were loaded and been displayed.
• A unique port number is calculated for the applet at[0082]step704. The calculation of the unique port number relies on the fact that each of theapplet306,BHO400 and SSO Hook are all identified by thesame operating system302 process number. The port number is then used for communications between the BHO and SSO Hook. A Transmission Control Protocol (TCP) packet is formed atstep706 that contains the attribute data obtained atstep702. The attribute data is forwarded atstep708 to the port number created atstep704.
• The TCP packet is forwarded back inside the virtual machine for use by the[0083]SSO Hook400 as described by reference to FIG. 8. After receiving the TCP packet (“the discovery packet”) from theBHO406 at step800, theSSO Hook400 parses the discovery packet atstep802 to extract the attribute data contained within the discovery packet, of the window or other GUI elements related to theJava applet306. As noted above, one of the items of attribute data is the window handle of the browser window that houses the top level Java window of theapplet306. Since there could be more than onebrowser310 running of theoperating system302 at any one time, theSSO Hook400 needs to ensure that the correct credentials from thedatabase112 are being forwarded to the window. Hence atstep804 the SSO Hook also determines the handle of thebrowser310 window housing the top level Java Window. The SSO Hook utilised theJNI Component407 to make this determination as is further described below.
• The window handle determined by the[0084]SSO Hook400 is then matched atstep804 against the window handle forwarded to the SSO Hook in the discovery packet. In the event of a match, theSSO Hook400 will know that the window identified by the handle is the correct window to receive the authentication credentials. Thus atstep806 theSSO Hook400 dispatches the discovery packet, containing the attribute data to with window identified by the handle atstep804. As noted above, with reference to FIG. 6, theSSO Hook400 maintains an internal queue of jobs that represent discovered applets and it is to one of these pending jobs to which attribute data is forwarded.
• The[0085]SSO Hook400 utilises theJNI Component407 to independently determine the handle of thebrowser310 window that is hosting the Java applet. This process is now explained with reference to FIG. 10. Atstep900 theJNI Component407 receives the window handle from theSSO Hook400. At step902 a Java “Window” type is mapped into the window handle. This step enables theJNI Component407 to determine whether the window handle forwarded by theSSO Hook400 relates to the same window that hosts the top level Java window of the applet. Atstep904, the window handle is then forwarded back to theSSO Hook400.
• After the attribute data is dispatched to the[0086]applet306, theSSO Hook400 and theJNI Component407 are able to pass the authentication credentials to theapplet306 and thereby affect sign on to the resource. This process is described by reference to FIGS. 10. The SSO Hook atstep1000 obtains a component tree from the attribute data. The component tree is obtained by querying theVirtual Machine304 in a manner familiar to those skilled in the art. Atstep1002 the component tree is manipulated by the SSOSystem Scripting Engine408. Manipulation of the component tree of a graphical user interface window by an SSO Scripting Engine actually carries out the sign and thus enables access to the relevant resource. It is again a process familiar to those skilled in the art and will not be further detailed here.
• Several benefits arise from the computer program code and method of the present invention in comparison to the programs and methods of the prior art. Principally, the computer program code and method allow Single Sign On systems to be used to access resources provided processes running on a virtual machine. Additionally, the computer program code and method allow communication with processes running on a virtual machine for other purposes, for example for testing virtual machine processes.[0087]
• It will be realised that the present invention has been described by reference to a preferred embodiment and that any alterations and modification that are apparent to those skilled in the art are included within the spirit and scope of the invention as defined solely by the claims appended hereto.[0088]

Claims (17)

We claim:

1. A method for delivering external data to a process running on a virtual machine, said virtual machine running on an operating system, the method including the steps of:

executing instructions on the virtual machine that obtain state data related to the process;

querying the virtual machine to obtain component data related to the state data; and

manipulating the component data to deliver the external data to the process.

2. A method according toclaim 1 wherein the process implements a user interface and the state data is user interface state data.

3. A method according toclaim 2 wherein the user interface is a graphical user interface (GUI) and the user interface state data indicates the creation of a top level window in the GUI.

4. A method according toclaim 1 wherein the instructions utilise an application programming interface (API) running on the virtual machine to obtain the state data.

5. A method according toclaim 4 wherein the API is an accessibility API and the state data is obtained by hooking the virtual machine process using that API.

6. A method according toclaim 3 wherein the process is a Java applet.

7. A method according toclaim 6 including, prior to the querying step, the step of calling a second process that executes outside the virtual machine and obtaining attribute data relating to the state data from the second process.

8. A method according toclaim 7 wherein the attribute data includes any one or more of:

a location indicator specifying a directory containing a main Class file of the applet,

a name of the main Class file,

a unique identifier allocated by the operating system to a parent window of the applet, and

a time value representing the time when GUI objects created by the applet were loaded and displayed.

9. A method according toclaim 8 further including instructions for forwarding the attribute data for use by the instructions executing on the virtual machine.

10. A method according toclaim 9 wherein the attribute data is forwarded in a UDP packet.

11. A method according toclaim 9 wherein the instructions executing on the virtual machine are additionally operative to:

determine the unique identifier allocated by the operating system to a parent window of the applet; and

confirm that the unique identifier determined by the virtual machine instructions matches the unique identifier allocated externally by the operating system.

12. A method according toclaim 11 wherein the external data is delivered to the parent window identified by the unique identifier.

13. A method according toclaim 2 wherein the external data is a login script for entering authentication credentials into the process.

14. Computer program code for carrying out the method ofclaim 1.

15. Computer program code for carrying out the method ofclaim 12.

16. A Single Sign On system for use on a computer terminal having an operating system installed thereon and a virtual machine running on the operating system, and wherein a server is communicatively coupled to the computer terminal; said system including:

a Java applet stored at the server, the applet including instructions for execution on a virtual machine to define a user interface;

a browser installed on said computer terminal operative to download the Java applet from the server and run the Java applet on the virtual machine;

a database of authentication credentials accessible to the computer terminal; and

instructions executable on the virtual machine, which instructions are operative to:

obtain user interface state data from the Java applet;

query the virtual machine to obtain component data related to the user interface state data; and

manipulate the component data so as to deliver authentication credentials to the Java applet.

17. A Single Sign On System according toclaim 16 wherein the Java applet includes instructions for presenting an object in the user interface that prompts a user of the terminal to authenticate themselves to a resource provided by the server, the virtual machine instructions automatically delivering the authentication credentials to the object to effect the authentication.

Images