Using the Schema Validation Policy

Learn about the Schema Validation Policy Assertion, supported policy subjects, and how to configure a Schema Validation Policy.

For information about using policies in the context of the Community Manager developer portal, see Business Policies.

Table of Contents

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 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.

Specification:

Schema Validation Policy Assertion

The syntax of the Schema Validation Policy assertion is shown below.

Syntax

gsvp:SchemaValidation
Schema Validation policy assertion element.
gsvp: SchemaValidation /@{any}
Additional attributes CAN be specified but MUST NOT contradict the semantics of the [owner element]; if an attribute is not recognized, it SHOULD be ignored.
gsvp: SchemaValidation /{any}
An extensibility mechanism to allow additional elements to be specified.

An example of a Schema Validation Policy is shown below.

Configuration Options

This policy does not require any configuration. Instead, you attach the policy to the physical WSDL policy attachment points (described below).

Scope

The schema validation policy assertion is allowed to have the following Policy Subjects as defined in the WS-PolicyAttachment specification:

  • Service Policy Subject
  • Endpoint Policy Subject
  • Operation Policy Subject

The WS-PolicyAttachment specification defines a set of WSDL/1.1 policy attachment points for each of the above Policy Subjects. A schema validation policy assertion MAY be attached to the following abstract WSDL policy attachment points:

  • wsdl:service
  • wsdl:port
  • wsdl:portType
  • wsdl:portType/wsdl:operation
  • wsdl:portType/wsdl:operation/wsdl:input
  • wsdl:portType/wsdl:operation/wsdl:output
  • wsdl:portType/wsdl:operation/wsdl:fault

When attached to abstract WSDL policy attachment points, only the normalized message is validated against the schema.

A schema validation policy assertion MAY be attached to the following physical WSDL policy attachment points.

  • wsdl:binding
  • wsdl:binding/wsd:operation
  • wsdl:binding/wsd:operation/wsdl:input
  • wsdl:binding/wsd:operation/wsdl:output
  • wsdl:binding/wsd:operation/wsdl:fault

When attached to physical policy attachment points, the entire bound message is validated against the schema. For example, the entire SOAP envelope, including its headers, is validated against the service's schema and all additional schemas referenced in the policy assertion.

A schema validation policy dictates behavior that is not required in order to exchange messages between consumers and providers. Instead, it dictates behavior that should be transparent to the consumer and provider and should not affect message exchanges at all. Therefore it is recommended that caching policies be classified as private by including the gsvp:Visibility attribute in the enclosing wsp:Policy element with a value of private.

The following is an example of a caching policy attached to WSDL components.

Binding Support

The Schema Validation Policy supports HTTP and POX bindings only.

Configuration

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

Step 1: Add Policy / Use System Policy

You can create a Schema Validation policy instance using Add Policy in the Policies > Operational Policies section.

Step 2: Configure

The Schema Validation Policy itself does not require any configuration. Instead, you attach the policy to the physical WSDL policy attachment points (described above). For more information on the configuration and test cycle, review the use case: Schema Validation Policy: use case for Policy Manager.

Step 3: Activate and attach policy

When the policy configuration is complete, activate the policy so that you can use it. You can then attach it:

  • To an individual web service to apply it to that service.
  • At the Organization level to apply it to all services defined within the organization.
  • Directly to any of the supported policy attachments points (listed above).

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.

Schema Validation Policy: use case for Policy Manager

This section provides a list of Schema Validation Policy usage scenarios.

It includes:

  1. Scenario 1: Request with Valid Data Type
  2. Scenario 2: Request with Invalid Data Type

Note: This policy supports HTTP and POX bindings only.

Scenario 1: Request with Valid Data Type

  1. Create a physical service.
  2. Virtualize and host it on Network Director (for example, Vs1).
  3. Configure a Schema Validation Policy.

  4. Attach the Detailed Auditing and Schema Validation policies to the Vs1 service.
  5. Send a valid request from a REST client. An example is shown below. The request will be processed successfully.

Content in Body: 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><Account xmlns="http://soa.com/jaxrs/account/1.0">
<ID>1111</ID> 
<FirstName>Bill</FirstName>
<LastName>Gates</LastName>
</Account>

SOAP Request:

Response Message:

Scenario 2: Request with Invalid Data Type

  1. Create a physical service.
  2. Virtualize and host it on Network Director (Example service name: VS1).
  3. Configure a Schema Validation Policy.

  4. Attach the Detailed Auditing and Schema Validation policies to the Vs1 service.
  5. Send a valid request from a REST client. The request will fail with a valid error message.

Content in Body: 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><Account xmlns="http://soa.com/jaxrs/account/1.0">
  <ID>Test</ID> --- Invalid data type
  <FirstName>Bill</FirstName>
  <LastName>Gates</LastName>
  </Account></pre>

SOAP Request:

Response Message: