The Need for WS-Security

Let's start by asking the question, "How do you secure a Web service?" In Chapter 6, "Connectivity with XML Web Services, Part 2," we introduced how authentication credentials could be applied to secure a Web service. By modifying the configuration settings in Internet Information Services (IIS) for .NET, or altering the security realm for the Java Web service, we were able to require clients accessing the service to provide authentication details.

When we are securing the Web service in this way, we are actually using transport-based security. In this case, we are relying on the security mechanisms provided by HTTP. Had we wanted to increase the security of the Web service by encrypting the transport itself, we could have used HTTPS (HTTP over Secure Sockets Layer, or SSL) ”but again, HTTPS is a transport-specific solution.

When using either HTTP for authentication or HTTPS for encryption, there are generally two common flaws. First, transport-based security is point-to- point security. This means the connection is secure only from the point it is initiated to the point it is sent. This type of security is perfectly valid for the scenario shown in Figure 13.1.

Figure 13.1: Point-to-point security using HTTPS (also applies to HTTP Authentication).

Let's imagine, however, that Service B is acting as a relay to Service C. Although security can be applied from A to B and from B to C as shown in Figure 13.2, we cannot ensure end-to-end security of the message as it travels from point A to point C. End-to-end security describes the safeguarding of the message from the originating point to the ultimate destination.

Figure 13.2: Point-to-point security using transport security and an intermediary.

If for some reason Service B is compromised, messages could be read by unauthorized users.

The second flaw is exposed when we try to move to another transport for Web services. As was mentioned in the introduction in Chapter 5, "Connectivity with XML Web Services, Part 1," Web services are designed to be decoupled from the underlying transport. This means that Web services have the potential for running on transports other than HTTP. Imagine the scenario shown in Figure 13.3, where a call is made via HTTP, yet the response is returned to the user as a Web service using SMTP.

Figure 13.3: Point-to-point security showing secure and insecure transports.

In this case, we can secure the HTTPS channel to provide security, but there is little we can do to secure the message as it's sent over SMTP.

What is required is a security mechanism for Web services that works from end to end in solutions and is independent of the underlying transport. This requirement for Web services security is addressed by WS-Security.