Summary

This discussion of WS-Security brings together all the concepts discussed in this book so far. The SOAP security header provides a location in the SOAP message for assembling the various security mechanisms available. Security tokens provide the mechanism for authentication and authorization technology in a very flexible manner. Security tokens mirror similar technologies outside WS-Security, such as username and password, X.509 certificates, and SAML assertions. XML Signatures fit into WS-Security in a natural way as detached XML Signatures, with the Signature element sitting in the security header and the Reference URI pointing to another part of the message, such as the SOAP body or another SOAP header. The effect on XML Encryption is greater because the EncryptedData element needs to be in the actual message part that is being encrypted. Consequently, the ReferenceList is used to point to the EncryptedData elements. However, this ReferenceList is really no different from the ReferenceList that is a child of EncryptedKey , so this concept is really not new.

The advent of security tokens with WS-Security is one of the more significant aspects of WS-Security for several reasons. One is the flexibility of the standard to add new security token types by adding new specification documents rather than having to amend the WS-Security specification itself. Thus, as new types of security tokens emerge, they can be brought in to the WS-Security world. The second reason is that they provide a more tailored mechanism than the standard KeyInfo structure provided from the XML Signature specification. The XML Signature KeyInfo structure has a predefined set of elements, most of which are optional but are constrained and appear to be mostly inspired by X.509 technology. Because a security token can have exactly the structure it needs to have, it can fully represent disparate authentication and authorization technologies. For security tokens to be fully supported, we needed to be able to point to them from a KeyInfo block; hence, the SecurityTokenReference rounds out the security token technology, allowing a generic way to point to the various security token types.

One issue of concern about WS-Security is that it does not define how to secure a SOAP message. For example, WS-Security does not specify what it means to have an encrypted message; it just tells you how to put encryption in the header. WS-Security is neutral about whether you should sign and encrypt the entire body, certain headers, or just a single character in the message. You should think of WS-Security as a set of tools that you can apply to your specific Web services scenario. The really hard work of determining your s ecurity policy is up to you, and with all the possible approaches that WS-Security provides, this task can be daunting.

As a developer, you will most likely be exposed to WS-Security functionality through development tools. Generally, these development tools create simplifying options to encrypt or sign a message, for instance. With BEA's Weblogic Workshop product, for example, when you designate that you want a SOAP request to be signed (perhaps because the Web service you are calling requires it), the entire message is signed by default. Also, related to this, interoperability organizations such as the Web Services Interoperability Organization (WSI, http://www.ws-i.org/) are defining standard profiles for WS-Security interactions so that applications secured with the various Web services development tools can successfully interoperate .

WS-Security has tremendous momentum, and the technology is available for every major Web services container such as Microsoft's Advanced Server, IBM's Websphere, and BEA's Weblogic Platform. As a developer or security administrator, you undoubtedly will need to have an understanding of this technology and the way it applies in your context.

WS-Security is not the end of the Web services “related security technology standards. Quite the contrary. When IBM and Microsoft laid out their Web Services Security roadmap, WS-Security was the base of the proposed architecture. WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation, and WS-Authorization were all mentioned as follow-on standards to WS-Security in this roadmap. WS-Policy, which focuses on communicating the Web services security requirements, is the focus of Chapter 8, and Chapter 9 discusses the other WS-Security standards, often called the WS-* standards.