Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption

As you can see, publishing your security policy for a Web service is not as simple as just putting some new attributes in WSDL. Four specifications, all in early stages, are needed to describe the requirements of a Web service:

• WS-Policy provides a framework for describing policy across many domains, such as security, reliable messaging, privacy, and so on.

• WS-PolicyAttachment provides strategies for binding WS-Policy “based documents to a particular resource such as WSDL.

• WS-PolicyAssertions describes a few common policy assertions that apply across the different policy areas.

• WS-SecurityPolicy describes policy assertions specific to security.

A Web service typically involves at least two parties, a sender (client) and receiver (server), as well as potential intermediaries. Each party may have its own security requirements. The receiver may not care that the message being received is encrypted but requires that sent messages be encrypted. For that same message, the sender may require that the sent information be encrypted. In other words, you, as a sender, may have different security requirements than the message's receiver. These differences may be resolvable. For example, if the receiver does not care whether the message is encrypted but the sender requires encryption, the receiver could go ahead and receive the message in encrypted format. In other cases, the differences may not be resolvable. Looking at WS-Security from this perspective leads to the possibility of negotiation between the sender and receiver for a mutually acceptable security policy. To negotiate like this, a protocol is required to determine the back-and-forth steps. This is not surprising when you consider that security protocols such as SSL have been around for a while. In the next chapter, we describe WS-SecureConversation, which takes this type of approach.

One of the compelling aspects of Web services has been their simple, request/response nature. It is unclear whether this simplicity will be abandoned to support a richer policy negotiation strategy that requires multi-step protocols. A simpler one-time exchange of policies seems more likely in which the sender consults the receiver's policy, found via WSDL, and determines the intersection between the receiver's and sender's requirements. At that point, a message that is secured based on the sender's requirements will be sent or otherwise rejected by the receiver.