Abstract:
In a computer system including a computer terminal, an operating system installed on said computer terminal, a virtual machine running on the operating system, a server communicatively coupled to the computer terminal and a process including instructions that when executed on a virtual machine define a user interface; a Single Sign On (SSO) system comprising a database of authentication credentials accessible to the computer terminal, and instructions executable on the virtual machine operative to: obtain user interface state data from the process; 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 process.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation-in-part of U.S. Ser. No. 10/369,268 filed by the present applicants on Feb. 14, 2003. The present application is also related to Australian Provisional Patent Application No. 2003906851 filed by the assignee on Dec. 11, 2003; the disclosure of which is hereby incorporated in its entirety. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    The present invention relates to a system and 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 system 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. 
         [0004]    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. 
         [0005]    2. Discussion of the Related Art 
         [0006]    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. 
         [0007]    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. 
         [0008]    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 user workstation  100 , such as a PC, is connected to a network  102 . Typically the workstation  100  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. The network  102  illustrated in  FIG. 1 , refers to LANs (including extranets), wide area networks and the Internet. 
         [0009]    Network connectivity allows user access to resources residing on an Application Server  104  that runs applications for the user and delivers output to the user workstation  100 . Applications may also run directly on the user workstation and have access to file servers  106 , print servers  108  and email servers  110  residing on the LAN or on other networks including the Internet. 
         [0010]    The user workstation  100  also has access to resources on a mainframe/Unix Host  112  that are accessed via terminal emulator software, using a protocol such as TN  3270 , running on the user workstation. Network connectivity also allows access to any number of services  114  available on the World Wide Web, such as internet banking, online auctions, online retailers, commercial databases (such as Lexis or Dialog) and web mail 
         [0011]    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) need 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. 
         [0012]    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 authentication server  116 , accessible to the user work station  100  over the network  102 . Alternatively, the SSO system can run directly on the user workstation  100  or on both the workstation  100  and server  116 . A database (such as an X.500 based Directory) of authentication credentials  118  is accessible to the SSO system. For security purposes the authentication credentials are stored in encrypted form. 
         [0013]    An overview of an SSO system is given by reference to  FIG. 2 . Generally, the SSO system runs as a background process on the user workstation  100  in step  202 . At step  204 , 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 (APIs) 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. 
         [0014]    After detecting a log-in opportunity at step  206 , 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 the database  118 . These credentials are then applied at step  210  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. 
         [0015]    The resources accessed by the SSO system may exist on the user workstation  100  as an application program, as is illustrated in  FIG. 3 . In this case, an application program  300  (for example a terminal emulator or email client) uses operating system  302  services such as a user interface  304  to perform its tasks. The SSO system  200  is also an application program that, as noted above, uses operating system services to authenticate the user to particular resources. 
         [0016]    However, some resources do not exist as an application program running directly on the operating system  302 , but rather as a process running on a virtual machine  304 . 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. A virtual machine  304  takes instructions from a process  306  and converts them to instructions that are recognisable by the operating system  302  and hardware  308  on which the virtual machine  304  runs. The first virtual machine  304  hosts a Java applet  306 , whilst a second virtual machine  312  may host a Java application  314 . 
         [0017]    For example, as illustrated in  FIG. 4  a web browser  310  such as Microsoft Internet Explorer exists as an application program running on an operating system  302  (such as Microsoft Windows), which in turn is running on particular hardware  308  (such as an Intel processor with memory and peripherals). The web browser  310  implements a virtual machine  304  on which processes may be run. In particular, a Java applet  306  delivered as part of a web page to the web browser  310  over the internet  102 , exists as a process that runs on the virtual machine  304 . For example the Java virtual machine (JVM) developed by Sun Microsystems, Inc. 
         [0018]    The Java applet uses services provided by the virtual machine, to instructions recognisable by the operating system  302  and hardware  308  implementing the virtual machine  304 . 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 Windows XP, Unix, Linux or Apple Macintosh OS series of operating systems, or indeed any platform that implements a JVM. 
         [0019]    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&#39;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 user workstation  100 . 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. 
         [0020]    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. One particular embodiment of the present invention, which employs the browser helper object (BHO) system to determine the source URL of a Java applet, is described in the applicant&#39;s co-pending U.S. patent application Ser. No. 10/369,268 filed 14 Feb. 2003 (Publication No. 2004/016087). Improvements and simplifications to the program code and method of the earlier embodiment have been undertaken to deliver enhanced reliability of operation, as described and illustrated herein. 
       SUMMARY OF THE INVENTION 
     Object of the Invention 
       [0021]    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 an improved computer software product and method that allows communication with a process running on a virtual machine. 
       DISCLOSURE OF THE INVENTION 
       [0022]    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 comprising 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.       
 
         [0026]    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. 
         [0027]    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. 
         [0028]    The process may for example be an applet or an application. 
         [0029]    The process may call out an external process to retrieve information, such as a login script or authentication credentials. Preferably, in order to retrieve the correct information, the code running within the virtual machine determines a unique identifier for itself. 
         [0030]    The unique identifier for identifying the application running in the virtual machine may be selected from one of:
       the class name of top level window,   the thread group of the top level window,   the textual information provided by the accessibility API is a name allocated by the API to the top level window, and   the title of the top level window.       
 
         [0035]    Suitably in the case of a Java accessibility API, the name of the top level window is an AccessibleName. 
         [0036]    According to a second aspect of the present invention there is provided computer readable media carrying program code for carrying out the method of the first aspect of the invention set out hereinabove. 
         [0037]    According to a third aspect of the present invention there is provided, in a computer system including a computer terminal, an operating system installed on said computer terminal, a virtual machine running on the operating system, a server communicatively coupled to the computer terminal and a process including instructions that when executed on a virtual machine define a user interface;
       a Single Sign On (SSO) system comprising:   a database of authentication credentials accessible to the computer terminal   instructions executable on the virtual machine, which instructions are operative to:
           obtain user interface state data from the process;   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 process.   
               
 
         [0044]    In one embodiment, wherein the process comprises a Java applet stored at the server, the applet includes said instructions to define a user interface, and the system further includes 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. 
         [0045]    In an alternative embodiment, wherein the process comprises a Java application, the application includes said instructions to define a user interface. 
         [0046]    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. 
     
    
     
       BRIEF DETAILS OF THE DRAWINGS 
         [0047]    In order that this invention may be more readily understood and put into practical effect, reference will now be made to the accompanying drawings illustrate preferred embodiments of the invention, and wherein: 
           [0048]      FIG. 1  is a block diagram illustrating the resources available to a user workstation via network connectivity as occurs in the prior art; 
           [0049]      FIG. 2  is a flow chart illustrating the operation of an SSO system as occurs in one example of the related art; 
           [0050]      FIG. 3  is a block diagram illustrating an application program running on an operating system, a Java applet running on a Virtual Machine inside a Web Browser and a Java application running on a standalone Virtual Machine; 
           [0051]      FIG. 4  is a block diagram illustrating the components of the software product of one embodiment of the present invention; 
           [0052]      FIG. 5  is a flow chart illustrating a high level view of the process carried out by the software product of one embodiment of the present invention; 
           [0053]      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 of the embodiment; and 
           [0054]      FIG. 7  is a flow chart illustrating the process whereby a component tree is obtained and manipulated. 
       
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0055]    Turning to  FIG. 4 , there is illustrated the user workstation  100 , which is a PC having conventional hardware  308 , on which an Operating System  302 , such as Microsoft Windows is running. Two application programs, being a web browser  310  and an SSO system  200  are running on the Operating System  302 . A virtual machine  304  such as the JVM is implemented within the web browser  310  that allows a Java applet  306 , downloaded from the Internet with a web page  410  to run on the user workstation. The applet  310  is written in the Java programming language and uses services provided by the virtual machine to perform its tasks and actually runs on the virtual machine  304  as a thread inside the browser process  302 . The program instructions of the applet will be converted by the virtual machine  304  into instructions that can be executed by the operating system  302 . The conversion process, however, is hidden from the applet  306  that needs only to call services that are provided by the virtual machine. In turn, the operating system  302  implements the necessary routines from the hardware  308  to execute the converted instructions. 
         [0056]    The task of the applet  306  in this example is to request the entry of a user name and password from the user of the workstation  100 , to allow the user access to resources provided at the web server from which the web page  410  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 the operating system  302  utilise APIs  412  provided by the operating system  302  to create such objects. In the case of Microsoft&#39;s 32 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, the operating system  302  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). 
         [0057]    However, in recent Java graphical user interface (GUI) frameworks only the browser  310  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 the Java applet  306  running inside the virtual machine  304 , 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 the SSO system  200 . 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. 
         [0058]    To provide access to this user interface state data, an Accessibility API  402  also runs on the virtual machine  304 . 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, Inc. 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 the SSO system  200  to pass data from a process running outside the virtual machine (“external data”) into the applet. 
         [0059]    The present invention works best with versions  6  and above of Microsoft&#39;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. 
         [0060]    An SSO Hook  400 , written in the Java programming language, also runs on the virtual machine  304  with the applet  306  and the Accessibility API  402 . The SSO Hook  400  can be registered with the Accessibility API  402  to obtain state data relevant to the applet  306 . Additionally the SSO Hook  400  also includes instructions for forwarding external data from the SSO System  200 , to the applet  306  by manipulating the state data obtained from the Accessibility API  402 . 
         [0061]    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 step  500 , the SSO System  200  causes the SSO Hook  400  to execute on the virtual machine  304  as a background process. User Interface State Data is then received at step  504  and examined by the SSO Hook  400 . At step  504  a test is carried out to determine whether the User Interface State Data defines a login opportunity related to the Java applet  306 , running on the virtual machine  304 . In the event that a login opportunity is defined the relevant authentication credentials are retrieved from the database  118  at step  506 . These credentials are then applied to the Java applet in step  508  to effect the authentication. 
         [0062]    The initial stage of the process commences when the SSO Hook  400  executes on the virtual machine  304  and this stage is illustrated in more detail by reference to  FIG. 6 . At step  600 , the SSO Hook  400  uses the Accessibility API to determine if there is any relevant user interface state data from the Java applet  306  running on the virtual machine  304 . 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 the SSO Hook  400  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, thread group, and accessible name. 
         [0063]    In the case of a Java application program  314 , 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. However it should be appreciated that the invention finds convenient use in relation to both Java application programs and applets. 
         [0064]    A test is performed at step  602  to determine whether the user interface state data received from the Accessibility API  402  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 at step  604 . 
         [0065]    The attribute data is obtained by querying the thread group of the top level window, which includes the full URL that completely specifies the directory containing the main Class file of the applet  306 . A correct URL of the applet is required to know which credentials from the database  118  to apply to the applet  306 . 
         [0066]    After the attribute data is dispatched to the applet  306 , the SSO Hook  400  is able to pass the authentication credentials to the applet  306  and thereby affect sign on to the resource. This process is described with reference to  FIG. 7 . The SSO Hook at step  1000  obtains a component tree from the attribute data. The component tree is obtained by querying the Virtual Machine  304  in a manner familiar to those skilled in the art. At step  1002  the component tree is manipulated by the SSO System Scripting Engine  408 . 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. This again is a process familiar to those skilled in the art and will not be further detailed here. 
         [0067]    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. 
         [0068]    It is to be understood that the above embodiments have been provided only by way of exemplification of this invention, and that further modifications and improvements thereto, as would be apparent to persons skilled in the relevant art, are deemed to fall within the broad scope and ambit of the present invention defined in the following claims.