Abstract:
Data can be securely passed between a client and a back-end resource by utilizing an intermediary or proxy that substitutes references for data and functions as if it were in fact a client. When sending service requests to a web-server on a publicly-accessible site, the intermediary replaces the data with references; when it receives references from the publicly-accessible site, it replaces those references with the actual data. At no time is actual data handled by a publicly-accessible site.

Description:
CROSS-REFERENCE TO RELATED APPLICATION  
       [0001]    This application claims the benefit of U.S. Provisional Application No. 60/115,835 filed Jan. 14, 1999, U.S. application Ser. No. 09/481,140, filed Jan. 12, 2000, and U.S. Provisional Application No. 60/211,256 filed Jun. 13, 2000, incorporated by reference herein. 
     
    
     
       BACKGROUND OF THE INVENTION  
         [0002]    In an on-line system, when data is retrieved from a remote resource, each intermediate point through which it travels may conceivably access the data. Even if such data is retrieved through a secure connection with a web server, the web server itself will be privy to the data. While the web server is beneficial in that it acts as intermediary between a client and a remote resource, it would be advantageous to utilize the services of the web server without having to compromise the data. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0003]    [0003]FIG. 1 is a block diagram of a system affording secure data transfer;  
         [0004]    [0004]FIG. 2 is a flow chart of a download procedure for the system of FIG. 1;  
         [0005]    [0005]FIG. 3 illustrates the flow of commands and data between the components of FIG. 1 for the download procedure of FIG. 2;  
         [0006]    [0006]FIG. 4 is a flow chart of an upload procedure for the system of FIG. 1; and  
         [0007]    [0007]FIG. 5 illustrates the flow of commands and data between the components of FIG. 1 for the download procedure FIG. 4. 
     
    
     DESCRIPTION OF THE INVENTION  
       [0008]    Secure transfer of data between a client and back-end resources over the Internet can be achieved in part by establishing a secure path between the two points. Formatting and protocol issues not requiring access to secure data can be delegated to conventional elements in the path.  
         [0009]    In one configuration, illustrated in the block diagram of FIG. 1, a client  10 , using an Internet browser  12  equipped with the means necessary to create a secure session, accesses a back-end system  20  on which a back-end resource  22  resides, through a client-accessible system  30 . The back-end resource  22  may be a database or some other source of data or device that the client wishes to access.  
         [0010]    The interconnection  14  between the client  10  and the client-accessible system  30  can be over a network such as the Internet or through some other medium. Similarly, the interconnection  16  between the client-accessible system  30  and the back-end system  20  can be over a network such as the Internet or through some other data link.  
         [0011]    An enabler  24  on the back-end system  20  functions as an interface between the back-end resource  22  and external connections to the back-end system  20 , such as the interconnection  16 . Information coming from or going to the interconnection  16  passes through the enabler  24  or, alternatively, passes to the back-end resource  22  under the direction and control of the enabler  24 .  
         [0012]    The data transfer process can be described in two parts: a download procedure (FIGS. 2 and 3), where data is transferred from the back-end resource to the client, and an upload procedure (FIGS. 4 and 5), where data travels from the client to the back-end resource. Either can be used alone, in concert with each other, or with other processes as appropriate.  
         [0013]    Download Procedure  
         [0014]    As shown in FIGS. 2 and 3, the client  10  initially accesses a web page for a download request. The page may be resident on the web server  32 , the back-end system  20 , or some other location. The client  10  may optionally insert a client-supplied value (or values) in the web page to complete the request and the request is then directed to the enabler  24  by way of a router  34 . A digital certificate or some other means may be used to determine and convey identity of the client  10  to the enabler  24 .  
         [0015]    If the response contains any client-supplied value(s), the enabler  24  stores them locally, i.e., on the back-end system  20 , and then creates one or more client-value references that function as a surrogate for those values. The enabler then modifies the request, incorporating any client-value references (instead of the client-value) and an authentication token, and sends the modified request to the web server  32 .  
         [0016]    The web server  32  in turn processes the request for a download, treating any client-value references it receives from the enabler  24  as data. It then sends a service request to the back-end system  20 . The service request may be received by the enabler  24  and, incorporating any client-value reference(s), the enabler  24  retrieves the corresponding client-supplied value(s), processes the request, and obtains the data sought by the client  10  from the back-end resource  22 . Alternatively, the back-end resource  22  may receive the service request directly. In that event, the back-end resource  22  will obtain the corresponding client-supplied value(s) from the enabler  24 , process the request, and obtain the data sought by the client  10 .  
         [0017]    If the enabler  24  receives the service request, the enabler  24  then stores the data locally (on the back-end system  20 ), responding to the web server  32  on behalf of the back-end system  20  with data reference(s) to permit later retrieval of the actual data. If however the back-end resource  22  receives the service request, the back-end resource  22  will then query the enabler  24  which in turn will store the data locally, and provide data reference(s) that the back-end resource  22  will send to the web server  32 .  
         [0018]    The web server  32  now formats a web page using the data reference(s) (instead of actual data) and sends this web page externally to the enabler  24 . The enabler  24  uses the data reference(s) to retrieve the data from the back-end system  20 , replaces the data reference(s) in the web page with the actual data, and sends the web page to the client  10 .  
         [0019]    In following the procedure outlined above, the web server  32  never sees any client data, neither values supplied by the client or data from the back-end resource  22 . To further insure security, the path between the client  10 , i.e., its browser  12 , and the enabler  24  via the router  34  can be made secure by utilizing a secure protocol such as SSL (“secure socket layer”). Similarly, the path between the web server  32  and the back-end system  20  (whether it be to the enabler  24  or the back-end resource  22 ) can utilize a secure protocol. The enabler  24  thus serves as an intermediary or proxy, appearing to the web server  32  as if it were in fact a “client,” as well as shielding data passing to and from the back-end resource  22  from the web-server  32 .  
         [0020]    Upload Procedure  
         [0021]    The procedure for an upload of data from the client  10  to the back-end system  20 , shown in FIGS. 4 and 5, is a subset of the download procedure just described. The client  10  initially accesses a web page on the web server  32  (or elsewhere) to request an upload. The client  10  inserts the data to be uploaded into the web page. The client  10  sends the data as part of an http (“hypertext protocol”) request, which is directed to the enabler  24 .  
         [0022]    In response to the request, the enabler  24  stores the client-supplied data locally, i.e., on the back-end system  20 , and then creates one or more data references that function as a surrogate for the data. The enabler  24  then modifies the request, incorporating the data references (instead of the client&#39;s data) and an authentication token, and sends the modified request to the web server  32 .  
         [0023]    The web server  32  in turn processes the request for a upload, treating the data references it receives from the enabler  24  as data. It then sends a service request to the back-end system  20 . There, it is intercepted by the enabler  24  and, using the data reference(s), the back-end system  20  retrieves the data and completes the service request, forwarding the data to the back-end resource  22 . Alternatively, the back-end resource  22  receives the service request and is assisted by the enabler  24  in obtaining the data to be uploaded.  
         [0024]    Finally, the back-end system  20  acknowledges receipt of the data, sending the acknowledgment to the web server  32 , which in turn forwards it to the enabler  24  and then on to the client  10 .  
         [0025]    As with the download procedure, the paths between the client  10  and the enabler  24 , and the web server  32  and the back-end system  20  can be secure.  
         [0026]    The method described here can also be utilized to assist in logging traffic to and from the back-end system  20 . Since the enabler  24  either receives every transaction or is monitoring the transactions, it can keep an audit log of all traffic in and out of the back-end system  20 , noting the content, origin, destination, time, and date.  
         [0027]    If desired, authentication can be performed using any method including the method described in provisional patent application No. 60/106,290, filed Oct. 30, 1998, and U.S. application Ser. No. 09/429,373, filed Oct. 28, 1999, both titled “Secure Authentication for Access to Back-End Resources,” and incorporated by reference herein.