14.4 Quality of Service capabilities

< Day Day Up >

In this section we discuss Quality of Service capabilities and considerations specific to inter-enterprise Web services. For further discussion on Quality of Services for Web services in general, see 8.6, "Quality of Service capabilities" on page 177. For document style Web services see 9.6, "Quality of Service capabilities" on page 209. For the Web Services Gateway see 10.5, "Quality of Service capabilities" on page 233.

One of the main challenges when developing applications in an inter-enterprise environment is the uncertainty about the connection between the enterprises and the partner enterprise infrastructure.

14.4.1 Security

Security is one of the crucial QoS aspects which needs to be addressed when an enterprise plans to expose their internal applications to partner organizations. For the whole context and its consequences, see:

Security in a Web Services World: A Proposed Architecture and Roadmap, an IBM white paper available at:

http://www.ibm.com/developerworks/webservices/library/ws-secmap/
The OASIS Web Services Security (WSS) Technical Committee home page at:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

To address the security risks in an inter-enterprise scenario with Web services, it is critical to understand the how the Web services security context is defined. Web services defines an end-to-end security context as shown in Figure 14-5 on page 311. Furthermore, it is necessary to recognize that this not necessarily congruent with the security context of the underlying transport protocol.

click to expand
Figure 14-5: End-to-end Web services security context

A good example of this is the HTTP transport protocol, commonly used in Web services scenarios. As shown in Figure 14-6, HTTP itself defines a security context from point to point. In reality, an HTTP request passes through several intermediaries (for example, routers and Web server in a DMZ) before the request reaches the endpoint.

click to expand
Figure 14-6: Point-to-point security context in a Web services scenario

Consequently, each intermediary that is working on the application level with the SOAP message is a potential security risk. This is true even when you use HTTPS instead of HTTP.

We have to apply security at a higher level because securing the message at the transport protocol level is not sufficient. As described in 8.6.4, "Security" on page 179, WS-Security describes how to secure the message using XML encryption and XML digital signature. WS-Security defines how to integrate these specifications into a SOAP message.

Non-repudiation is also more significant in an inter-enterprise scenario than in an intra-enterprise scenario. This requirement can be fulfilled with a combination of sender authentication and message signature.

Using firewalls

In the case of inter-enterprise communication, data is often exchanged over a public network such as the Internet. The exposed interface for communications is visible to everyone on the Internet. Communication channels and data must be secure because there are unknown Internet users with unknown intentions. In the simplest scenario a firewall as entry point to the enterprise infrastructure may be sufficient.

But the higher the value of the services an enterprise offers, the more the channels must be secured. In such cases it may be necessary to implement a demilitarized zone (DMZ) with several security levels. Figure 14-7 shows a possible scenario.

click to expand
Figure 14-7: Securing the enterprise infrastructure with a two-level DMZ

In this scenario we introduce multiple levels to secure the enterprise infrastructure. Each level is protected by a separate firewall which performs network address translation and only allows traffic through explicitly enabled ports. In the first level we introduce a reverse proxy to hide the internal network structure. Using a router in the second level decouples the intranet from the Internet. The router may also introduce several subnets, which gives you additional security because the requests have to be routed to cross the subnet boundaries. This means you have better control because you can decide which request has to go to a specific port and which ports are allowed.

It is clear that infrastructure increasing security on the transportation level also has its drawbacks. The most important disadvantage is the increased path length from the source to the target application. Therefore, you have to take into account the increased execution time of requests. A good load balancing approach is also crucial for high traffic servers.

In addition to securing the communication channel and message exchange, it is important to:

Avoid the risk of malformed messages from outside, for example, using the Web services engine to validate messages before invoking the application.
Avoid denial-attacks, for example, using dedicated Web services servers.
Increase the control of Web services interactions, for example, using separate ports in the firewalls.

< Day Day Up >