Using the WS-Schema Validation Policy
Learn about the WS-Schema Validation Policy and policy configuration options.
For information about using policies in the context of the Community Manager developer portal, see Business Policies.
Table of Contents
- Introduction
- Creating a WS-Schema Validation policy
- Schema Validation Behavior
- Configuration Options
- Configuration
- Activating a policy
- Attaching a policy
- 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.
Creating a WS-Schema Validation policy
To add an operational policy
- Go to Workbench > Browse > Organization, and select Policies > Operational Policies. The Policies Summary is displayed.
- Click Add Policy.
- Choose the policy type and click Next.
- Specify a name (required) and description (optional) and click Finish. At the Completion Summary, click Close. 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.
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. |
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:
- Select the schemas you would like to add to the policy in the left column, and use >> to copy them to the right column.
- Select the validation mode (Lax or Strict).
- 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, activate it. You can then 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.
Activating a policy
When you create and configure a policy, the policy is in Draft state. When the policy configuration is complete, activate the policy: click Activate Policy and then confirm. See Activate a Policy.
A policy in Draft state is not available for general use. Once you activate the policy, it is in Active state and is available for use.
Attaching a policy
To use the policy, go to the Policies folder in the respective organization and attach the policy to a web service, binding, or binding operation.
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:
- Scenario 1: Runtime with "LAX"
- Scenario 2: Runtime with "Strict" (Valid Schema is not Selected)
- Scenario 3: Runtime with "Strict" (Valid Schema is Enabled)
- Scenario 4: Runtime with "Strict" (Child Elements included in SOAP Request)
- Scenario 5: Runtime with "LAX" (Child Elements included in SOAP Request)
Scenario 1: Runtime with "LAX"
- Create a physical service. For example: http://10.7.20.21/EchoSan/Echo.asmx?wsdl.
- Virtualize and host it on Network Director (Example service name: Vs1).
- Configure a WS-Schema Validation Policy.
- Attach the Detailed Auditing and WS-Schema Validation policies to the Vs1 service.
- 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>
- Send a request from a client, such as SoapUI. The request will be processed successfully.
- Navigate to the Vs1 service and then choose Monitoring > Logs.
Request Message:
Response Message:
Scenario 2: Runtime with "Strict" (Valid Schema is not Selected)
- Create a physical service. For example: http://10.7.20.21/EchoSan/Echo.asmx?wsdl.
- Virtualize and host it on Network Director (Example service name: Vs1).
- Configure a WS-Schema Validation Policy.
- Attach the Detailed Auditing and WS-Schema Validation policies to the Vs1 service.
- 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>
- Send a request from a client; for example, SoapUI. The request will fail.
- 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
- Create a physical service. For example: http://10.7.20.21/EchoSan/Echo.asmx?wsdl.
- Virtualize and host it on Network Director (Example service name: Vs1).
- Configure a WS-Schema Validation Policy.
- Attach the Detailed Auditing and WS-Schema Validation policies to the Vs1 service.
- 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>
- Send a request from client (SOAP UI). Request will be processed successfully.
- 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
- Create a physical service. For example: http://10.7.20.21/EchoSan/Echo.asmx?wsdl.
- Virtualize and host it on Network Director (Example Service Name: Vs1).
- Configure a WS-Schema Validation Policy.
- Attach the Detailed Auditing and Ws-Schema Validation policies to the Vs1 service.
- 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>
- Send a request from a client; for example, SoapUI. The request will fail.
- 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
- Create a physical service. For example: http://10.7.20.21/EchoSan/Echo.asmx?wsdl.
- Virtualize and host it on Network Director (Example service name: Vs1).
- Configure a WS-Schema Validation Policy.
- Attach the Detailed Auditing and WS-Schema Validation policies to the Vs1 service.
- 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>
- Send a request from a client; for example, SoapUI. The request will fail.
- 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.