Abstract:
Systems and methods for deploying rich internet applications in a secure computing environment. An example computer system comprises: a hardware processor and a run-time environment executing a first rich internet application in a first application container and a second rich internet application in a second application container. The run-time environment is configured to: determine, by querying an administration server, whether at least one of the first rich internet application or the second rich internet application is allowed to be executed within the run-time environment, determine whether at least one of the first rich internet application or the second rich internet application is allowed to access a certain function exposed by an application-programming interface (API) of the run-time environment, implement a client-side messaging bus to facilitate communications between the first rich internet application and the second rich internet application, and prevent at least one of the first rich internet application or the second rich internet application from terminating the run-time environment.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 14/205,573 filed on Mar. 12, 2014, which claims the benefit of U.S. Provisional Application No. 61/781,746, filed Mar. 14, 2013. Both above-referenced applications are incorporated herein by reference in their respective entireties. 
     
    
     BACKGROUND 
       [0002]    In enterprise computing environments, end users&#39; computers are usually managed by IT administrators. For security and maintenance reasons, users typically do not have administration rights on their computers. This prevents them from installing applications on the computer directly and instead applications are deployed centrally by administrators through what is referred to as an application packaging process. 
         [0003]    In the financial industry, for example, firms such as banks and hedge funds have strict security and compliance policies. Users are prevented from installing applications on their computers to protect against potential security threats. Before an application is packaged and deployed to a user&#39;s computer, most firms conduct an IT security review to ensure that the application meets security and compliance standards. Similar processes are followed to update an application that was previously installed on a user&#39;s computer. 
         [0004]    Such application deployment processes create two significant problems for application developers. First, IT security reviews and application packaging processes can take months to complete, causing delays in deploying the application to users. Second, different firms deploy and update applications at different times, requiring application developers to simultaneously support multiple versions of their application. This is particularly a problem for internet-based applications such as trading applications where users from different firms interact with one another through the application and therefore usually need to be using the same version of the application. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0005]    The present disclosure is illustrated by way of examples, and not by way of limitation, and may be more fully understood with references to the following detailed description when considered in connection with the figures, in which: 
           [0006]      FIG. 1  shows an exemplary deployment of a rich internet application (RIA)  300  using the run-time environment  100  which is managed by an administration server  160 ; 
           [0007]      FIG. 2  shows an exemplary application container  200  with various graphical user interface components; 
           [0008]      FIG. 3  shows an exemplary multi-application architecture of the run-time environment which isolates RIAs  300  from one another and allows secure communication through a inter-application messaging bus  320 ; 
           [0009]      FIG. 4  shows a flowchart of an exemplary process for launching the run-time environment  100 ; and 
           [0010]      FIG. 5  shows an exemplary network diagram where the run-time environment  100  has been installed on multiple desktop computers 600 and multiple RIAs  300  are deployed to the different instances of the run-time environment  100 . 
       
    
    
     DETAILED DESCRIPTION 
       [0011]    In secure enterprise computing environments, developers of internet-based applications often build rich internet applications (RIAs) to solve application deployment problems. RIAs support many of the features of installed applications such as rich graphical interfaces and popup notifications. However, RIAs differ from installed applications in two important respects. First, RIAs are typically deployed from a central server and are usually updated automatically each time a user attempts to access the application. This means users across different firms are always using the same (i.e. latest) version of the application. Second, RIAs typically execute in run-time software which restricts the application inside what is referred to as a security sandbox. This prevents the application from directly accessing the user&#39;s computer and protects the computer from security threats. 
         [0012]    In the financial industry, developers of trading applications and other real-time desktop applications use several different RIA technologies including Java WebStart, Adobe Air and Microsoft ClickOnce. While these run-time technologies improve application deployment, they have a number of important deficiencies that are needed in secure enterprise computing environments. First, once the run-time software is installed on a user&#39;s computer, a user has the ability to freely access any supported application available on the internet. This circumvents IT security policies designed to ensure that users only access authorized applications. Second, run-time technologies typically allow an application to request permission from a user to access resources outside of the security sandbox. For example, an application may request to save a file on the user&#39;s computer, potentially exposing the computer to a virus. Third, run-time technologies don&#39;t provide a method for an IT administrator to easily disable features of the run-time software. This may be needed if the IT administrator considers a particularly feature to expose a security threat. Fourth, run-time technologies don&#39;t authenticate the identity of a user. This requires each application to separately authenticate each user. Fifth, run-time technologies don&#39;t maintain a record of the applications a user accesses and the actions a user performs while using the application. This is critically important for creating audit trails required by government regulations, including those regulating the financial industry. Sixth, run-time technologies don&#39;t provide a method for different applications running on the same user&#39;s computer to communicate and integrate with one another. This is needed in any environment where there are multiple related applications that have a need to share information. 
         [0013]    To address these significant problems, a new technology is needed that can provide necessary controls to IT administrators, simplify application deployment for developers and enable integration between applications. 
         [0014]    Described herein are systems and methods for deploying rich internet applications (RIAs) into a desktop computing environment managed by IT administrators. The techniques described provide significant improvements over existing techniques of application deployment in secure enterprise computing environments. The improvements include better security, faster time-to-market, lower cost of deployment and enhanced user experience. 
         [0015]    The system includes a run-time environment, a run-time API, and an administration server. The run-time environment is used for deploying and running RIAs using strict security controls including user authentication, application authorization, application audit, permissioned access to run-time functionality and application isolation. The run-time environment also enables secure, client-side messaging between RIAs. The run-time API provides a programming interface that can be used by an RIA to access run-time functionality. The administration server is used by a central administrator to manage user authentication, application authorization, application audit and run-time API permissions. 
         [0016]    Further described herein is a method for deploying RIAs to end users&#39; computers managed by IT administrators. The method includes installing the run-time environment on one or more end users&#39; computers. Each instance of the run-time environment is configured to communicate with an administration server. The administration server is configured to associate a user of the run-time environment with RIAs that the user has been authorized to access. The administration server is also configured to allow or disallow each RIA from accessing different functionalities of the run-time environment. 
         [0017]    In certain implementations, each RIA runs in a separate isolated process. This prevents each RIA from harming other RIAs running in the run-time environment and also prevents the RIAs from harming the computer. The RIAs, though isolated in separate processes, are able to communicate securely with one another using a client-side inter-application messaging bus. This enables RIAs to be integrated with one another in order to provide an enhanced user experience. 
         [0018]    In certain implementations, actions performed by a user or an RIA are audit by an audit service within the run-time environment. The audit service captures audit information and can store audit information on the end user&#39;s computer as well as deliver the audit information to the administration server. This streamlines the collection of audit information and provides additional tools to central administrators. 
         [0019]    The present document describes systems and methods for deploying rich internet applications (RIAs) into a desktop computing environment managed by IT administrators. The techniques described provide significant improvements over existing techniques of application deployment in secure enterprise computing environments. The descriptions below should be read in conjunction with the accompanying drawings  FIG. 1 through 5 . 
         [0020]    The system comprises one or more computers 600 (including, e.g., desktop and/or portable computers) each running one or more instances of the run-time environment  100 . The run-time environment  100  is managed centrally, through secure network connections, by one or more administration servers  170 . The run-time environment  100  interacts via network connections with one or more application servers  500  which each host one or more RIAs  300 . An exemplary system is depicted in  FIG. 5 . 
         [0021]    Referring to  FIG. 1 , an exemplary run-time environment  100  includes a user authentication service  110 , an application authorization layer  120 , a run-time API permissions layer  130 , an audit service  140 , and a run-time engine  150 . The run-time environment  100  may or may not include each of these components. In one embodiment, the run-time environment  100  includes a user authentication service  110  and a run-time engine  150 . In another embodiment, the run-time environment  100  further includes a run-time API permissions layer  130  and a run-time engine  150 . 
         [0022]    A user authentication service  110  provides a process for authenticating the identity of a user when the run-time environment  100  is launched. In one embodiment, the user authentication service  100  communicates with an administration server  170  to perform the authentication. In another embodiment, the user authentication service  100  receives credentials from the computer&#39;s 600 operating system. 
         [0023]    The application authorization layer  120  provides controls to allow or disallow an RIA  300  to run in the run-time environment  100 . Authorizations are provided by a central administrator via the administration server  170 . In one embodiment, the authorizations are managed directly on the administration server  170  through an online dashboard. In another embodiment, authorizations are updated on the administration server  170  through an API that connects the administrator server  170  to another system. 
         [0024]    The run-time API permissions layer  130  provides controls to allow or disallow an RIA  300  to access certain functionalities from being used within the run-time environment  100 . For example, using the run-time API permissions  130  an RIA  300  can be prevented from performing an exit action that would cause the run-time environment  100  to stop executing. In another example, using the run-time API permissions  130  an RIA  300  can be prevented from storing files on the computer&#39;s 600 file system. Permissions are provided by a central administrator via the administration server  170 . In one embodiment, the authorizations are managed directly on the administration server  170  through an online dashboard. In another embodiment, authorizations are updated on the administration server  170  through an API that connects the administrator server  170  to another system. 
         [0025]    The audit service  140  captures user actions such as launching or closing an application, moving or resizing windows and mouse click events. In one embodiment, the audit service  140  stores audit information on the computer&#39;s 600 file system and periodically sends audit information to the administration server  170 . In another embodiment, the audit information is delivered in real-time to the administration  170  as it is being captured. 
         [0026]    The run-time engine  150  is responsible for execution of one or more RIAs  300  as well as displaying of the graphical user interface of each RIA  300 . In one embodiment, the run-time engine  150  is a WebKit-based rendering engine such as Google Chromium. 
         [0027]    The run-time API  160  provides programming interfaces use by an RIA  300  to access certain functionalities of the run-time environment  100 . For example, the run-time API  160  may provide programming interfaces for showing or hiding a window. In another example, the run-time API  160  may provide programming interfaces for displaying a notification or alert. The run-time API  160  is incorporated into an RIA  300  by a software developer. In different embodiments, the run-time API  160  is written in different programming languages including JavaScript, Java, ActionScript, C++ and C#. 
         [0028]    The administration server  170  is comprised of one or more central servers that communicate securely with the run-time environment  100  and allow central administrators to access and manage various components of the run-time environment  100  including the user authentication service  110 , the application authorization layer  120 , a run-time API permissions layer  130  and an audit service  140 . 
         [0029]    The application server  500  is comprised of one or more servers responsible for hosting one or more RIAs  300 . The run-time environment  100  is able to simultaneously execute different RIAs  300  each being hosted by a different application server  500 . In one embodiment, the application server  500  is a web server like Apache Tomcat. 
         [0030]    Referring to  FIG. 2 , when executing in the run-time environment, each RIA  300  runs in a separate application container  200 . In an exemplary embodiment, an application container  200  is a collection of one or more top-level graphical user interface (GUI) components such as windows  210 , gadgets  220  and notifications  230  that are part of the RIA. A window  210  is a GUI component that can be resized, moved, minimized, restored, hidden and shown. A gadget  220  is a GUI component that is usually small and used for a single-screen, single-purpose application or widget. A gadget  220  usually remains on the desktop and is not minimizable or resizable. A notification  230  is a GUI component that usually displays for a short period of time and usually with motion in order to visually capture a user&#39;s attention (for example to alert the user about a time-sensitive event). The implementation of an RIA  300  inside an application container  200  enables the RIA  300  to have multiple GUI components which execute and stop executing in unison. This is an important feature of native or installed applications that differentiates them from browser-based applications which typically execute inside a single window or tab. 
         [0031]    Referring to  FIG. 3 , RIAs  300  are isolated from one another when executing in the run-time environment  100 . This prevents each RIA  300  from harming another RIA  300  or the computer 600 and is an important part of the security model described herein. In an exemplary embodiment, depicted in  FIG. 3 , the RIA isolation is effected by running each RIA  300  in a separate operating system process  310 . 
         [0032]    Still referring to  FIG. 3 , in certain implementations, RIAs  300  are able to securely communicate with one another via an inter-application messaging bus  320 . Each RIA  300  connects securely to the inter-application messaging bus  320 . Once connected, the RIA  300  is able to send messages via the inter-application messaging bus  320  and those messages can be received by other RIAs  300  also connected to the inter-application messaging bus  320 . In one embodiment, the inter-application messaging bus is a WebSocket server that is part of the run-time engine  150  and each RIA  300  connects securely to the WebSocket server by establishing a WebSocket connection. 
         [0033]    Referring to  FIG. 1  and  FIG. 3 , in certain implementations, application authorizations  120  may be used to allow or disallow one RIA  300  from communicating via the inter-application messaging bus  320  to another RIA  300 . This provides further security to prevent one RIA  300  from harming another RIA  300  via the inter-application messaging bus  320 . In one embodiment, application authorizations  120  related to the inter-application messaging bus  320  are provided by the administration server. In another embodiment, application authorizations  120  related to the inter-application messaging bus  320  are provided by each RIA  300  interacting with its application server  500 . 
         [0034]    Described herein are methods for deploying RIAs  300  in a secure desktop computing environment. This can be done by first performing the following setup. First, install the run-time environment  100  on a computer 600 and associate the run-time environment  100  with an administration server  170 . Next, configure the administration server  170  to provide authorization for one or more users to access one or more RIAs  300 . Once the setup has been completed and the user launches the run-time environment  100 , perform the following steps described in  FIG. 4 . First, the run-time environment  100  establishes a secure connection to the administration server S 400 . Next, the run-time environment  100  uses its user authentication service  110  to authenticate the identity of the user S 410 . If the user cannot be authenticated, the run-time environment  100  does not allow the user to proceed to the next step. Next, the run-time environment  100  sends a request to the administration server  170  to send information needed to create and launch each RIA  300  which the user has been authorized to access S 420 . Next the run-time environment  100  uses the information received from the administration server  170  to load and run each RIA  300 . 
         [0035]    Unless specifically stated otherwise, terms such as “updating”, “identifying”, “determining”, “sending”, “assigning”, or the like, refer to actions and processes performed or implemented by computer systems that manipulates and transforms data represented as physical (electronic) quantities within the computer system&#39;s registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. 
         [0036]    Examples described herein also relate to an apparatus for performing the methods described herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer system selectively programmed by a computer program stored in the computer system. Such a computer program may be stored in a computer-readable non-transitory storage medium. 
         [0037]    The methods and illustrative examples described herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used in accordance with the teachings described herein, or it may prove convenient to construct more specialized apparatus to perform the methods and/or each of their individual functions, routines, subroutines, or operations. The required structure for a variety of these systems will appear as set forth in the description above. 
         [0038]    The above description is intended to be illustrative, and not restrictive. Although the present disclosure has been described with references to specific illustrative examples and embodiments, it will be recognized that the present disclosure is not limited to the examples and embodiments described. The scope of the disclosure should be determined with reference to the following claims, along with the full scope of equivalents to which the claims are entitled.