What Is WS-Policy: Declaring XML Constraints

Web Services Policy (WS-Policy) is a standard specification within the WS-* framework that provides a flexible, extensible grammar for expressing the capabilities, requirements, and operational constraints of a web service. This article covers the fundamental architecture of WS-Policy, explains how XML expressions define rules such as security and quality of service, and details how service consumers and providers use these declarations to achieve interoperable communication.

Understanding the Role of WS-Policy

In Service-Oriented Architecture (SOA), web services often require specific behaviors to interact properly—such as message encryption, authentication mechanisms, reliable messaging, or addressing protocols. While standard Web Services Description Language (WSDL) documents define what a service does (interfaces, operations, and data types), WS-Policy defines how a service must be accessed in terms of operational rules and constraints.

By standardizing these rules into machine-readable XML metadata, WS-Policy eliminates the need for out-of-band communication or custom documentation to establish operational requirements between a client and a server.

Core Concepts and XML Constructs

WS-Policy defines policies using specific XML constructs defined within the WS-Policy namespace (http://schemas.xmlsoap.org/ws/2004/09/policy or http://www.w3.org/ns/ws-policy). The architecture relies on three primary building blocks:

1. Policy Assertions

A policy assertion represents an individual domain-specific requirement, capability, or preference. For example, assertions can mandate the use of WS-Security, digital signatures, or specific token profiles.

<sp:TransportBinding xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
    <!-- Domain-specific assertion details -->
</sp:TransportBinding>

2. Policy Operators

Policy operators define logical combinations of policy assertions to indicate required combinations or acceptable alternatives:

• <wsp:All>: A logical AND. All nested assertions must be satisfied.
• <wsp:ExactlyOne>: A logical XOR. Exactly one of the nested assertion alternatives must be satisfied.

3. Policy Expressions

A policy expression is an XML container (the <wsp:Policy> element) containing assertions and operators that describe the overall requirements of the service endpoint or message.

Declaring Constraints via XML: An Example

The following example demonstrates a policy declaring that an endpoint requires HTTPS transport-level security alongside a username token:

<wsp:Policy wsu:Id="SecureServicePolicy"
    xmlns:wsp="http://www.w3.org/ns/ws-policy"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
    <wsp:ExactlyOne>
        <wsp:All>
            <sp:TransportBinding>
                <wsp:Policy>
                    <sp:TransportToken>
                        <wsp:Policy>
                            <sp:HttpsToken RequireClientCertificate="false"/>
                        </wsp:Policy>
                    </sp:TransportToken>
                </wsp:Policy>
            </sp:TransportBinding>
            <sp:SupportingTokens>
                <wsp:Policy>
                    <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"/>
                </wsp:Policy>
            </sp:SupportingTokens>
        </wsp:All>
    </wsp:ExactlyOne>
</wsp:Policy>

In this declaration: 1. The <wsp:Policy> root encapsulates the rules under the identifier SecureServicePolicy. 2. The <wsp:ExactlyOne> element combined with <wsp:All> defines a single mandatory policy alternative. 3. The nested domain assertions (<sp:TransportBinding> and <sp:SupportingTokens>) inform the client that communications must use HTTPS and include a Username Token for authentication.

Policy Attachment and Runtime Evaluation

Policy expressions are associated with specific WSDL elements using the WS-PolicyAttachment specification. Policies can be bound at various scopes:

• Service Scope: Applies to the entire web service.
• Endpoint/Binding Scope: Applies to a specific transport or protocol binding.
• Operation Scope: Applies only to specific service operations (e.g., requiring stricter encryption for financial transactions).
• Message Scope: Applies exclusively to input, output, or fault messages.

A WSDL document references a policy using the <wsp:PolicyReference> element:

<wsdl:binding name="SecureServiceBinding" type="tns:SecureServicePortType">
    <wsp:PolicyReference URI="#SecureServicePolicy"/>
    <!-- Standard SOAP binding elements -->
</wsdl:binding>

When a client consumes the WSDL, its policy engine parses the referenced policy tree, evaluates its own local capabilities against the declared assertions, and automatically configures its outbound SOAP handlers (e.g., generating required security headers and applying encryption) to match the service’s operational constraints.