WO2010017828A1

WO2010017828A1 - Secure browser-based access to web services

Info

Publication number: WO2010017828A1
Application number: PCT/EP2008/006721
Authority: WO
Inventors: Luigi Lo Iacono; Hariharan Rajasekaran
Original assignee: Nec Europe Ltd.
Priority date: 2008-08-14
Filing date: 2008-08-14
Publication date: 2010-02-18

Abstract

The present invention relates to a method for providing a secure end-to-end communication between a thin client (2) on a first host and a Web Service (5) provided on a second host in a packet-switched network. The method comprising the step of establishing a communication between the thin client (2) on said first host and a Web portal (3) on a third host, wherein said Web portal (3) provides (access) information regarding the said Web Service (5). An integrated thin client extension (42) serving as Web Service client (42) on said first host is provided, wherein said thin client extension (42) provides the framework for establishing the secure policy-based end-to-end communication between the thin client (2) and the Web Service (5). Finally, the secure policy-based end-to-end communication between the thin client (2) and the Web Service (5) is established via the thin client extension (42).

Description

SECURE BROWSER-BASED ACCESS TO WEB SERVICES

The present invention relates to a method, and a system for providing an end-to-end secure connection between thin clients such as browsers and Web Services. In particular, according to the present invention a secure end-to-end connection is preferably provided by a browser extension such as a plug-in which may be downloaded on to the browser when accessing the concerned Web Service(s).

Background of the invention

Service Oriented Architecture (SOA) is a software architecture where functionality is grouped around business processes and packaged as interoperable services. SOA also describes IT infrastructure which allows different (possibly heterogeneous) applications to exchange data with one another as they participate in business processes. In order to use the vast opportunities provided by SOA-based systems, to remain competitive and to be prepared for future business models, enterprises need to be open for dynamic collaborations to facilitate, the access and utilization of internal, external and shared resources in an on-demand and transparent manner.

"Web Services" (Web Service or WS) can be used to implement a Service Oriented Architecture. A major focus of Web Services is to make functional building blocks accessible over standard Internet protocols that are independent from platforms and programming languages. A Web Service can provide information, e.g. a weather forecast service, or it may have an effect in the real world, e.g. an online flight booking service. Web Services can significantly increase the Web architecture's potential, by providing a way of program communication, discovery of services, etc.

A Web Service is defined by the W3C (World Wide Web Consortium) as "a software system designed to support interoperable Machine to Machine interaction over a network". Web Services are frequently just Web APIs (Application Programming Interface) that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services.

A Web Service exposes its functions via methods. A Web Service Definition Language (WSDL) file describes what a Web Service can do, where to find it and how to invoke the methods offered by it (see e.g. a definition of the Web Services Description Language (WSDL) Version 2.0 at: http://www.w3.org/TR7wsdl2O/). Web Services communicate using the Simple Object Access Protocol (SOAP) messages (which are based on XML (Extensible Markup Language)), i.e. the request for a method should be a SOAP request from a client and the Web Service will return the result of the method with a SOAP response (SOAP: see http://www.w3.org/2000/xp/Group/). The SOAP messages are commonly carried using the HTTP protocol. An introduction to Web Services architecture can be found in: Web Services Architecture; http://www.w3.org/TR/ws-arch/.

Security is a major consideration in these environments, since they are dealing with resources that are provided and managed by separate organizational entities across domain boundaries. Thus, when instantiating SOA-based systems with Web Services technology, a bunch of specifications and standards exists to implement adequate security mechanisms. These are, however, only applicable between full-fledged Web Service clients and services.

In the case where the client is realized as a combination of a Web portal and a browser- based thin client, the end-to-end Web Service link is interrupted, i.e. there exists no direct end-to-end communication between the browser and the Web Service (see e.g. Figure 1). This is especially an issue for security systems in such environments, since they need to rely on some form of proxy for enforcing security policies to the Web Services layer.

Providing end-to-end security between thin clients such as Web browsers and Web Services (direct connection between the thin client and the Web Services) is currently not feasible due to the lacking support for Web Service security specifications in Web browsers. Already the current SOAP APIs (Simple Object Access Protocol; Application Programming Interface) offered by the major browsers are incompatible with one another making the task of providing a uniform solution to address this problem difficult.

Using a Web browser, which comes installed on practically every machine, to access Web Services eliminates the need for installing dedicated clients and hence provides all the advantages of thin clients. Numerous general portal systems as well as specific portal solutions exist which underlines the demand for such a technology.

A thin client environment offers a convenient and efficient way, in terms of overall management effort, to provide access to service-based systems, but has its own limitations.

During the early years of Web Services, Web browsers did not have the ability to send SOAP

^' messages and hence an intermediary was required to handle this transformation from HTTP (HyperText Transfer Protocol) requests triggered by the browser to a SOAP request that a

Web Service can understand and vice versa.

This is usually done by a component (the WS-client) within the Web Portal as shown in Figure 1. For instance, user 1 uses a Web browser 2 on his computer (first host) to communicate via HTML/HTTP (HyperText Markup Language/Hypertext Transfer Protocol) with a Web Portal 3 (on a third host). A security card 11 may be used for user authentication (strong two-factor authentication). The Web browser 2 and the Web Portal 3 are provided on different computers. A Web Service client 4 (WS-Client) is installed within the Web portal 3 in order to send/receive SOAP messages to/from the Web Services 5. In other words, the Web Service client 4 is used to transform the HTTP requests triggered by the Web browser 2 to a SOAP request that a Web Service 5 can understand and vice versa. Such an approach obviously breaks the (direct) end-to-end Web Service link between the Web browser 2 (the thin client) and the Web Service 5 and hence has the drawback of the unavailability of end-to- end message security. In other words, the intermediate Web portal provides a safety risk and the overall system the lack of expressing and enforcing security policies from end to end.

In the following the terms "Web browser" and "browser" will be used synonymously. Moreover, the term "end-to-end" (SOAP) connection refers to a "direct" connection between two hosts without the need of an additional host in-between for HTTP-SOAP transformation. In other words, a direct or end-to-end (SOAP) connection between a thin client on a first host and a Web Service on a second host means that the thin client and the Web Service may establish a direct (SOAP) connection without the need of an additional Web Service client on a third host in-between. However, a direct or end-to-end connection between a thin client and a Web Service may comprise in a packet switched network a plurality of hosts in-between if these additional hosts are merely used for the routing through the Internet and are not required as a Web Service client.

In general, SOAP messages are secured using mechanisms described by WS-Security which includes e.g. signing the body of the SOAP message (see e.g. WS Security Specification: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss).

A security architecture in a browser-based access to Web Services as known from the prior art is shown in Figure 2. In cases, where the Web Service 5 is accessed via a Web portal 3, some form of security proxy 6 does the SOAP message security with its incorporated WS- client. The proxy 6 might use its own credentials to enforce the security policies or when the security mechanisms need to be performed using the user credentials, current solutions make use of proxy based solutions, where the Web portal 3 is granted access to the private key of the user 1. The online credential repository system MyProxy tries to overcome this problem by providing proxy credentials derived from the long term private key of the user 1 to Web Services 5 to enable them to consume other services on behalf of the user (see e.g. Jason Novotny, Steven Tuecke, Von Welch. An Online Credential Repository for the Grid: MyProxy). Such solutions, though convenient in some aspects, present a major risk from a security point of view.

Another way to provide such functionality wυuld be to enable SOAP message security within the Web browser augmented with security tokens such as SAML (Security Assertion Markup Language) assertions. Though such solutions are available currently for the server side (see e.g. WSo2 Web Services Framework; http://dist.wso2.Org/products/wsf/php/l.0.0/), such support inside the browser is currently missing.

To enable end-to-end message security in browser based access to Web Services, the

Web Services technologies and more specifically the Web Services security technologies need to be introduced directly into the browser. This has been improved in the current version of

Web browsers which offer some form of SOAP API which can be used by scripts embedded in the HTML page to send SOAP messages directly from the browser (see Figure 3).

For example, the Web browser Mozilla™ starting from version 1.0 offers such functionality ^via its SOAP APT (see http://lxr.mozilla.org/) and Internet Explorer version 5 offers a similar API via its DHTML (Dynamic HTML) WebService Behaviour (see e.g. http://msdn2.microsoft.com/en-us/library/ms531032.aspx). In both cases, a JavaScript code in the Webpage intercepts user actions and calls the underlying APIs to convert the information gathered via HTML forms into SOAP messages relevant for the called Web Service.

For instance, the Web browser 2 in Figure 3 communicates via the Web portal 3 and the WS-Client 4 within the Web portal 3 with the Web Service 5. The communication between the Web browser 2 and the Web portal 3 is based on HTML/HTTP. The communication between the WS-Client 4 and the Web Service 5 is based on SOAP/HTTP. The WS-Client 4 transforms the requests from the Web browser 2 from a HTTP request to a SOAP request that the Web Service 5 can understand and vice versa (the message direction form the Web Service to the Web browser). This connection is preferably used when security requirements are low, i.e., this communication may be insecure.

However, for security reasons it is preferred to establish a secure and preferably direct (end-to-end) connection between the Web browser 2 and the Web Service 5. Since the Web Service 5 communicates via SOAP, there is an additional component required in the Web browser which provides SOAP capabilities. An additional WS-Client 41 (see Fig. 3) is running on the Web browser 2 to establish direct (end-to-end) communicate via SOAP/HTTP between the Web browser 2 and the Web Service 5.

This approach is, however, inflexible due to the different APIs used in the different browsers (even though the SOAP message they send out to the Web Service is the same). In addition, the way in which the returned SOAP message is interpreted also varies based on the browser type. This leads to the problem where the JavaScript code that interacts with the underlying API needs to be customized based on the type of browser the user uses to access the Web application. In other words, the Web Service has to provide a plurality of different APIs for the different browser types.

One way to overcome this problem (different browsers - different APIs) is to use an AJAX based solution described in: "Call SOAP Web Services with Ajax; http://www.ibm.com/developerworks/webservices/library/ws-wsajax"/. With this approach, the SOAP processing is not realized by browser built-in functionalities, but as JavaScript operations for creating SOAP messages and using the xmlHttpRequest API for communicating with the Web Service. However, this approach as well as the ones based on the browser-specific SOAP APIs do not provide any security means such that the SOAP/HTTP connection between the Web browser and the Web Service does not fulfill security stάuusrds. It is therefore an object of the present invention to provide an improved method and system for a simplified and preferably secure end-to-end communication between a thin client and a Web Service.

This and other objects are achieved by the features of the independent claims. Further preferred embodiments are characterized in the dependent claims.

SUMMARY OF THE INVENTION

The method and the system according to the present invention refers to a new approach which allows e.g. browser-based thin clients to become "full-fledged Web Service clients", which enables the Web browser to access Web Services directly. With the method and the system according to the present invention security policies may be enforced directly within the browser. Unlike conventional approaches, the present invention enables the Web browser to enforce security policies relating to the Web Service layer directly and henceforth does not need to rely on intermediate systems or proxies. This enables the implementation of security solutions even for environments with high security requirements allowing for example the integration of (personalized) smart cards with other security tokens. Moreover, the present invention allows for a variety of policy management options ranging from a portal-wide policy which can be specialized for each provided function or for each registered user. Furthermore, unlike some conventional implementations the present invention presents a generic Web browser enhancement and allows the easy integration into Web portals even in existing portal deployments which respect the portal-specific development process and roles. In this context, the present invention for example does not demand Web browser specific coding in the Web applications business or presentation layers.

In particular, the present invention relates to a method for providing a secure end-to-end communication between a thin client (preferably provided on a first host) and a Web Service (preferably provided on a second host) in a packet-switched network like the Internet. The method comprises preferably the following steps.

First, a communication between the thin client- and the Web portal is established, wherein the Web portal provides information regarding the said Web Service, preferably access information regarding the Web Service. Additionally, or alternatively, the Web portal may provide information regarding services provided by the Web Service. The information provided by said Web portal may further comprise security policies of said Web Service.

A thin client extension, preferably an integrated thin client extension, is provided which serves as Web Service client (WS-Client) on said first host, wherein said thin client extension provides the framework for establishing a secure, preferably policy-based, end-to-end communication between the thin client and the Web Service. This overcomes for instance the limitations of the "same host policy" of Web browsers.

Afterwards, a secure and preferably policy-based end-to-end communication between the thin client and the Web Service is established via the thin client extension. In other words, a secure end-to-end communication or direct connection is established between the thin client on the first host and the Web Service on the second host. It should be pointed out that the first step of establishing a communication between the thin client and the Web portal in order to retrieve information may be omitted in case that the required information regarding the Web

Service is already known by the thin client, e.g., based on previous connections. The thin client is preferably a Web browser. Such a Web browser is typically available on every computer, handheld computer like a Personal Digital Assistant (PDA) or a mobile phone, etc. The thin client extension is preferably a plug-in, e.g. in case the thin client is a

Web browser, preferably a Web browser plug-in. The thin client may also be provided as a native plug-in or as a program running in a particular browser plug-in such as an Java Applet executed by a Java plugin or ActionScript executed by a Flash plugin.

The thin client extension may be provided on a storage medium (like CD, DVD, USB- memory stick, flash memory) or may be provided over the network. According to a preferred embodiment of the invention, the thin client is provided by the third host such that it can be downloaded from said host. Typically, the extension needs not to be downloaded for each access to a Web Service, e.g., according to a preferred embodiment the extension is downloaded once for each session. According to a further preferred embodiment, an extension may be used for more than one session, e.g., before starting the session it is verified whether the available extension on the first host is suitable for establishing a secure end-to-end connection.

The framework for establishing the secure and preferably policy-based end-to-end communication is preferably compliant to Web Service security standard specifications. Preferably, said framework for establishing the secure end-to-end communication allows direct addressing of a security proxy from the thin client, wherein said security proxy is preferably executed on a different host as the thin client. However, according to another embodiment, the security proxy may be provided on the same host on which the thin client is running.

The secure end-to-end communication between the thin client and the Web Service may be established via SOAP communication, preferably via SOAP/HTTP. The thin client extension is preferably a Web browser plug-in which is preferably customized individually for the specific Web browser. For instance, a Web browser plug-in may be customized especially for Firefox™, whereas another Web browser plug-in may be customized for Safari™ or Internet Explorer™. In other words, there may be provided different thin client extensions for the different available Web browsers. It is further preferred that the different thin client extensions for the different Web browsers communicate with the Web Service via a common interface technology. In other words, it is sufficient when the Web Service provides only one interface for the communication. The specific differences of the Web browsers are compensated by the different thin client extensions which are adapted to the specific thin clients or Web browsers. It is further preferred that the thin client extension is addressed by thin client specific commands. In other words, the thin client extension is preferably adapted to the specific thin client.

The thin client extension comprises preferably at least two operations for the communication between the thin client and the Web Service, hi particular, in the following the first operation is the operation for sending information from the thin client to the Web Service, whereas the second operation is the operation for receiving information from the Web Service, i.e. the first operation refers to the direction from the thin client to the Web Service whereas the second operation refers to the direction from the Web Service to the thin client. According to a preferred embodiment, the first operation gathers data input from the thin client and executes thin client extensions for sending the data input to the Web Service. In other words, a user may fill out a form in a Web browser. By pressing the submit button, the first operation gathers the data from the Web browser form and processes the data such that the thin client extension sends the data directly to the Web Service, preferably under consideration of the security policies.

According to a further preferred embodiment, the second operation executed in the thin client extension gathers or receives data from the Web Service and processes the data such that the thin client is able to display the data received from the Web Service. For instance, data are transmitted from the Web Service to the thin client via SOAP. However, the thin client without thin client extension would not be able to decrypt, verify and display the data.

The thin client extension "between" the Web Service and the thin client is able to decrypt, validate and interpret the received data and transforms the data by the second operation into data which can be displayed by the thin client (as far as the received data could have been decrypted as well as verified as authentic according to the security polcies).

The method and system according to the present invention is preferably adapted to fulfil certain security requirements. In particular, there is preferably a security system for providing a secure policy-based end-to-end communication between the thin client on a first host and the Web Service provided on a second host. The present invention also relates to a computer program product directly loadable into the internal memory of a digital computer. The computer program product preferably comprises software code portions for performing the above mentioned method steps when the product is run on a computer.

The method and system according to the present invention provides advantages over the existing solutions by extending a Web browser with Web Service capabilities, preferably with a suitable plug-in which preferably includes Web Service Security (WSS).

Preferably the plug-in according to the present is provided for each of the major browsers, but preferably provides on the other hand a unique interface to the Web Service enhancements so that the code included into the Web pages does not need to recognize distinct browsers and their specific peculiarities. The solution according to the present invention minimizes therefore platform dependent parts by isolating them into the Web browser plug-in (Java Applet).

It is further preferred that the system and method according to the present invention, in particular by means of the plug-in according to the present invention, allows introducing SOAP message security by also relying at the client's security capabilities such as the local certificate store or even smart cards. With the method and system according to the present invention the Web Service Security requirement may be fulfilled.

Further preferred advantages of the present invention may be briefly summarized as follows.

The system and method according to the present invention preferably enables end-to- end Web Service link in Browser/Portal-based environments.

The system and method according to the present invention preferably enables end-to- end security link in Browser/Portal-based environments. The system and method according to the present invention preferably provides a solution for high-level security environments supporting for example the use of smart cards.

The system and method according to the present invention preferably provides a generic browser extension which can be applied to any portal system and application system running on the portal. The system and method according to the present invention is preferably easy to integrate. In particular, it may be sufficient that portal application developers provide two specific JavaScript operations for user input gathering and response output.

The system and method according to the present invention preferably provides preferably a fine-grained policy management (policy global for the portal, policy specific to one function provided by the portal, policy specific to one user).

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described in detail with respect to preferred embodiments with reference to accompanying drawings, wherein:

Fig. 1 shows a browser based access to Web Services as known from the prior art;

Fig. 2 shows a security architecture in a browser based access to Web Services as known from the prior art; Fig. 3 shows a browser with build-in Web Service capabilites as known from the prior art; Fig. 4 shows a Web Services client with a browser plug-in accoring to the present inventio; and

Fig. 5 shows a prefered embodiment according to the present invention. DETAILED DESCRIPTION OF THE INVENTION

The present invention provides methods and systems for improved and preferably secure end- to-end communication between a thin client (e.g. Web browser) and Web Services. The present invention provides advantages over the existing solutions described beforehand by extending the browser with Web Service capabilities with an suitable plug-in which preferably also includes Web Service Security (WSS).

Figure 4 shows an example of a preferred embodiment according to the present invention. A user 1 uses a thin client in form of a Web browser 2 on his computer to establish a connection to a Web portal 3, wherein the Web portal 3 provides information on the available Web Service(s) 5. The user may therefore access the Web Service 5 via a web portal 3 as done in the art. However, when personal or important information are to be transmitted from the user to the Web Service 5, it is preferred to bypass the Web portal 3. The present invention provides a thin client extension, e.g. in form of a browser plug-in, which supports such a bypass by allowing an end-to-end connection between the Web browser 2 and the Web Service 5. The plug-in serves as a WS-client 42 which is embedded within the local Web browser. The plug-in may be provided for downloading either from the Web portal or the Web Service. According to a further preferred embodiment, the plug-in may also be provided by a storage medium such as a CD, DVD of a device with a flash memory. The system and method according to the present invention on the one hand provides a plug-in, preferably customized for each of the major browsers, but the solution of the present invention provides on the other hand a unique interface to the Web Service enhancements so that the code included into the Web pages of the Web Service does not need to recognize distinct browsers and their specific peculiarities. Moreover, the system and method of the present invention allows introducing SOAP message security by also relying at the client's security capabilities such as the local certificate store or even smart cards 11.

A prototype implementation for the method and system according to the present invention has been realized by using the Java Applet technology for the plug-in (see Figure 5). In the embodiment of Figure 5 simple and light-weighted frameworks for Web Services 5 and Web Service Security has been selected to keep the overall size of the applet moderate and to avoid the composition of the applet by numerous support libraries. The applet is not limited to Java Applets and the Web Service Client 42 may be based on other applet languages.

The applet may be preferably placed within an HTML frame of the Web portal from where it may be downloaded. The applet is preferably downloaded and/or initiated only once. Preferably, the applet can be addressed by scripts, e.g. from forms on the local Web browser and can be hidden.

In order to keep the plug-in generic, it provides preferably only one interface which expects an XML fragment containing the Web Service call as defined in the SOAP Body element. Thus, the plug-in can be deployed in whatever Web portal 3 and is not dependent on or specific to a particular application domain.

The integration into existing Web portal applications may be supported quite easy by including two JavaScript operations into the HTML page triggering a Web Service (most commonly HTML forms). The first JavaScript operation intercepts the event which releases the HTTP Post or Get request to the portal, gathers all user inputs provided in the HTML form, builds the XML fragment for the Web Service call and executes the plug-in' s method. In other words, the data from the form on the local Web browser 2 are not transmitted from the Web browser to the Web Portal 3, but are redirected by the plug-in which enables a direct SOAP based communication between the Web browser 2 and the Web Service 5 (see diagonal dotted double arrow in Fig. 5).

The second JavaScript operation performs the visualization of the response message from the Web Service 5. When the SOAP response has been authenticated by the plug-in 42, it is passed to the HTML page on the local Web browser 2, i.e. the response data are displayed in the local Web browser. Again, only the XML fragment of the SOAP response message is passed to the display() operation.

In summary, it is sufficient if a Web portal programmer adds two JavaScript functions per HTML front-end for a Web Service. The plug-in runs under a global policy for the entire portal, which can be customized by each HTML page if required. In a further preferred embodiment, the user's credentials is provided by specifying a

Java keystore file containing the user's private key as well as the passphrase to access the key. This file may be provided on a smart card 11.

Claims

1. A method for providing a secure end-to-end communication between a thin client (2) on a first host and a Web Service (5) provided on a second host in a packet-switched network, the method comprising the steps:

(a) establishing a communication between the thin client (2) on said first host and a Web portal (3) on a third host, wherein said Web portal (3) provides information regarding the said Web Service (5),

(b) providing a thin client extension (42) serving as Web Service client (42) on said first host, wherein said thin client extension (42) provides the framework for establishing the secure policy-based end-to-end communication between the thin client (2) and the Web Service (5), and (d) establishing the secure policy-based end-to-end communication between the thin client (2) and the Web Service (5) via the thin client extension (42).

2. The method according to claim 1, wherein the thin client (2) is a Web browser.

3. The method according to claim 1 or 2, wherein the thin client extension (42) is a plug- in, preferably a Web browser plug-in, preferably a native plug-in or a program running in a particular browser plug-in such as a Java Applet executed by a Java plugin or ActionScript executed by a Flash plugin.

4. The method according to claims 1, 2 or 3, wherein the thin client extension (42) is provides by the third host.

5. The method according to any of the preceding claims, wherein said information provided by said Web portal comprise security policies of said Web Service.

6. The method according to any of the preceding claims, wherein the framework for establishing the secure policy-based end-to-end communication is compliant to Web service security standard specifications.

7. The method according to any of the preceding claims, wherein said framework for establishing the secure end-to-end communication allows direct addressing of a security proxy (62) from the thin client (2).

8. The method according to claim 7, wherein said security proxy (62) is preferably executed on a different host as the thin client (2).

9. The method according to any of the preceding claims, wherein the thin client (2) and the Web Service (5) communicate via SOAP.

10. The method according to any of the preceding claims, wherein the thin client extension (42) is a plug-in customized individually for a specific Web browser (2).

11. The method according to any of the preceding claims, wherein different thin client extensions (42) for different Web browsers (2) are provided.

12. The method according to claim 1 1, wherein the different thin client extensions (42) communicate with the Web Service (5) via a common interface technology.

13. The method according to any of the preceding claims, wherein the thin client extension (42) is addressed by thin client specific commands.

14. The method according to claim 13, wherein a first operation gathers data input from the thin client and executes thin client extensions for sending the data input to the Web Service.

15. The method according to claim 13 or 14, wherein a second operation executed in the thin client extension gathers data input from the Web Service and provides it to the thin client for a thin client visualization of the data received from the Web Service (5).

16. System for providing a secure policy-based end-to-end communication between a thin client (2) on a first host and a Web Service (5) provided on a second host which is adapted to perform the method steps according to any of claims 1 to 15.

7. A computer program product directly loadable into the internal memory of a digital computer, comprising software code portions for performing the steps of any of claims 1 to 15 when said product is run on a computer.