This invention pertains generally to web services, and more specifically to using a proxy as an intermediary between web services and end-user applications.
The recent availability of new web service tools such as SOAP, WSDL, XML-RPC etc. has enabled rapid development and roll-out of complicated web service functionality. Prior to the availability of such tools, large web service projects such as online backup, central queuing, online product pricing, image storage and retrieval and online searching took long amounts of time, large programming teams and substantial financial investments to develop. As a result of the simplified development enabled by the new tools, more web services are available to end-users today.
It would be desirable to publishers of software applications to be able to provide these web services from within their applications. These web services, provided by companies such as Amazon and Google, generally require that the client have a unique identifier (“ID”) and a secret key that is to be included in or used to sign the service calls. It is not practical for software publishers to require that each of the millions of customers using their products obtain their own web service account with the provider. It is also undesirable from a business point of view, as the software application provider may want their customers to believe, for marketing purposes, that the web service is part of the application.
One solution would be for the software publisher to obtain a single key for a given web service, and use that key to call the service from each instantiation of the application on each customer's computer. Unfortunately, including the key in each copy of the application would make it impossible to secure this key in a way that would keep it confidential. Since each call to a web service typically results in a charge, publishers certainly do not want their key to become accessible to the general public. If that were to happen, dishonest parties could use the publisher's key to call the web service from contexts outside of the publisher's software, at the publisher's expense.
Additionally, using a web service from within an application involves exchanging data between the application and the web service. Since the publisher is responsible for the application, it would be desirable for the publisher to be able to filter such data, to ensure that it is secure or to add services as desired.
What is needed are methods, computer readable media and computer systems that allow a software publisher to call web services from within their applications, without compromising the security of their key. It would also be desirable if the publishers could filter content passed between their applications and the web services.
A proxy operates as an interface between application programs and web services. Each application uses a unique ID and key assigned by the publisher to interface with the proxy. The proxy itself uses a single, genuine ID/key pair for calling actual web services. Because only the proxy has the real web service key, that key remains secure and confidential.
The proxy receives requests for web services made by applications running on end-user's computers. The proxy is configured to handle these web services requests, using the same well defined Application Programming Interfaces (“APIs”) that the real web services use. The calls to the web services are made by the application programs using customer-unique software publisher generated ID/key pairs. The proxy then makes corresponding calls to the real web services, using the software publisher's own, genuine ID/key pair, and passes the results back to the applications.
The use of the proxy also allows filtering of the APIs input and output (parameters and/or data), for example to ensure end-users can only access the information they are authorized to see. Additionally, the proxy can provide value added services, such as scanning the data for malicious code, additional authentication or non-repudiation of the data, and/or other filtering operations as desired. These mechanisms can be used to filter the input and output of any web service.
The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
The Figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.
As illustrated in
The web service proxy 101 examines received requests 107. The proxy determines whether each received request 107 originates from a legitimate end-user application 105 that is authorized to make that particular web service request 107. Typically, the proxy keeps a list or the like of end-user applications 105 under its jurisdiction, their assigned ID/key pairs 109, and the web services 103 that they are allowed to access. If the request 107 is validated, the web service proxy 101 forwards a repackaged (or resigned) request 111 to the target web service 103 with the appropriate genuine web service ID/key pair 113.
The web service proxy 101 receives a corresponding response 115 from the web service 103 to which the repackaged request 111 was sent. The web service proxy 101 then transmits the received response 115 to the appropriate end-user application 105 that made the original request 107. As explained in greater detail below in conjunction with
It is to be understood that the web service proxy 101 can be centralized or distributed, and can run on one or more servers, clients or any other type of computing devices. It is to be further understood that the web services 103 in question have well defined Application Programming Interfaces (APIs), so that the application programs 105 can easily generate requests 107 thereto, and the proxy can create corresponding repackaged or resigned requests 111. For example, web services 103 that use WSDL, SOAP, or XML-RPC (e.g., Amazon and Google web services) have well defined APIs.
Turning now to
In some embodiments, each end-user application 105 is assigned a single ID/key pair 109 for all web services 103. In other embodiments, an application 105 is assigned a different ID/key pair 109 for each web service 103. Either way, these ID/key pairs 109 are only for use between the web services proxy 101 and the end-user 105. Depending upon the form of the request 107 expected by the web service, an end-user ID/key pair 109 can be either included in the request 107 itself, or used to sign the request 107 as appropriate.
It is to be understood that the term “ID/key pair” as used herein refers to whatever type of identifying and/or verification data is required by individual web services 103. As such, even where a web service 103 requires such data in a form other than a literal pairing of an identifier and a key (e.g., a key only, a user name and a password, a pair of keys, etc.), the term “ID/key pair” as used herein still encompasses such scenarios.
As illustrated in
To clarify the operation of an embodiment of the present invention, the use of a web service proxy 101 as an intermediary between an on-line backup end-user application 105 and Amazon's Simple Storage Service (S3) (an example of a web service 103) is described.
The publisher of the on-line backup application 105 creates an S3 account, and obtains a genuine API ID and secret key 113. The key pair generation tool 201 is configured to use the S3-ID/key pair 113 to generate end-user ID/key pairs 109. During installation of the on-line backup program 105 at an end-user site, the proxy 101 is contacted, and the generation tool 201 issues an ID/key pair 109 for the installed application program 105 (for example, ID=123, Key=ABC).
During its course of operation, the installed end-user application 105 issues requests 107 to the proxy 101, using its assigned ID/key pair 109. The requests 107 are filtered and repackaged by the proxy 101. The proxy then sends the filtered request 111 to the Amazon web service 103. Responses 115 from the web service 103 are received by the proxy 101, filtered and repackaged prior to being returned to the end-user application 105.
To better illustrate possible filtering activities, some specific examples within the context of S3 are provided. In one embodiment, when storing files being sent to or received from user applications 105, the proxy 101 could modify the filename to, e.g., “123-<original-file-name>”. The proxy 101 could then enforce size restrictions for all files named 123-*, based on the storage quotas allocated to various end-users 105.
As an extension to the above example, when an end-user 105 is browsing files, the proxy 101 could filter the provided view to include only files that begin with “123-”. For readability the proxy could strip the 123-designation from the data viewable by the end-user 105. Further, when retrieving or deleting files, the end-user 105 could only be given access to those named 123-*. Of course, these are only examples of filtering operations that are possible. Other examples will be readily apparent to those of ordinary skill in the relevant art in light of this specification.
The publisher could also charge small, per transaction, fees to third parties wanting to use the services 103, making the publisher the trusted intermediary in web service 103 communications.
As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies and other aspects of the invention can be implemented as software, hardware, firmware or any combination of the three. Of course, wherever a component of the present invention is implemented as software, the component can be implemented as a script, as a standalone program, as part of a larger program, as a plurality of separate scripts and/or programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Furthermore, it will be readily apparent to those of ordinary skill in the relevant art that where the present invention is implemented in whole or in part in software, the software components thereof can be stored on computer readable media as computer program products. Any form of computer readable medium can be used in this context, such as magnetic or optical storage media. Additionally, software portions of the present invention can be instantiated (for example as object code or executable images) within the memory of any programmable computing device. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.