..OO.. Wheeling thru - by Asir

WS-Policy Implementations

WS-Policy is widely supported by several commercial products. Publicly known products are:

• Apache AXIS2 (uses Apache WS-Commons)
• BEA AquaLogic Service Bus
• BEA WebLogic Server
• gSOAP Toolkit
• IBM Emerging Technologies Toolkit for Web Services and Autonomic Computing
• Layer 7 SecureSpan
• Microsoft Windows Communication Foundation
• InfoCard WinFX Component
• SAP Netweaver
• Sonic Software - Actional 6.0
• Systinet Registry
• Systinet Server
• Sun Project Tango
• WSO2 Tungsten

If you are aware of other commercial products, please send info to 'Asir at Selvasingh dot com'.

WS-Policy Data Model

The Web Services Policy Framework consists of three items: a policy data model for expressing the consistent combinations of capabilities and requirements of a Web Service, a processing model for combining and comparing policies, and an XML Representation of the policy data model. The following is a pictorial representation of the policy data model.

How to Describe a Policy Assertion?

A Policy Assertion identifies a visible domain specific behavior that is a capability or requirement. In the example below, Policy Expression uses the TransportBinding Security Policy Assertion.  This assertion identifies the use of transport level security – such as HTTPS - for protecting messages.

<wsp:Policy>
  <sp:TransportBinding>
    <wsp:Policy>
      <sp:TransportToken>
        <wsp:Policy>
          <sp:HttpsToken RequireClientCertificate="false"/>
        </wsp:Policy>
      </sp:TransportToken>
      ...
    </wsp:Policy>
  </sp:TransportBinding>
</wsp:Policy>

TransportBinding is a Policy Assertion. A Policy Assertion is an XML element. The QName of this element represents the behavior identified by this Policy Assertion. Policy Assertion may contain Parameters and a Nested Policy.

RequireClientCertificate is a Parameter of the HttpsToken Policy Assertion. Parameters are the opaque payload of a Policy Assertion and are preserved through policy processing such as normalize, merge and intersect. A Parameter can be either an XML element child or attribute of a Policy Assertion element.

TransportToken is a Nested Policy Assertion of the TransportBinding Policy Assertion. TransportToken assertion requires the use of a transport token. A Nested Policy Assertion further qualifies a dependent behavior of a Policy Assertion.

Policy Assertions are defined by users, product designers and protocol authors. What are the minimum requirements for describing a Policy Assertion? Policy Framework and Attachment specifications outline the following:

1. Description must clearly and completely specify the syntax and semantics of a Policy Assertion
2. If there is a Nested Policy Expression, description must declare it and enumerate the Nested Policy Assertions that are allowed
3. Description must specify the semantics when there are multiple instances of a Policy Assertion in the same Policy Alternative
4. If a Policy Assertion is to be used with WSDL, description must specify a WSDL Policy Subject – such as Service, Endpoint, Operation and Message.

Wala!

Growing Collection of Policy Assertions

Like XML Schema libraries, policy assertions are growing. There are numerous product level policy assertions in use. Several WS-* protocol specifications and applications define policy assertions:

• Web Services Security Policy
• Web Services Reliable Messaging Policy
• Web Services Atomic Transaction
• Web Services Business Activity Framework
• Devices Profile for Web Services
• A Technical Reference for InfoCard v1.0 in Windows
• ...

This is a growing collection!

WS-Policy Interop uses Security Policy

WS-Policy Round 3 interop tests use security policy assertions. These tests exercise substantial parts of the Policy Framework and Policy Attachment for WSDL.

WS-Policy Interop Tests: Round 1 and 2

Round 1 test cases are for testing policy normalize, merge and intersect operations. Round 2 test cases are for testing effective policy computations for policies attached to WSDL.

WS-Policy scenarios pack includes both input and expected output data for these test cases. Round 1 and 2 are WS-Policy unit test cases. Implementers may wrap these tests as JUnit implementations, Web Service Endpoints, command line executables, user interface code, etc.

The important bits for Round 1 and 2 are input and expected output data. Implementers should offer feedback if their output data does not match the expected output data.

Leverage Nested Policy Expression?

The burning question is when should a policy assertion author leverage nested policy expression?

When we talk about nested policy expression there is always two or more policy assertions involved. I would use the following two design questions to determine the possible use of nested policy expression:

• Are they designed for the same policy subject?
• Are they dependent?

If the answers are yes then leveraging nested policy expression is a good idea. However, there is one caveat: nested policy expression participates in the policy intersection algorithm.

Changes to WS-MetadataExchange

Upcoming changes to WS-MetadataExchange specification are: change to reference Get operation in WS-Transfer and describe how to use the metadata encapsulation format within Endpoint References. For details, please see the joint white paper from HP, IBM, Intel and Microsoft.

WS-Policy Interop Workshop, April 25-27 2006

You are invited to attend the WS-Policy Interop Workshop at the SAP AG Campus in Walldrof, Germany on Tuesday, April 25th to Thursday, April 27th, 2006. This is the first WS-* interop workshop to be held in Europe. A copy of the invitation is available on WS-Builders website - http://groups.yahoo.com/group/WS-Builders/message/87. I'll see you there!

Check out Updated Web Services Policy Specifications

WS-Policy and WS-PolicyAttachment have been republished based on community feedback. Updates include enhancements to the policy framework.

List of changes are:

• Updated all the examples to use Policy Assertions from 2005/07 Web Services Security Policy and 2005/02 Web Services Reliable Messaging Policy; plus, few editorial changes
• Removed @targetNamespace because it is redundant
• Added optional wsp:Policy/@Name to identify a Policy Expression using a URI
• Removed wsp:UsingPolicy (use @wsdl:required on wsp:PolicyReference instead) because it is redundant
• Prohibited circular references with wsp:PolicyReference
• Promoted WS-Security Policy’s Nested Policy Expression to WS-Policy Framework based on feedback from the security community

Link - http://schemas.xmlsoap.org/ws/2004/09/policy/

At Microsoft, I am a technical diplomat and responsible for standardizing and building industry momentum around WS-Policy specifications. For this publication, I had the pleasure of working with specification authors from BEA, IBM, Microsoft, SAP, Sonic Software and VeriSign.