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

This chapter describes arguably the most essential aspect of securing Web services: the WS-Security standard. We say arguably here because WS-Security should be considered a layer of an overall Web Service Security strategy ”only one aspect, albeit a significant aspect, of an overall Web Services Security architecture. The WS-Security standard is a specification specifically created for using the security technologies you learned about in previous chapters in the context of a SOAP message. The WS-Security specification reached "approved status" status in April 2004. It is now a full-fledged OASIS open standard.

XML Signature and XML Encryption deal with XML security ”securing the content of XML documents. So what is the purpose of WS-Security? It deals with SOAP security ”securing the content of Web services messages. WS-Security is XML security in dynamic action, specifically designed to integrate into SOAP messages.

The good news is that you have already been exposed to much of the complexity of learning WS-Security in the previous chapters in this book. Most of the learning required to understand WS-Security is in understanding the underlying security technologies that WS-Security utilizes, not in understanding WS-Security itself. WS-Security defines practically no new security technology; instead, it focuses on applying existing security technologies such as X.509 certificates, SAML assertions, XML Signature, and XML Encryption to SOAP messages.

Problems and Goals

WS-Security is targeted at the problem of securing the Web service message itself, no matter where the SOAP message goes, no matter how long it lives. Contrast this with HTTP transport security (covered in Chapter 3, "The Foundations of Distributed Message-Level Security"), which is about creating a secure pipe between two servers through which messages travel.

Note

Web services are designed to work across any type of transport protocol, not just HTTP. For example, SOAP messages could be sent over email (SMTP) or even FTP. For the discussion in this chapter contrasting transport security and message-based security, we focus on HTTP transport security because it is the only transport binding specified for SOAP so far and is by far the most prevalent transport protocol used to carry SOAP messages today. In the case of non-HTTP transport technologies, other considerations may apply, but generally the contrast between transport-based security and message-based security remains consistent.

HTTP Transport Security Versus Message Security

It is helpful to understand the distinction between HTTP Transport Layer Security ( shortened to transport security going forward) and SOAP message-level security (shortened to message security going forward). Understanding the trade-offs between these two options, their relative strengths and weaknesses, and their associated costs is important to engineering an effective security solution.

Transport security was covered in some detail in Chapter 3 when discussing the foundations of message-based security. Recall that the purpose of transport security is to create a secure pipe between two Web servers. Authentication occurs at the time the secure pipe is created, and confidentiality and integrity mechanisms are applied only while the message is in the secure pipe, as shown in Figure 7.1.

Three of the transport security options described in Chapter 3 ”one-way SSL/TLS, basic authentication, and two-way SSL/TLS ”are quite viable for securing Web services. In general, they are simpler to implement than their message-level security equivalents, and system administrators tend to have experience working with transport-level security. Table 7.1 presents a matrix of transport security pros and cons, and Table 7.2 presents a similar matrix showing message security pros and cons.

Table 7.1. Transport Security for Web Services: Pros and Cons

Table 7.2. Message Security for Web Services: Pros and Cons

Transport security works by establishing a secure pipe between two endpoints, whereas message security works by applying security technology to the message itself. The SOAP message request to a Web service has encryption, digital signatures, and authentication applied directly into the message (we show you how in this chapter). With transport security, the SOAP message is secure only when it is in the pipe. With message security, the message is (conceptually) secure wherever it goes. For example, if messages were logged automatically by the Web services container, under transport security the message could very well be in the clear; however, with message security the message would still be encrypted and/or signed and retain its security even in the log file.

As you might expect, WS-Security takes advantage of the flexibility of XML Encryption. Because XML Encryption allows you to sign all or part of an XML document, you have the flexibility to allow a specific recipient of a message to see only certain parts of the message. A common problem that has bothered application firewall vendors for years is that SSL packets are completely opaque to the firewall; these packets pass through the firewall to the Web container before they are decrypted. (Many application firewalls can be configured to act as the SSL endpoint to prevent this problem; however, the message either has to be sent in the clear from the firewall to the target server, or the firewall has to establish a new SSL session with that server.) Thus, creating certain types of firewall rules becomes impossible when an SSL session is involved. With Web services and emerging standards such as WS-Routing, which allows for many intermediate waypoints to receive the message, you can imagine parts of the message encrypted in such a way that a waypoint (for example, a firewall) could read only the part of the message it needs to do its filtering. This is impossible with transport security, which works only endpoint-to-endpoint.

Note

SOAP Routing Protocol, or WS-Routing, is a SOAP-based, stateless protocol for exchanging one-way SOAP messages from an initial sender to the ultimate receiver, potentially via a set of intermediaries.

When you are thinking about message security, remember that each message can have its own security strategy. In the case of a simple synchronous Web service, there are two messages: one for the request and another for the response. It is entirely possible, and potentially reasonable, to have the request encrypted and the response in the clear (or any combination of authentication, encryption, and digital signature). This strategy would not be possible with transport security. With transport security, you have created a secure pipe, and every message ”request and response ”that passes through the pipe will be encrypted at one end and decrypted at the other end.

Of course, the extra power and flexibility of message security comes with a price: complexity. This price is partly due to the complexity of the underlying security technologies, such as XML Signature and XML Encryption; however, over time much of this complexity will be absorbed by your development and deployment environment, and you will simply declare rules for the way you want your specific Web service secured. Even when you have help from tools, the myriad possible options available make message-based security complex. For example:

• Do you want to require a username/password, a digital signature, and encryption?

• Do you want the encryption to be a certain algorithm or strength?

• Where will the client find the public key to encrypt with?

• On the response, do you want to encrypt the message back?

• Do you need to digitally sign it?

We could go on and on with these possible configuration and policy questions, but you get the idea. The bottom line is that deciding to use message security is like choosing to sit on a powerful, complex rocket engine with numerous knobs . It is sometimes said that the greatest security threat is complexity, and although the flexibility of WS-Security is a great strength, it is perhaps also its greatest weakness.

You can mix transport- and message-based security together. You need more of the WS-Security implementation details to understand this concept better, but one example is using username/password in WS-Security. One of the variations of username and password, UsernameToken , can have the password in the clear, similar to HTTP transport security's basic authentication. Using SSL to secure the transmission of the message is typically a good idea so that the password is not in the clear over the Internet. Of course, using UsernameToken with a clear-text password in the SOAP message defeats one of the major objectives of message security: How can the message be secure if the message contains a password sitting in the clear! But if you decided to take this approach, you would probably combine SSL/TLS from HTTP transport security with the UsernameToken from WS-Security. We discuss this and related issues later in this chapter in the section "Security Tokens in WS-Security."

Table 7.3 briefly summarizes the main differences between transport- and message-based security.

Table 7.3. Message Security and Transport Security Comparison

The Origins of WS-Security

WS-Security is a standard originally proposed by Microsoft, IBM, and VeriSign in April 2002 ^[1] . Prior to that, the only SOAP security standard was a W3C Note called "SOAP Security Extensions: Digital Signature" ^[2] (see Chapter 4, "Safeguarding the Identity and Integrity of XML Messages"). WS-Security supercedes that note and addresses authentication and encryption as well as digital signature. In late summer of 2002, WS-Security was sent to the OASIS standards body. In April 2004, it was established as an approved OASIS open standard. In terms of mind “share, WS-Security has had great success and is on the road to becoming the predominant method for securing Web services. What is frequently lacking in security technologies is the investment in making them easier for people to use. This is short-sighted because how good is a security technology if no one can put it to use? The involvement and interest shown by many high-visibility vendors on the WS-Security OASIS Technical Committee are promising , and emerging tools that will make WS-Security straightforward to use will continue to aid in its adoption.

^[1] You can view the original WS-Security note at http://www-106.ibm.com/developerworks/ webservices /library/ws-secure/?open&l=740,t=gr.

^[2] "SOAP Security Extensions: Digital Signature," http://www.w3.org/TR/SOAP-dsig/

WS-Security Is Foundational

Microsoft and IBM are both strongly committed to WS-Security, and it is a base technology for their overall XML and Web services architecture. In April 2002, IBM and Microsoft published a joint whitepaper called "Security in a Web Services World: A Proposed Architecture and Roadmap," ^[3] providing a far-reaching architectural vision of security that positions WS-Security as a foundational technology for a set of follow-on Web Services Security technologies.

^[3] "Security in a Web Services World: A Proposed Architecture and Roadmap," http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnwssecur/html/securitywhitepaper.as

From Figure 7.2, you can see how critical WS-Security is to a comprehensive Web Services Security framework. In the final two chapters of this book, we will review the other WS-* security-related standards such as WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation, and WS-Authorization.