WS-Policy

At this point in the book, you have learned a great deal about what is required to secure a Web service using the many different available security options such as WS-Security, Security Assertion Markup Language (SAML), and so forth. Even if you did not read this chapter on WS-Policy, you could secure Web services using these technologies, and with some hard work and vigilance , you could successfully implement secure Web services.

Although you could implement secure Web services this way, and although many of the current Web services implementations will take just this approach, how will users of your Web service know the security requirements your Web service has? Similarly, if you want to use a Web service over the Internet or perhaps some far-away department of your company, how would you know what type of security to apply to your SOAP requests to interact with that Web service?

The emerging answers to these questions lie in the WS-Policy framework. The WS-Policy framework strives to provide a mechanism for exchanging requirements, not just security requirements (although WS-Policy was originally inspired by security policy issues), between a Web services client and a Web service provider. WS-Policy recognizes that the need to express a set of requirements for a Web service ”a "policy" ”exists across many domains, such as transactions, reliable messaging, privacy, security, and more we perhaps have not even thought of yet. Consequently, WS-Policy is actually a set of specifications providing generalized mechanisms for describing policy in a machine- readable way. The idea is that there ought to be a common language for describing the rules for interacting with a Web service, or what a client requires of a Web service, regardless of whether the domain is security, privacy, transactions, or any other category. Also, some of these rules, called assertions in WS-Policy, are common across all domains. For example, "I require SOAP version 1.1" could be a common rule whether in the security domain or in the privacy or reliable messaging domain.

WS-Policy and WSDL

At first, you might think that WS-Policy is just an extension of the Web Services Description Language (WSDL), and there have been early attempts at making it so; however, developers of WS-Policy have gone out of their way to make it a standalone concept that you can point to or include in various ways. Consequently, WS-Policy can be associated with a Web service in a variety of powerful ways. For example, you could choose to have specific parts of the WSDL, such as a specific operation or even a message for a Web service, point to a policy. Another possibility would be to have WS-Policy point to a set of Web services that it covers. This standalone nature of WS-Policy is also important because Web service clients do not have WSDLs, yet WS-Policy also applies to Web services clients . For example, you can easily imagine a situation in which a Web service's client expects sensitive information from a Web service and wants to require that encryption be used when the Web service responds to the request message. WS-Policy allows a Web services client to express this and not participate with any Web service that is unwilling or unable to participate in encryption.

At the time of this writing, the WS-Policy framework is still evolving, but the vision of WS-Policy is a powerful and important part of the evolution of Web services. Ultimately, the perfectly executed WS-Policy would involve policy negotiation between Web services, where multiple rounds of negotiation could occur. This capability would allow a mutually agreeable policy for both the Web service client and the Web service itself. This has been a long-standing vision, perhaps inspired by early visions of "agent" technology, which would allow for much more flexibility and dynamism between Web services. Although WSDL has been an extremely valuable standard and has been instrumental in the phenomenal growth of Web services, it has the problem of being a fairly static and limited instrument for describing a Web service. More and more technologies such as Web services message brokers are working to make WSDL more dynamic so that parts of the WSDL, such as the Web service's location URI, can dynamically change based on any number of factors, including message content. WS-Policy appears much more suited for these types of dynamic interactions and, perhaps, could become the description language for Web services (and Web services clients, a new thing) of the future.

WS-Policy and WS-SecurityPolicy

This chapter covers the WS-Policy framework in detail with emphasis, of course, on security policy. WS-Policy could change quite a bit by the time you read this chapter; however, the concepts and strategies used to describe policy will likely be stable, and these concepts will be the basis for the final WS-Policy specifications.

Let's start by discussing the need for a WS-Security policy and the ways you might use it at a high level. As you saw in the preceding chapter on WS-Security, you have numerous options when implementing WS-Security on your Web services. How could you express this information to a Web services client wanting to use your Web service?

What would you have to tell that Web services client? The following are some facts you might want to express:

• A security token of a specific type (for example, UsernameToken ) is required.

• Encryption is required, and here is the public key you will need to encrypt a message destined for this Web service.

• A signature is required.

Having only three requirements doesn't seem so bad. It would be nice if the situation were this simple. In reality, multiple other issues must be addressed:

• How do you describe the part of the message that must be encrypted? XML Encryption is extremely flexible, and the WS-Security specification provides no guidelines for what constitutes an encrypted message. You must decide that based on your Web service's requirements.

• Similarly, how do you describe what must be signed? Does the whole body need to be signed, or just a part of the body or a specific header?

• What algorithms do the server and client support? If the server chooses a stronger algorithm, is it acceptable?

• A typical synchronous Web services call contains two independent SOAP messages: a request and a response. Naturally, when securing a Web service, most people think about what a client will be required to do with the incoming request for the Web service to accept that request. However, you also likely need to describe to the client what the Web service will do with the response SOAP message:

  • I will return this type of token.

  • I will encrypt the response message.

  • I will sign the response message.

• Finally, and this is the one of the largest issues, what message security does the client require? WSDL supports a one-way interaction in which the Web service publishes its requirements and the client of the Web service must adhere to them. However, in WS-Security scenarios, the client may want a say in the security requirements. For example, say that a Web service provides credit reports . As a client, you would likely want the Web service to sign and encrypt the contents of a message back to you. In this case, a mechanism must be in place for the client to communicate its minimum requirements.