Understand WS-Policy processing

Explore Intersection, Merge, and Normalization in WS-Policy

Paul Nolan (nolanpt@uk.ibm.com), Software Engineer, IBM　

Paul Nolan is a developer working on Web services projects. He is closely involved with the evolution of the WS-Policy specification. He also works on the team developing the policy4J package, which will form the core component of the IBM policy processing infrastructure.

Summary: WS-Policy is becoming a crucial component of the Web services framework. It is likely that most Web services programmers will encounter the effects of Web service policy at some level. The newly updated public specification for WS-Policy briefly describes various policy processing models such as Normalization, Intersection and Merge. Learn the meaning of these architected operations and some of the implications and considerations that are not immediately obvious.

Tag this!

Date: 07 Dec 2004
Level: Intermediate
Activity: 2621 views

Introduction

The Web Service Policy Framework (WS-Policy) specification defines a syntax and semantic for service providers and service requestors to describe their requirements, preferences, and capabilities. The syntax provides a flexible and concise way of expressing the needs of each domain in the form of policies. A domain in this context is a generic field of interest that applies to the service, such as the following:

Security
Privacy
Application priorities
User account priorities
Traffic control

The specification also describes processing models for these policies that operate independently of the domains. There are three defined operations for processing policies; Normalize, Merge, and Intersect. This paper discusses these functions and highlights some of the less obvious implications of this processing.

It is worth taking a moment to cover some of the basic terminology that the WS-Policy framework specification uses. The words Assertion and Alternative are used extensively in this paper, so the following sections describe these terms so that you are familiar with them.

The assertion

An assertion is the basic unit of policy. It can be thought of as an instruction to a policy processing infrastructure. For example, the assertion could declare that the message be encrypted; the actual definition of this assertion would be in the WS-Security Policy domain specification.

Thus, the meaning of individual assertions is specific to each domain and identified in their own separate specifications; the details of each domain-specific assertion is beyond the scope of the WS-Policy framework. However, the WS-Policy framework treats each assertion as an opaque.

Each assertion is identified by its Qualified Name (QName). An assertion can be a simple string or can be a complex object with many sub elements and attributes. However, it is only the root XML element QName that is involved in any WS-Policy framework processing.

The alternative

A policy is built up using assertions and nested combinations of the operators <wsp:All>, <wsp:ExactlyOne>, and the attribute Optional. This policy syntax is used to describe acceptable combinations of assertions to form a complete set of instructions to the policy processing infrastruction, for a given Web service invocation. Each set of assertions is termed an alternative.

Note that only a policy which includes the Optional attribute or the <wsp:ExactlyOne> operator has more than one alternative. Put the other way round, a policy that is built up using only assertions and the <wsp:All> operator can be collapsed into a single alternative.

The following sections cover each of the types of processing that can be performed on a policy.

Normalization processing

The flexible syntax of the Web service policy framework can lead to potentially complex policies. The Normal form of policy was defined to simplify the manipulation and to clarify the understanding of policies. Policies in the Normal form are how the basic operation of the policy processing is to be carried out.

In order for policies to be processed with the Merge or Intersect operations they must first be reduced to the standardized Normal format. The Normal form contains only one choice operator: <wsp:ExactlyOne>>. This defined Normal form uses a simplified XML format whose schema is represented in Listing 1.

Listing 1. An example of the Normal form

<wsp:Policy ... >
   <wsp:ExactlyOne>
    [<wsp:All> [ <assertion ...>... </assertion>]* 
     </wsp:All> ]*
   </wsp:ExactlyOne>
</wsp:Policy>

Note that the <wsp:ExactlyOne> operator appears once and only once within the Normalized policy. In effect each element within the <wsp:ExactlyOne> operator is a policy alternative. Each policy alternative is encapsulated within a <wsp:All> operator.

It is worth noting that there are two special cases of Normalized policy. The first is the empty policy, as Listing 2 shows.

Listing 2. An empty policy

<wsp:Policy ... > 
   <wsp:ExactlyOne>
      <wsp:All/>
   </wsp:ExactlyOne>
</wsp:Policy>

A note on missing rather than empty assertions

Note that an alternative that is missing an assertion has special meaning. If that same missing assertion is actually present elsewhere in the overall policy, the particular alternative is indicating that the assertion should not be carried out during policy processing.

This could potentially be a different meaning from the situation where an assertion that does not appear in either the alternative or in the overall policy. Since the actual processing of assertions is dependent upon the policy domain it belongs to (for example, a privacy domain could require a specific assertion each time), if a required assertion is missing from an alternative, the resulting processing action defaults to whatever the policy domain's rules are. In the latter case, where a required assertion is missing from the overall policy, the meaning is not defined. The assertion may or may not be acted upon; again, it is the individual policy domain that defines the assertion which should decide in this case.

The single empty policy alternative represented by the <wsp:All/> indicates that no assertions are required. This is saying that the policy infrastructure doesn't need to take action. The empty alternative can appear in a Normalized policy in conjunction with other non-empty alternatives. It simply states that taking no action is a valid choice.

The second special case of Normalized policy is the null policy.

Listing 3. The null policy

<wsp:Policy ... >
   <wsp:ExactlyOne/>
</wsp:Policy>

The null policy indicates that there are no valid alternatives. Any attempted invocations of this Web service won't be successful since there is no defined policy on how it is to be used according to the requested situation. An example of this would be a service provider that asks for a particular type of encryption method, for which the service requester doesn't have the security infrastructure to support. In such a case, the policy framework determines the compatible policy to be null and thus, invocation of the service doesn't work.

A further point of interest concerns the use of the Optional attribute. If a policy simply consisted of two optional assertions then there are effectively four possible permutations and hence, in its Normal form, there would be four alternatives. Likewise three optional assertions give rise to eight alternatives. If more assertions are added, it is clear to see that the potential number of alternatives will grow by a binary escalation. It takes relatively few optional assertions to produce an unacceptable number of alternatives, and therefore the use of the Optional attribute should be used with caution.

An example of the use of Normalization

The Normalization process can be illustrated with a series of steps. The following shows an example of each step in the process to illustrate how it works. Consider the policy in Listing 4.

Listing 4. A basic Normalized policy

<wsp:Policy ...>
   <wsp:All>
      <wsp:ExactlyOne>
         <nsSecurityAssertion wsp:Optional="true"/>
         <nsReliableMessagingAssertion/>
      </wsp:ExactlyOne>
      <nsTransactionAssertion/>
      <nsAuditAssertion/>
   </wsp:All>
</wsp:Policy>

Step 1: Expand the @wsp:Optional attribute

First, expand the @wsp:Optional attribute. This means that two entries are created for each occurrence of the optional assertion. One entry contains the assertion, and in the other, the assertion is absent. To represent these two options, use a <wsp:ExactlyOne>> operator. To represent the option where the assertion does not appear, use the syntax of the empty policy. For example:

<nsSecurityassertion wsp:Optional="true"/>

would expand to:

<wsp:ExactlyOne>
   <nsSecurityassertion/>
   <wsp:All/> 
</wsp:ExactlyOne>

So the example policy would now look like Listing 5.

Listing 5. A modified Normalized policy

<wsp:All>
   <wsp:ExactlyOne>
      <wsp:ExactlyOne>
         <nsSecurityAssertion/>
         <wsp:All/>
      </wsp:ExactlyOne> <nsReliableMessagingAssertion/>
   </wsp:ExactlyOne>
   <nsTransactionAssertion/>
   <nsAuditAssertion/>
</wsp:All>

Step 2: Collapse the policy operators

Next, you have to repeatedly collapse the policy operators until you only have a single <wsp:ExactlyOne> containing assertions wrapped in <wsp:All> operators. There are a finite number of possibilities, so this step is not as complicated as you might think. For example, a <wsp:All> inside a <wsp:All>, or a <wsp:ExactlyOne> inside a <wsp:ExactlyOne> each collapse to a single operator because of the associative rule.

The example below shows how to start with an assertion and work outwards. If, in this example, you cancel out the <wsp:ExactlyOne>, you get the result in Listing 6.

Listing 6. Collapsing operators

                    
<wsp:All>          
   <wsp:ExactlyOne>
      <nsSecurityAssertion/>
      <wsp:All/>
      <nsReliableMessagingAssertion/>
   </wsp:ExactlyOne>
   <nsTransactionAssertion/>
   <nsAuditAssertion/>
</wsp:All>

Step 3. Repeat collapse process until unified

This collapse process is repeated until there is only a single outer <wsp:ExatclyOne> operator. In this example the only tricky maneuver is to reverse the <wsp:All> and <wsp:ExactlyOne> operators. The technique is to use a cross product principle.

Single assertions are taken from the <wsp:ExactlyOne> and combined with all the assertions in the outer <wsp:All>.

 
<wsp:ExactlyOne>
   <wsp:All>
      <nsSecurityAssertion/>
      <nsTransactionAssertion/>
      <nsAuditAssertion/>
   </wsp:All>
   <wsp:All>
      <wsp:All/> 
      <nsTransactionAssertion/>
      <nsAuditAssertion/> 
   </wsp:All>
   <wsp:All>
      <nsReliableMessagingAssertion/>
      <nsTransactionAssertion/>
      <nsAuditAssertion/>
   </wsp:All>
</wsp:ExactlyOne>

Step 4. Final clean-up

In order to reach the Normal form, a final bit of tidy-up is required. The <wsp:All/> (empty policy) within a <wsp:All> can be removed. This is because this empty assertion indicates that this assertion should not be carried out. The assertion is not named; however, it is implied. In this example, this is effectively the optional SecurityAssertion. This is the case where the assertion does not appear.

If this is compared with the definition of a normalized policy, you can see that this is now in the normalized form. There is one <wsp:ExactlyOne> operator containing <wsp:All> operators. You can see that this example policy yielded three alternatives.

Merge

Merge is the process of combining sub-policies together to form a single policy. This operation is necessary due to the fragmented way policies could be constructed or acquired. For example, the WS-PolicyAttachment specification describes how policies can be attached to the elements of a WSDL. Furthermore, each element in the WSDL could have a list of policies associated with it. Combining all these policies together to form a single Merged policy is a necessary step in policy processing.

The Merge process takes place on policies that have been converted to Normal form. The alternatives from each sub-policy are combined to form the new Merged alternative. The combination process follows a cross product pattern. One alternative is taken from each policy in turn until all permutations have been exhausted. Listings 7 and 8 show two policies that are to be merged together during processing.

Listing 7. Policy P1

<wsp:Policy wsu:id="P1"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsSecurityAssertion/>
      </wsp:All>
      <wsp:All>
         <nsReliableMessagingAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

Merged with:

Listing 8. Policy P2

<wsp:Policy wsu:id="P2"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsTransactionAssertion/>
      </wsp:All>
      <wsp:All>
         <nsAuditAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

To get the merged policy, each alternative from policy P1 is combined with each alternative from P2. Since P1 and P2 were already in Normal form, the combining process is simply a matter of taking an assertion from each alternative and forming new alternatives that contain all the assertions.

Listing 9. Policy P1 merged with P2

<wsp:Policy wsu:Id="P1_Merged_with_P2"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsSecurityAssertion/>
         <nsTransactionAssertion/>
      </wsp:All>
      <wsp:All>
         <nsSecurityAssertion/>
         <nsAuditAssertion/>
      </wsp:All>
      <wsp:All>
         <nsReliableMessagingAssertion/>
         <nsTransactionAssertion/>
      </wsp:All>
      <wsp:All>
         <nsReliableMessagingAssertion/>
         <nsAuditAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

It is the underlying policy infrastructure's responsibility to determine the meaning of any alternatives that result in duplication of assertions. It is also worth noting that there is the potential for rapid growth in the size of the Merged policies if there are multiple choices in each source policy. Given this, pay special attention to the use of the Optional attribute, which can quickly lead to size escalation.

Intersection

Intersection is the process of comparing two Web services policies for common alternatives. Only when both sides of an interaction agree on at least one policy alternative can the interaction take place. This operation would typically be used when a requester expresses its capabilities and requirements in policy form. The requester policy perhaps indicates the assertions that its local runtime infrastructure is capable of processing. The intersection of two policies gives zero or more alternatives on which both parties agree.

The process of Intersection is perhaps not as obvious as it first appears. Consider the question: How does a domain-neutral policy framework determine if two assertions are the same? The meaning of the assertions is known only to the domain which defines them. To deal with this issue a domain neutral policy framework can only do so much; domain knowledge is required to complete the process.

The process begins with both policies being expanded to Normal form. The two Normalized policies are now examined an alternative at a time. The intention of the first phase is to eliminate those alternatives that are clearly different. This is done by examining the Vocabularies of the two alternatives. The Vocabulary of an Alternative is a set of QNames of the assertions in that Alternative. If the Vocabularies do not match, then the two Alternatives are clearly different and can be discounted from the Intersection.

Note that this comparison of Vocabularies does not take into account duplication of these QNames. If there is more than one assertion in an alternative with the same Qname, then this could match any number of assertions with the same Qname from the second alternative. The comparison process also does not take into account any attributes or values that these assertions might have. It is therefore possible for two alternatives to share the same Vocabulary, but could in fact contradict each other in some aspect. For example: <nsAssertionvalue="on"/> has the same QName as <nsAssertionvalue="off"/> The comparison process is essentially only checking that the two Alternatives speak the same language. What sorts it out is the next stage of Intersection, which produces the matched alternatives.

Two alternatives that have different Vocabularies are considered incompatible. When two alternatives have a matching Vocabulary they are combined to produce a single new alternative in the Intersected policy. Since the assertions in the alternatives are combined, the resulting alternative contains duplicate occurrences of many of its assertions, and might also contain contradictory assertions. However, it is more likely that the assertions differ only in terms of refinement of detail. For example, an assertion from an alternative from the requester policy might simply state that it is capable of supporting encryption. It would therefore only consist of a root element and possibly no attributes or values. The equivalent matching assertion from the service provider policy alternative might contain details of exactly which encryption should be used and some refining attributes.

The process of combining alternatives from two policies is carried out in a cross product fashion. Each alternative from each policy is compared with every alternative from the other. It is therefore worth noting that the Intersected policy could potentially be large. The more choices that exist in the source policies, the more potential combinations could arise.

It is beyond the scope of the WS-Policy framework specification to define how these combined alternatives are to be interpreted; domain knowledge is required to rationalize the newly combined alternatives into something meaningful to the infrastructure. For example, the WS-Security Policy domain will be the only source of information as to whether two security assertions contradict each other or are complementary refinements of each other.

The process of collapsing several occurrences of each assertion within an alternative that have the same QName into a single meaningful instruction to the infrastructure requires knowledge of the meaning of the assertions in question. Consider the question: Does the appearance of an assertion twice mean that the infrastructure should perform the operation defined by this assertion twice? The answer must be that this is not a question for the domain-neutral processing described here; the answer must come from domain-specific knowledge.

The newly Intersected policy might yet require further processing before diriving the compatible set of alternatives that can be supported and are acceptable to both sides of the Web services interaction. It is even possible that an alternative might contain contradictions that are not meaningful to the underlying infrastructure that is responsible for performing the required behaviors, in which case the invocation can fail.

It is also worth noting the effects of Intersection on the special case policies of null and empty. Intersecting a null policy with any policy results in a null policy. Intersecting an empty policy with anything results in a null policy with one exception. If two empty policies are intersected, then the result is an empty policy.

Example

Assume you have a service provider policy and a requester policy. These policies have been normalized and take the following form:.

<wsp:Policy wsu:Id="Provider_Policy"...>
   <wsp:ExactlyOne>
      <wsp:All> 
         <nsSecurityAssertion level="high"/> 
         <nsReliableMessagingAssertion/>
      </wsp:All>
      <wsp:All>
         <nsSecurityAssertion level="medium"/>
         <nsTransactionAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

The requester-side policy is:

<wsp:Policy wsu:Id="Requester_Policy"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsSecurityAssertion/>
         <nsReliableMessagingAssertion timeout="100"/>
         <nsReliableMessagingAssertion retries="3"/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

The intersection process takes each alternative bounded by the <wsp:All> operators. Only the QNames' assertions are compared. This means that the requester-side alternative matches only the first alternative from the provider policy. These two alternatives are combined to produce the intersected alternative.

<wsp:All>
   <nsSecurityAssertion level="high/>
   <nsSecurityAssertion/>
   <nsReliableMessagingAssertion timeout="100"/> 
   <nsReliableMessagingAssertion retries="3"/>
   <nsReliableMessagingAssertion/>
</wsp:All>

It is the policy processing infrastructure's job to interpret this policy alternative and merge the assertions with identical Qnames into assertions that have meaning to the processing modules. For example, the ReliableMessagingAssertion assertions could well be merged into a single assertion:

 <nsReliableMessagingAssertion timeout="100" retries="3"/>

As Web services interoperability issues become more apparent, the use of policy will become more significant. It is likely that application developers and deployers will not be able to avoid the implications of policy processing. This paper touched on some of the issues that are likely to be significant. This paper is based on current knowledge and experience. There is no doubt that this is a developing subject and there could still be many changes as Web services continue to evolve and further issues are addressed.

Resources

Get the latest version of Web Services Policy Framework (WS-Policy)
Get involved in the developerWorks community by participating in developerWorks blogs .
Visit the Developer Bookstore for a comprehensive listing of technical books, including hundreds of Web services titles.
Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.

About the author

Comments (Undergoing maintenance)

Trademarks | My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=SOA and Web services

ArticleID=32090

ArticleTitle=Understand WS-Policy processing

publish-date=12072004

author1-email=nolanpt@uk.ibm.com

author1-email-cc=