There is a broad set of historical work in the area of computer systems and information policy. This includes different perspectives on how technical (IT) staff and business managers maintain and manage information systems. As the underlying technology evolves, so does the ability to use meta-information about those systems to help businesses and customers do more with the systems they have.
Much of the historical policy work has concentrated on the data management, systems configuration, and security areas. A business’ need to manage the information and resources under its control often drives this focus. As businesses depend more on technology, their ability to control access to resources and enforce their administrative policies become central requirements. In a dynamic distributed environment, this includes the need to manage and distribute these policies only to authorized entities. Recently, government regulations have increased businesses’ responsibility to protect consumer information from being distributed to third parties without the individual’s consent. This new privacy legislation adds to the existing set of business requirements and introduces access to customer data (and metadata) as part of the information that is critical to the day-to-day management of the business.
In a service-oriented environment, service policies have a fundamental impact on interoperability. It’s important to communicate to potential requesters any policies that a service provider enforces when those policies impact the interaction either because they require requesters to follow a specific behavior or a protocol or because they imply service-side behavior that impacts requester requirements or expectations (such as following a particular privacy policy). Service policies become a critical part of service descriptions, augmenting the basic WSDL functional description with a statement of nonfunctional service behaviors. As such, Web service policies support the development of service applications and provide the means to perform both development time and runtime service discovery and selection based on nonfunctional capabilities. For example, a service can be selected from among a list of functionally equivalent services based on its support for a specific privacy policy or the security guarantees it provides. The descriptive capability of policies, however, cannot be confined to services alone (although that will be the main focus of this chapter), but is required to annotate resources of different kinds, such as documents or document schemas.
The first set of Web Services Policy documents [WS-Policy, WS-PolicyAttachment, and WS-PolicyAssertions] was published in 2002. An updated set of two documents [WS-Policy and WS-PolicyAttachment] was published in September 2004. The modifications that were introduced into the new set clarify the processing and attachment models, while simplifying the policy syntax and defining how service policies can be represented and attached to services or resources in the context of the Web services framework. This chapter refers to these two specifications collectively as WS-Policy.
The need for an interoperable, standardized representation of nonfunctional capabilities and requirements of service endpoints should be clear, in view of the discussion in the previous section. It is necessary, however, that you understand why WS-Policy was created as a separate specification from WSDL, which already provides the basis for functional service descriptions. There are three major reasons for this.
First, there is the benefit of clearly separating concerns, avoiding a single monolithic specification to deal with all the diversity of service description information. WSDL has a clear focus on functional descriptions. Nonfunctional descriptions and quality of service aspects are naturally dealt with in a composeable, reusable specification, such as WS-Policy. Additional service description aspects, such as semantics, are best left to a different description language (such as OWL-S).
Second, the use of policies is not limited to service endpoints, but encompasses a variety of possible subjects, even when considering the service-oriented environment. XML documents, stateful resources of every kind, reliable messaging sessions, and so on can be legitimate subjects on which policies will need to be asserted to ensure interoperability among services. For this reason, WS-Policy strives to provide a flexible, extensible policy attachment mechanism for associating policies with subjects. WSDL is concerned only with service endpoints.
The flexibility of the attachment mechanism satisfies a third requirement that WSDL is not designed to support. That requirement involves representing the incremental addition of capabilities to an existing service. From a development and systems management perspective, it is common to incrementally modify a service offering by endowing it with additional capabilities available within a deployment environment. For example, confidentiality, authentication, support for reliable messaging protocols, and so on might be added to a service without impacting an application. In this way, services can be positioned to offer different qualities of service to different targeted audiences. In those cases, the service description also needs to be updated. WS-Policy Attachments provides support to flexibly add policies to preexisting services.
To fulfill this vision, WS-Policy must be able to encode capabilities and requirements that are derived from any discipline or application domain. Because of this, WS-Policy is intrinsically extensible, relying on discipline-specific assertions to represent discipline-specific properties, such as security policies, transaction policies, and business-specific policies. Domain experts, such as industry or standard groups, will define these domain dialects, which will then be used within the WS-Policy framework, leveraging a common, domain-independent processing model.
The simplicity of assertion expressions does not preclude additional semantics being defined for policy domains through technology such as Resource Description Framework (RDF) and the Web Ontology Language (OWL). The Web services community is interested in adding semantics to WSDL. Semantics for policy domains could also annotate policy assertions, allowing a policy container to aggregate a set of related assertions for a particular endpoint.
Web services policies are relevant in several scenarios. Following are three of particular relevance:
Development and deployment of interoperable service requester applications—. Together with WSDL, WS-Policy provides a declarative description of the requirements that services make on requesters, which guide the development and deployment of those applications.
Service discovery and selection—. WS-Policy descriptions enable service requesters to locate services based on their nonfunctional capabilities in addition to their functional properties. This way, it is possible to locate services that provide a given level of security or support for specific reliability guarantees.
Dynamic update of requester configuration—. Interacting endpoints can exchange policies using the WS-MetadataExchange port types. This way, services can update their configuration at runtime and customize each specific interaction. Requesters then retrieve updated policy information from the service provider and use it to reconfigure their runtime accordingly.
The WS-Policy framework consists of two specifications: WS-Policy and WS-PolicyAttachment. The WS-Policy specification describes the grammar for expressing policy alternatives and composing them as combinations of domain assertions. The WS-Policy specification also describes the basic mechanisms for the merging of multiple policies that apply to a common subject and the intersection of policies to determine compatibility.
The WS-PolicyAttachment specification describes how to associate policies with a particular subject. It gives normative descriptions of how this applies in the context of WSDL and UDDI, and it provides an extensible mechanism for associating policies with arbitrary subjects through the expression of scopes. The next section explores attachment in more detail.
A policy in the WS-PolicyFramework is the expression of a set of valid policy alternatives. Policy alternatives describe the acceptable combinations of constraints and requirements, which govern the interaction between a service and a requester or the access to a resource. A policy assertion represents each behavior (a discipline-specific constraint or requirement, such as following a reliable messaging protocol of encrypting messages). Therefore, a policy alternative is a combination of assertions, possibly from multiple disciplines. The policy does not specify to which subject the policy must be applied (the policy subject). It is merely a self-contained description of the constraints and requirements.
You can express the set of policy alternatives in a given policy in a compact form using policy operators, as described next. These choices enable you to group assertions or optionally include them within a group. You then define a normative algorithm for the translation of an arbitrary policy into its normal or enumerated form to facilitate the intersection of policy sets to find viable policy options for two parties that are trying to determine if they have comparable policies.
The primary component of the WS-Policy Framework is the policy container, which is represented by the Policy element. This element is a container for collections of assertions or combinations of assertions that represent a set of valid policy alternatives. Assertions are combined through policy operators. Policies can be named using the Id attribute to enable referencing and reuse.
The WS-Policy specification defines two operators and a modifying attribute to enable policy authors to group assertions into valid combinations.
This operator means that one—and only one—of its contained assertions or operators might be considered as part of an alternative at any one time. Consider the following:
<wsp:Policy>
<wsp:ExactlyOne>
<wsse:SecurityToken>
<wsse:TokenType
wsse:x509v3
</wsse:TokenType
</wsse:SecurityToken>
<wsse:SecurityToken>
<wsse:TokenType>
wsse:kerberosV5TGT
</wsse:TokenType>
</wsse:SecurityToken>
</wsp:ExactlyOne
</wsp:Policy>
This policy represents two valid policy alternatives: one that specifies the constraint that an X.509 security token needs to be presented, and another that specifies the constraint that a Kerberos token needs to be presented. No policy alternative allows both tokens to be presented simultaneously.
This operator is a simple aggregation of assertions. All children must be considered part of the combined behavior.
As an example, consider the following policy.
<wsp:Policy>
<wsp:All>
<wsse:SecurityToken>
<wsse:TokenType>wsse:x509v3</wsse:TokenType>
</wsse:SecurityToken>
<wsrm:RMAssertions>
......
</wsrm:RMAssertions>
</wsp:All>
</wsp:Policy>
This policy has a single valid policy alternative. This alternative combines reliable messaging behavior with the requirement to present an X509 security token.
This attribute is encoded on policy assertions to indicate that the inclusion of an assertion in the combined behaviors is optional.
<wsp:Policy> <wsse:Integrity wsp:optional="true"> ... </wsse:Integrity> </wsp:Policy>
Here, the policy contains two valid policy alternatives: one that includes the use of a digital signature, and one that does not (and does not specify additional behavior). The absence of the optional attribute has the default interpretation of optional=“false.” In other words, the assertion is required.
You can include the use of these operators and optional attributes in various combinations within a policy by nesting assertions and operators inside another operator. A policy is said to be in “normal form” when it is composed of a single ExactlyOne operator containing one or more All operators. Every policy in normal form follows this template. The WS-Policy specification describes the rules for converting a policy into normal form.
<wsp:Policy> <wsp:ExactlyOne> <wsp:All>...<wsp:All> + </wsp:ExactlyOne> </wsp:Policy>
In a normal form policy, each valid policy alternative is contained within an All element, and all of the alternatives are contained under a single ExactlyOne operator. This means you can choose only one alternative, and that alternative is a complete expression of the combined behaviors. In other words, where any particular assertion included in the policy appears in an alternative, you must apply its behavior, and where it does not appear in an alternative, you must not apply its behavior.
The WS-Policy specification defines a normative algorithm for translating any policy expression into a normal form policy. The meaning of a policy as a collection of alternatives is defined by its corresponding normal form, as defined by the normative transformation algorithm. An example of such a transform is illustrated next, using fictitious assertions A, B, C, and D.
<wsp:Policy>
<A/>
<B optional=true>
<wsp:ExactlyOne>
<C/>
<D/>
</wsp:ExactlyOne>
</wsp:Policy>
The normal form is as follows:
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <A/> <B/> <C/> </wsp:All>
<wsp:All> <A/> <C/> </wsp:All>
<wsp:All> <A/> <B/> <D/> </wsp:All>
<wsp:All> <A/> <D/> </wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
The vocabulary of a policy is the set of all assertions that appear in the policy. Every assertion that is declared in a policy is considered part of the policy’s overall vocabulary. For instance, in the last example of the previous section, the vocabulary of the policy would include assertions A, B, C, and D. As policies are merged through inclusion or through attachment to a common policy subject, so, too, are their vocabularies.
Because the vocabulary represents all the behaviors that the policy, considered as a whole, is making a statement about, each policy alternative is cast within this context. Consequently, each alternative is making an explicit statement of which behaviors within the vocabulary are part of the alternative, and (implicitly through their absence) which behaviors are not. This is the absence is negation rule of policy expressions.
It is important to note, however, that policies make no statement about behaviors whose assertions are not part of the policy vocabulary (because they are never mentioned in the policy). When intersecting policies to determine compatibility, the “absence is negation” rule applies within the scope of the policy’s vocabulary.
You can name policies using the wsp:Id attribute on the policy that is contained. Policy identifiers are unique absolute URIs. You need to assign an identifier to a policy so that other documents and definitions can reference it.
You need to reference policies in two main situations. In the first one, the contents of a policy expression can be embedded into a new policy by reference, using the PolicyReference element. The policy reference element is used within a Policy container; it carries the URI of the policy to be included, and its semantics are equivalent to textual substitution of the PolicyReference element by the contents of the included policy.
PolicyReference provides a means of aggregating policies, and it supports modularizing complex policy definitions into reusable policies that represent individual disciplines or concerns. For example, for manageability purposes, a service provider might find it desirable to model its separate quality of service domains, such as security, transactions, and reliability, as separate policies. A service provider can then combine these separate domains as required for each deployed service by including the appropriate policies under a single policy container.
Policy identifiers are also required when policies are attached to specific policy subjects. The different attachment mechanisms are discussed in more detail in section 7.2.2.
The intersection of policies is defined in the WS-PolicyFramework specification as a mechanism to help determine the potential compatibility between two policies. This situation arises every time the policies of a service need to be checked against the capabilities or requirements of the service requester. For instance, during the service discovery phase, a potential service user can express his quality of service requirements in the form of a policy that services need to support. Although an exact match might not be possible (between the policy advertised by the service and the one representing the requester’s requirements), the question arises of whether there is a set of compatible settings that both policies support. That alone would be enough to support the interaction from the quality of service compatibility point of view. By inspecting the structure of the two policies, you can determine whether such a compatible set might exist. The process by which this determination is done is called policy intersection, because it involves identifying the set of policy alternatives that appear in both policies. You cannot decide on actual compatibility by the intersection of policies alone; intersection simply discards clear nonmatches and returns possible matches (matching the element names of the XML representation of the assertions). You must validate the resulting common alternatives by discipline-specific engines to ensure technical compatibility.
Policy intersection selects a subset of matching alternatives that appear in both policies. Policy assertions are compared to their element-qualified names and are considered equivalent if the names match. A match in the qualified names of the assertions does not imply that the assertions match (because attributes and children of the two assertion elements might not match) but provides a first check of compatibility that needs to be further refined by checking the assertions for compatibility. In the general case, this second comparison step requires the use of discipline-specific knowledge, which is not available at the policy framework level. This is, for example, the case in the assertions that include parameters (in the form of attribute values of additional nested elements). Without an understanding of the meaning of each parameter, you cannot judge the compatibility of two parameter values. Policy intersection provides a first pass at establishing the compatibility of policies by preselecting possible matches between alternatives. Therefore, intersection is a domain-independent process for explicitly ruling out incompatible policy alternatives.
This mechanism is expected to be used in various ways. In a simple scenario, a service requester uses it to determine which of the policy alternatives that a service offers are compatible with its own technical capabilities and requirements. To do this, the requester formulates a policy that represents the type of service interactions it supports and intersects it with the actual policy offered by the service it wants to access. This process can result in one or more potential alternatives. It is advisable that you follow the intersection with validation of the matching alternative(s) using assertion-specific knowledge.
In the context of Web services, policies describe the constraints on an interaction between two or more Web service endpoints—typically a service provider and a service requester. However, policies that were created using the Policy container do not indicate the subject to which they apply. In WS-Policy, the association of policies with subjects is clearly separated from policy definition. That allows you to associate policies with multiple subjects and encourages you to reuse policy definitions.
WS-PolicyAttachment is concerned with the introduction of various mechanisms to associate policies with subjects. In a Web services scenario, several things might constitute a subject: a particular document, a document type, a message, a message exchange, a port type, an endpoint, a whole service, or a collection of services. The important point is that the set of possible subjects is not a closed set. Extensibility of attachment mechanisms is a fundamental requirement in WS-Policy. Two different mechanisms are introduced in this specification to satisfy this requirement:
A generic policy annotation to be used in arbitrary XML documents. A policy annotation allows direct attachment of policies to specific subjects that are defined or described within the document. The annotation directly identifies the applicable policies.
An external attachment mechanism that associates policies with subjects from outside the documents where the subject is defined or described.
You create policy annotations using the PolicyURIs attribute or the PolicyReference element. (Both are global definitions within the WS-Policy namespace.) The value of the PolicyURIs attribute is a list of whitespace-separated policy identifiers. The PolicyReference element contains one policy identifier. You use multiple elements when you need to attach more than one policy. You can encode the PolicyURIs attribute or the PolicyReference element, or you can nest it under an XML element to indicate that the referenced policies apply to the subject that element identifies.
WS-PolicyAttachments describes in detail how to use policy annotation in WSDL service description documents. Annotation of WSDL descriptions is a primary mechanism by which policies are attached to a service endpoint. (It is not the only mechanism, however, because you can also attach policies to a service endpoint using the external attachment method, as explained next.) Several types of WSDL definitions can constitute a policy subject. They include the message definitions, port type definitions, and WSDL bindings, among others. An attachment to a WSDL message binding using the PolicyReference element is shown in the next example.
<binding name="stockQuoteSoapBinding"
type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction=
"http://example.comGetLastTradePrice"/>
<input>
<wsp:PolicyReference URI=
"http://www.example.com/StdSecurityPolicy1"/>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
Here, a security policy is attached to the input message of the “GetLastTradePrice” operation by including the PolicyReference element with the policy name URI under the <input> element of the binding. Because the scopes of WSDL definitions are naturally overlapping, the scopes of the corresponding policies overlap, too. Consider, for example, policies that are attached to a message and to a port type that contains an operation that uses the message. Both the message policy and the port type policy apply to the message as a subject, because the message is included in the scope that the port type definition defines. In general, when policies are associated with the WSDL definitions of overlapping scopes, the policy for a subject is the aggregation of all applicable in-scope policies. This is known as the effective policy of the subject. To clarify the possible usage cases and provide guidance to service developers, WS-PolicyAttachment defines a normative set of possible policy subjects in a Web service, identifies the corresponding WSDL elements that make up the overall policy description of each of them, and provides the policy aggregation mechanism that computes the effective policy.
External association of policies with subjects is done using the PolicyAttachment element. A PolicyAttachment contains a subject scope expression that identifies the set of subjects to which policies are being attached in addition to the policy to be attached. PolicyAttachment either provides an inline definition or uses one or more PolicyReference elements. The scope expression is an extensible part of the PolicyAttachment construct that allows various scenarios and disciplines to define their own expressions for describing policy subjects.
<wsa:EndPointReference>
<wsa:Address>
http://www.example.com/StockQuote
</wsa:Address>
</wsa:EndpointReference>
WS-PolicyAttachment introduces the use of one such domain expression. As shown in the preceding example, you can encode a WS-Addressing endpoint reference as a scope expression to attach policies to the referenced endpoint.
The external attachment mechanism is particularly useful for communicating policy associations at runtime, via a message exchange. For example, in the course of their interaction, two endpoints might agree to use a certain conversational protocol during part of the interaction. The constraints on this protocol are specific to the interaction and relate to specific message instances, identifiable by their unique message identifier URIs, their sequence number if available, or by some other conversation-specific identifier. You cannot communicate this information prior to the dialogue through attachment to WSDL or UDDI; you can only communicate at runtime because that’s when the identifiers are established. With the introduction of the WS-MetadataExchange specification, an endpoint can also request a policy at runtime. This late binding allows policies to reflect a finer level of granularity because the MEX request might identify the requester or the instance of a service via an EPR, which allows the provider to offer a policy expression that is targeted toward the individual requester.
WS-PolicyAttachment describes a normative use of UDDI for associating policies with Web service endpoints, giving service requesters and providers the ability to leverage the query capabilities of UDDI for discovery of endpoints based on their policy descriptions.
At the time of this writing, WS-Policy is at the start of the path toward standardization. The current WS-Policy document focuses on expressing two types of metadata: capabilities (things a service can do) and constraints (things a service requires). One of the next tasks is to gather domain-specific experts and have them specify domain-specific expression languages to express the constraints and capabilities that are relevant for each domain in the form of assertion dialects. Examples of proposals in this area comprise WS-SecurityPolicy, which includes requirements for authentication and message-level security, and WS-ReliableMessaging, which includes capabilities for RM and WS-Transactions (WS-AtomicTransaction and WS-BusinessActivity).
When multiple service assurance protocols exist, it is important for a Web service to be able to indicate which one it supports and what requirements it places on potential requesters.
As Web services gain adoption and more complex Web services applications are deployed, the WS-Policy framework might need to be extended to express and support service agreements (such as WS-Agreements) and specification profiling for interoperability (WS-I conformance claims). Service agreements don’t just require a language for expressing goals and objectives. They also need a mechanism for negotiating and associating an agreement with a service endpoint and the parties that are governed by the agreement terms.
It may be necessary to clarify the relationship between WS-Policy and full-fledged semantic description frameworks. Just as WSDL extensions have been proposed to allow semantic expressions to extend the definition of a service interface, individual policy assertions can be annotated with semantic expressions and reasoned about as the semantic Web moves from theory to practice.
Ensuring the quality of service of Web services interactions is one of the most critical requirements of the Web services stack of specifications. Several specifications described later in this book—such as WS-Security, WS-Reliable messaging, and WS-Transactions—define the protocols that support specific aspects of this requirement. In a service-oriented environment, where loose coupling between applications is a fundamental property, the quality of service capabilities and requirements of a service must be declaratively expressed in standardized vocabularies so that you can properly configure and maintain partner services and avoid unnecessary coupling. WS-Policy defines a general-purpose framework for representing and combining statements about the quality of service properties. WS-Policy is an extensible framework that can accommodate domain-specific dialects to represent these assertions and allow the attachment of policies to arbitrary types of subjects though the generic attachment mechanisms that WS-PolicyAttachments define.