Chapter 8: Implementing Secure Messaging for Web Services

In Chapter 5, I described the Web services security features prescribed by WS- Security and related specifications, including security tokens that are used for authentication and to optionally sign and encrypt messages to guarantee message integrity and confidentiality, respectively. Additional specifications have been proposed that build upon these core security features to enable Web services to interact more securely and efficiently with client applications and with one another. In this chapter, I will discuss the WS-Trust specification and how it can be used to enable the participants in a Web service interaction to make trust determinations and obtain the required security credentials needed to prove trust. I will also cover the security context token defined by WS-SecureConversation, which can be used to improve the efficiency and security of interactions that are comprised of a series of messages. Finally, I will demonstrate the support for these specifications implemented by Microsoft Web Services Enhancements (WSE) to secure your Web services.

Beyond WS-Security

While WS-Security describes enhancements that can be used to secure SOAP- based messaging as well as how to implement a secure, end-to-end security solution for Web services, it does not completely provide for all of the security requirements of SOAP-based interactions. The following are critical security scenarios that are not explicitly enabled by the features of WS-Security:

• Communicating the minimum set of security requirements that an incoming message conforms to in order to be accepted by a Web service.

• Obtaining security tokens from an authentication service in order to demonstrate that a principle is who or what it claims to be.

• Determining whether a Web service should accept a presented security token that meets the requirements of the service.

• A Web service challenging the requestor to determine if trust can be established.

• Negotiating a shared secret that can be used to efficiently secure a series of SOAP messages.

While the extensibility of SOAP and WS-Security allows us to write our own custom schemes to cover these scenarios, it is important that such solutions be based on widely-adopted specifications to enable greater interoperability. Just to reiterate, while it might be easier to understand Web services security concepts by describing all such scenarios in a single monolithic specification, keeping these specifications modular and orthogonal makes it easier to implement only the desired functionality and/or reuse functionality in unrelated scenarios. For example, while WS-Security describes methods for securing SOAP messages, this same functionality can also be leveraged to secure publicly exposed profile documents, as I showed in Chapter 6. Regarding the scenarios that I have just listed that are not covered by WS-Security, I have already discussed security policies for Web service in Chapter 6, and the rest of these security-related scenarios are covered by the WS-Trust and WS-SecureConversation specifications.