Chapter 6: Defining Policies for Web Services

While the specifications that I have covered thus far are useful in the functionalities that they bring to Web services, the Web Service Description Language (WSDL) wasn t designed to describe many of these Web service requirements. For example, if the GetDocuments method of our DocumentService required all requests be encrypted and signed with particular X.509 certificates, we would have to define this in something other than WSDL. In this chapter, I will discuss the WS-Policy specification, which provides the necessary framework for both parties in a Web service-based interaction to declare their respective policy requirements. I will also discuss related specifications, such as WS-SecurityPolicy, WS-PolicyAssertions, and WS-PolicyAttachment, which integrate the existing feature-based specifications with the policy framework. I will also show how Microsoft Web Services Enhancements (WSE) implements these policy specifications.

Why We Need Policies

It s all very well that we now have specifications such as WS-Security and WS- Attachments that prescribe how to handle tasks necessary for SOAP messaging, but those specifications don t really answer the question of how we expose these functionalities to our Web service consuming clients . We have seen in previous chapters that a Web service request can contain a set of credentials that can be used by the requested service to determine whether to allow access. That s great, but how do you know which credentials to include in the request message? Should you send along a Kerberos ticket, and if that doesn t work, try a X.509 certificate, or maybe load the message down with every possible security token that you can assemble? Although a message loaded down with WS- Security-defined elements might be more secure, it's inefficient to perform the extra work of adding these security elements when the recipient doesn't require them and possibly can't even handle such a message.

At this point, I know that many of you have just developed ”in your minds ”some sort of service, which for fun you might have named MyInfoService, that can be called in advance of making a request to the service that you need to access, say MyDataService, in order to get the applicable policy requirements. MyInfoService might tell you which security tokens to send to MyDataService, which languages are supported, what the message encoding should be, and the like. After this neat epiphany, you might then start to think about the difficulties of late binding to such a service, the extra logic that will need to be built into the client to assemble the right information at run time to make the request to MyDataService. After thinking more about the costs of making an extra SOAP request to MyInfoService before calling MyDataService, you might begin to pine for the early-binding benefits of consuming a WSDL file at design time.

Limitations of Existing Description Mechanisms

As we discussed in Chapter 1, one of the major benefits of WSDL is that it lets us consume the description of a Web service at design time so that we know, at run time, how to interact with the service. Unfortunately, although WSDL is designed to describe items such as exposed Web methods , data types, and SOAP message elements, it has proven less useful when it comes to describing choices, preferences, and other requirements not tied directly to the messaging interface.

For example, WSDL can tell you that MyDataService expects a SOAP request message to have a body element, which contains a certain child element, which corresponds to an exposed Web method. It can also provide schema information for this element. Each exposed Web method will have this information, and there will be similar information about what will be returned should the methods execute successfully. WSDL can even tell you that certain header elements are required, such as those that might provide authentication information or otherwise identify the requester or a particular message. Unfortunately, WSDL alone can t help us in the case of conditional requirements and other policy issues not directly related to either message transport or describing a SOAP message. Fortunately, WSDL does provide the extensibility to support the definition of policy requirements, as we will discuss shortly.

Defining Web Service Requirements

Up to this point, I have taken a somewhat compartmentalized approach to my discussion of Web service specifications and their related functionalities. This is in part for clarity s sake but also because the modular design of these specifications enables us to treat them in this manner, implementing the ones that we feel are necessary for our application and simply forgetting the rest. However, when we get into real-world scenarios, things can and will get more complicated. It s certainly not unanticipated that, in an enterprise Web service, we ll be carrying out operations such as encrypting and signing SOAP messages, transmitting security tokens, and providing custom routing information. Of course, as I have pointed out, the real question when accessing Web services is not, How do I do these things? since the specifications tell us how, but rather, Which of these must I specify for my request message to successfully return me my ˜Hello World? Or, How can I tell the customers of my Web service what they need to do to get their ˜Hello World? Alternatively, how can customers tell my Web service about the messaging requirements of their client applications so that messages can also be received by the clients?

The answer is that we need a way for communicating the full breadth of what our Web service requires of its clients, which can be thought of as our Web service s policy statement. The same goes for communicating the client s requirements to the service. Since both parties in a Web service-based interaction need to be able to enforce their own policies and interpret other policy statements, it really makes more sense to discuss policy in terms of sender and receive rather than client and service.

The policy-related specifications, backed by IBM, Microsoft, BEA Systems, SAP and others, officially define policy as the collection of all acceptable policy assertions for a specific domain (WS-Policy Section 3.4). In this definition, an assertion is considered a requirement or preference of the service. The following are examples of some assertions that can be made by a Web service:

• You must send either an X.509 certificate from you or else a Kerberos ticket, and Kerberos tickets are preferred.

• You must encrypt your message header.

• You must sign the message.

• You must send requests only in either German or Dutch.

• You can send messages encoded in either UTF-8 or ANSI_X3.4-1968.

In the rest of this chapter, I ll discuss the specifications that describe how to declare such policies for our Web services. Like all of the specifications that I discuss in this book, a main goal of these specifications is to be modular, wherein each layer is broken down into a separate specification, which includes the policy specifications described next .

WS-Policy

This specification describes a framework for defining and communicating the expectations and requirements both for sending messages to and receiving messages from a Web service, and it defines the format of such requirements.

WS-PolicyAssertion

This specification defines a core set of Web service-policy assertions dealing mostly with messaging issues, encoding, and other requirements that fall outside WSDL.

WS-SecurityPolicy

This specification describes a set of policy assertions that defines the types of security features that a Web service has implemented and the type of security that s required of an incoming request message. Although WS-SecurityPolicy is often considered a security specification, I discuss it in this chapter because it does define policy assertions regarding Web services security and leverages the WS-Policy framework for describing assertions.

WS-PolicyAttachment

This specification, in essence, ties everything together by defining how policy expressions are linked to WSDL and Universal Description, Discovery, and Integration (UDDI) as well as to other discoverability mechanisms.

Not only are the above specifications designed, to leverage one another, but they are also orthogonal to one another. This means that, for example, the security policy assertions defined in WS-SecurityPolicy can be taken advantage of in a framework other than the one described in WS-Policy or even just passed around in SOAP message headers. In subsequent sections, I will delve into what these specifications describe in a bit more detail, and we will see how WSE makes it work. I do cover UDDI-specific policy bindings in this book.