Using the WS-Schema Validation Policy

Learn about the WS-Schema Validation Policy and policy configuration options.

About Policies Managing Policies About Operational Policies

Supported Platforms: 7.x, 8.0

Table of Contents

  1. Introduction
  2. Creating a WS-Schema Validation policy
  3. Schema Validation Behavior
  4. Configuration Options
  5. Configuration
  6. WS-Schema Validation Policy: use cases for Policy Manager

Introduction

A common integration problem in an SOA occurs when consumers send messages to services that don’t conform to the service's message schemas. Typically this is caused by the versioning of a service’s schema and a consumer sending a message defined in the prior schema version. However, it can also be a consumer's malicious attempt to cause a denial of service by sending invalid messages to a service.

A Manageability Container can help by validating the messages exchanged between the consumers and services against the service’s published schema.

Configuring the container to perform schema validation of messages is performed by defining the schema validation policies. The policies indicate which messages to validate and possibly indicate additional schemas to validate against that might not be defined in the service’s WSDL document. Additional schemas are typically required when validating expected headers in a bound (SOAP) message.

back to top

Creating a WS-Schema Validation policy

To add an operational policy
  1. Go to Workbench > Browse > Organization, and select Policies > Operational Policies. The Policies Summary is displayed.
  2. Click Add Policy.
  3. Choose the policy type and click Next.
  4. Specify a name (required) and description (optional) and click Finish. The Add Policy Wizard creates a draft policy instance that you can then configure on the Policy Details page.

For more information, see Add Policy.

back to top

Schema Validation Behavior

  • If schemas are not selected as part of the policy configuration, the policy validates based on the schema or schemas in the WSDL. This is default behavior.
  • If schemas are selected in the policy configuration and also exist in the WSDL, the policy validates the selected schemas in the policy configuration and the schema or schemas in the WSDL.

Configuration Options

The policy includes the configuration options listed below.

Option Description
Select Schemas Displays a list of schemas that are available in the file system, that can be selected and added to the policy.
Validation Mode

Select Lax or Strict XML validation mode.

Lax: Validates only the XML elements that have a namespace that matches a namespace of an associated schema. Elements with no namespace, or those that do not have a namespace that matches a schema namespace, are skipped and not validated. Lax validation is less stringent than strict validation, and is the default validation type.

Strict: Validates all XML elements against the applied schemas. Each XML element must have a namespace that matches a namespace of an associated schema, or validation fails.

back to top

Configuration

Let's take a quick walkthrough of the WS-Schema Validation Policy configuration process to get you started.

Step 1: Add Policy / Use System Policy

In Policy Manager, to create a WS-Schema Validation Policy instance, go to Policies > Operational Policies and choose Add Policy.

Step 2: Modify Policy

When you click Modify to make changes to the WS-Schema Validation Policy on the Policy Details page, the initial policy looks like this:

Step 3: Configure

Configuring the WS-Schema Validation Policy is one step in a larger process.

To configure the WS-Schema Validation Policy:
  1. Select the schemas you would like to add to the policy in the left column, and use >> to copy them to the right column.
  2. Select the validation mode (Lax or Strict).
  3. Review the policy use cases for each validation mode for the complete process and follow the applicable steps. See WS-Schema Validation Policy: use cases for Policy Manager.
Step 4: Attach Policy

After you've saved your policy, you can attach it to a web service or you can attach the policy at the Organization level and the policy will be active for all services defined within the organization.

Back to top

WS-Schema Validation Policy: use cases for Policy Manager

This section provides a list of Policy Manager-specific usage scenarios for the WS-Schema Validation Policy.

It includes:

  1. Scenario 1: Runtime with "LAX"
  2. Scenario 2: Runtime with "Strict" (Valid Schema is not Selected)
  3. Scenario 3: Runtime with "Strict" (Valid Schema is Enabled)
  4. Scenario 4: Runtime with "Strict" (Child Elements included in SOAP Request)
  5. Scenario 5: Runtime with "LAX" (Child Elements included in SOAP Request)

Scenario 1: Runtime with "LAX"

  1. Create a physical service. For example: http://10.7.20.21/EchoSan/Echo.asmx?wsdl.
  2. Virtualize and host it on Network Director (Example service name: Vs1).
  3. Configure a WS-Schema Validation Policy.

  4. Attach the Detailed Auditing and WS-Schema Validation policies to the Vs1 service.
  5. Create a project in a client, such as SoapUI, using the Vs1 WSDL URL.

    Actual SOAP Request:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
      <soapenv:Header/>
      <soapenv:Body>
        <tem:Echo>
          <!--Optional:-->
          <tem:s>?</tem:s>
        </tem:Echo>
      </soapenv:Body>
    </soapenv:Envelope>

    Update SOAP Request with WS-Addressing Elements:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
      <soapenv:Header>
        <wsa:Action></wsa:Action>
      </soapenv:Header>
      <soapenv:Body>
        <tem:Echo>
          <!--Optional:-->
          <tem:s>?</tem:s>
        </tem:Echo>
      </soapenv:Body>
    </soapenv:Envelope>
        
  6. Send a request from a client, such as SoapUI. The request will be processed successfully.
  7. Navigate to the Vs1 service and then choose Monitoring > Logs.

    Request Message:

    Response Message:

Scenario 2: Runtime with "Strict" (Valid Schema is not Selected)

  1. Create a physical service. For example: http://10.7.20.21/EchoSan/Echo.asmx?wsdl.
  2. Virtualize and host it on Network Director (Example service name: Vs1).
  3. Configure a WS-Schema Validation Policy.

  4. Attach the Detailed Auditing and WS-Schema Validation policies to the Vs1 service.
  5. Create a project in client (SOAP UI) using Vs1 WSDL URL:

    Actual SOAP Request:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
      <soapenv:Header/>
      <soapenv:Body>
        <tem:Echo>
          <!--Optional:-->
          <tem:s>?</tem:s>
        </tem:Echo>
      </soapenv:Body>
    </soapenv:Envelope>

    Update SOAP Request with WS-Addressing Elements:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
      <soapenv:Header>
        <wsa:Action></wsa:Action>
      </soapenv:Header>
      <soapenv:Body>
        <tem:Echo>
          <!--Optional:-->
          <tem:s>?</tem:s>
        </tem:Echo>
      </soapenv:Body>
    </soapenv:Envelope>
    
  6. Send a request from a client; for example, SoapUI. The request will fail.
  7. Navigate to the Vs1 service and then choose Monitoring > Logs

    Request Message:

    Error Message:

    XML is not valid [cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'wsa:Action'.]

    Note: Valid schema is not selected.

Scenario 3: Runtime with "Strict" (Valid Schema is Enabled)

Schema Name: http://schemas.xmlsoap.org/ws/2004/08/addressing

  1. Create a physical service. For example: http://10.7.20.21/EchoSan/Echo.asmx?wsdl.
  2. Virtualize and host it on Network Director (Example service name: Vs1).
  3. Configure a WS-Schema Validation Policy.

  4. Attach the Detailed Auditing and WS-Schema Validation policies to the Vs1 service.
  5. Create a project in a client, such as SoapUI, using the Vs1 WSDL URL.

    Actual SOAP Request:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
      <soapenv:Header/>
      <soapenv:Body>
        <tem:Echo>
          <!--Optional:-->
          <tem:s>?</tem:s>
        </tem:Echo>
      </soapenv:Body>
    </soapenv:Envelope>

    Update SOAP Request with WS-Addressing Elements:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
      <soapenv:Header>
        <wsa:Action></wsa:Action>
      </soapenv:Header>
      <soapenv:Body>
        <tem:Echo>
          <!--Optional:-->
          <tem:s>?</tem:s>
        </tem:Echo>
      </soapenv:Body>
    </soapenv:Envelope>
  6. Send a request from client (SOAP UI). Request will be processed successfully.
  7. Navigate to the Vs1 service and then choose Monitoring > Logs.

    SOAP Request:

    SOAP Response:

Scenario 4: Runtime with "Strict" (Child Elements included in SOAP Request)

Schema Name: http://schemas.xmlsoap.org/ws/2004/08/addressing

  1. Create a physical service. For example: http://10.7.20.21/EchoSan/Echo.asmx?wsdl.
  2. Virtualize and host it on Network Director (Example Service Name: Vs1).
  3. Configure a WS-Schema Validation Policy.

  4. Attach the Detailed Auditing and Ws-Schema Validation policies to the Vs1 service.
  5. Create a project in client (SOAP UI) using Vs1 WSDL URL:

    Actual SOAP Request:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
      <soapenv:Header/>
      <soapenv:Body>
        <tem:Echo>
          <!--Optional:-->
          <tem:s>?</tem:s>
          </tem:Echo>
    </soapenv:Body>
    </soapenv:Envelope>

    Update SOAP Request with WS-Addressing Elements:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
      <soapenv:Header>
        <wsa:Action><wsa:Address></wsa:Address></wsa:Action>
      </soapenv:Header>
      <soapenv:Body>
        <tem:Echo>
          <!--Optional:-->
          <tem:s>?</tem:s>
        </tem:Echo>
      </soapenv:Body>
    </soapenv:Envelope>
  6. Send a request from a client; for example, SoapUI. The request will fail.
  7. Navigate to the Vs1 service and then choose Monitoring > Logs.

    SOAP Request:

    Error Message:

    XML is not valid [cvc-complex-type.2.2: Element 'wsa:Action' must have no element [children], and the value must be valid.]

Scenario 5: Runtime with "LAX" (Child Elements included in SOAP Request)

Schema Name: http://schemas.xmlsoap.org/ws/2004/08/addressing

  1. Create a physical service. For example: http://10.7.20.21/EchoSan/Echo.asmx?wsdl.
  2. Virtualize and host it on Network Directory (Example service name: Vs1).
  3. Configure a WS-Schema Validation Policy.

  4. Attach the Detailed Auditing and WS-Schema Validation policies to the Vs1 service.
  5. Create a project in a client, such as SoapUI, using the Vs1 WSDL URL.

    Actual SOAP Request:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
      <soapenv:Header/>
      <soapenv:Body>
        <tem:Echo>
          <!--Optional:-->
          <tem:s>?</tem:s>
        </tem:Echo>
      </soapenv:Body>
    </soapenv:Envelope>
    

    Update SOAP Request with WS-Addressing Elements

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
      <soapenv:Header>
        <wsa:Action><wsa:Address></wsa:Address></wsa:Action>
      </soapenv:Header>
      <soapenv:Body>
        <tem:Echo>
          <!--Optional:-->
          <tem:s>?</tem:s>
        </tem:Echo>
      </soapenv:Body>
    </soapenv:Envelope>
    
  6. Send a request from a client; for example, SoapUI. The request will fail.
  7. Navigate to the Vs1 service and then choose Monitoring > Logs.

    SOAP Request:

    Error Message:

    XML is not valid [cvc-complex-type.2.2: Element 'wsa:Action' must have no element [children], and the value must be valid.]

Notes

  • Lax
    • If corresponding schema is not added to policy, the tags will be ignored by parser.
    • If corresponding schema is added to policy, the tags will be validated by parser.
  • Strict
    • If corresponding schema is not added to policy, an error will occur saying schema should be added to the policy.
    • If corresponding schema is added to policy, the tags will be validated by parser.

Back to top