xi 3[1].6.0-example configs

WebSphere® DataPower XML Integration Appliance XI50

Example Configurations

Release 3.6.0

��

IBM WebSphereDataPower XML Integration Appliance XI50

Example ConfigurationsRelease 3.6.0

WebSphere DataPower

First Edition (October 2006)This edition applies to version 3, release 6, modification 0 of IBM WebSphere DataPower XML Integration Appliance XI50

© Copyright International Business Machines Corporation 2002, 2006. All rights reserved.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Release 3.6 iii

Table of Contents

Chapter 1Human Resources Web Portal

Scenario A: Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1XML Firewall Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Rule #1: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7Rule #2: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15Rule #3: Error Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18

Duration Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20Message Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20Message Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21Message Filter Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22Duration Monitor Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23

Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25Object Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26Event Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27

Scenario B: An HTML Forms Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28XML Firewall Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-33

Rule #1: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-33Rule #2: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-45Rule #3: Error Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-48

SSL Server Crypto Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-50Crypto Identification Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51Crypto Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51Crypto Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-52

Scenario C: Multi-Protocol, Single Port Service . . . . . . . . . . . . . . . . . . . . . . . . . . 1-53XML Firewall Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-54Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-58

Rule #1: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-58Rule #2: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-64Rules 3 to 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-68

Chapter 2Bank Checking Web Service

XML Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8Rule #1: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

Match Rule: Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9Implied Action 0: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

iv Release 3.6

Action 1: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10Action 2: Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12Action 3: Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14Action 4: AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15AAA Policy: SAML-Attr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16Action 5: Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20

Rule #2: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Match Rule: Encrypted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Action 1: Decrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Action 2: Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24

Rule #3: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25Match Rule: Signed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25Action 1: Verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26Action 2: Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27Action 3: Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28

Rule #4: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31Match Rule: Signed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31Action 1: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31Action 2: Encrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32Action 3: Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33

Rule #5: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35Match Rule: Encrypted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35Action 1: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-36Action 2: Encrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37

Rule #6: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46

Object Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47Event Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47

SSL Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-49Crypto Identification Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50Crypto Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50Crypto Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51

SomeBank Checking Service WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-52

Chapter 3Multi-Protocol Gateway

Multi-Protocol Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Advanced Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5XML Threat Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6

Single Message XML Denial of Service (XDOS) . . . . . . . . . . . . . . . . . . . 3-7Multiple Message XML Denial of Service (MMDOS) . . . . . . . . . . . . . . . . 3-7

Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Front Side Protocol Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9

HTTP Front Side Protocol Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9HTTPS Front Side Protocol Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10MQ Front Side Protocol Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11Websphere MQ Queue Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12

Multi-Protocol Gateway Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15

Release 3.6 v

Rule #1: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17Match Rule: Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17Implied Action 0: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17Action 1: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18Action 2: Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20Action 3: Verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22Action 5: Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

Rule #2: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24Match Rule: Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24Action 1: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24Action 3: Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25

Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28Object Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29Event Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30

SSL Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31SSL Proxy Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31Crypto Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32Crypto Identification Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33Crypto Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34Crypto Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34

Validation Credential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35

Chapter 4Example Web Application Firewall

Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Application Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

Request Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4Response Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6Error Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

Error Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12Web Request Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

HTML Form Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12XML-Based Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16

Web Response Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20Rate Limiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23Name Value Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24

HeaderFilter Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24Suppressor Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26XycoPost Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28

Chapter 5SOAP with Attachments

XML Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4

Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5Rule #1: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7Rule #2: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11Rule #3: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Rule #4: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18Rule #5: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22

vi Release 3.6

Rule #6: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24Rule #7: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27Rule #8: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32Rule #9: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34

Additional Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37Base64 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37Attachment Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37DIME Attachment Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38

NoticesTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notices-1

1 - 1

Chapter 1Human Resources Web Portal

This example configuration implements a human resources web portal benefits service, allowing employees to request services from human resources through a web interface.

Scenario A: Web ServicesThe service is implemented initially to support departmental application servers submitting well-formed SOAP requests to the DataPower system. The application servers interact with the end user browsers. The headquarters IT systems employ task-specific Web service endpoints to handle the range of HR information needs. Here is an illustration of the architecture involved.

Figure 1 - 1. HR Web Service architecture

The traffic is monitored for transaction times that exceed a configured threshold. All errors are logged in a special log target built for this service.

DataPower

Web Service 1

Web Service 2

Web Service 3

App Servers

SOAPSOAP

SOAP

Browsers

HTML

Human Resources Web Portal

1 - 2 Release 3.6

Here is an example SOAP request supported by this service:<?xml version="1.0" encoding="UTF-8"?><S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<S11:Header><wsse:Security>

<wsse:UsernameToken><wsse:Username>sfelinish</wsse:Username><wsse:Password>99cat99</wsse:Password>

</wsse:UsernameToken></wsse:Security>

</S11:Header><S11:Body>

<xycohr:request xmlns:xycohr="http://xycohr.com/hrservices"><xycohr:First_Name>Samantha</xycohr:First_Name><xycohr:Last_Name>Felinish</xycohr:Last_Name><xycohr:Employee_ID>7636356</xycohr:Employee_ID><xycohr:Department>Sales</xycohr:Department><xycohr:Requested_Service>floatholiday</xycohr:Requested_Service><xycohr:Service_Date>05/01/2005</xycohr:Service_Date>

</xycohr:request></S11:Body>

</S11:Envelope>

This implementation employs the following configured DataPower components.• XML Firewall• XML Firewall Policy• Document Processing Rules • Document Processing Actions• XPath Routing Map• Duration Monitor• Log Target

In addition, service-specific stylesheets and schema files were uploaded to the device.

Scenario A: Web Services

Release 3.6 1 - 3

XML Firewall ServiceThe XML Firewall Service configuration page appears as shown here.

Figure 1 - 2. Web Services Firewall Configuration

These are the field values.Firewall Name: XycoHRServices

The name of the firewall object. This name may appear in the Via: field of the HTTP headers returned during SOAP and XML web service transactions. It also appears in the log files.

Firewall Type: Dynamic backend

The selection Dynamic backend indicates that the servers to which the firewall will forward requests are determined dynamically by the firewall’s document processing policy. In this case the determination is accomplished through a Route action that in turn employs an XPath Routing Map.

XML Manager: Default

The default is left in place. Firewall Policy: XycoHRServices

The custom policy built for this service, XycoHRServices, is selected. This policy is covered in detail below.


1 - 4 Release 3.6

URL Rewrite Policy: None

The default is left in place. The URLs sent by the clients are not altered in any way.

Back EndSSL Client Crypto Profile: None

The default is left in place. Communication with the back end servers will not employ SSL in this case.

Response Type: SOAPThe selection SOAP indicates that the back end servers will post SOAP documents in response to requests from the firewall service. The firewall service automatically validates the documents against the SOAP schemas now in use (SOAP 1.1, 1.2 and variants).

Response Attachments: Strip

The default value (strip) is left in place. Any attachments sent by the back end service will be stripped off before the message is handled by the firewall service.

Front EndDevice Address: 0.0.0.0

The default value of 0.0.0.0 is used. The service will listen at the port indicated on all ethernet addresses configured for the current device.

Device Port: 2065

The automatically assigned value of 2075 is used. This could be altered to any value not used by another service on the current device. All traffic bound for this service must use port number 2075. The SOAP HTTP URL resembles http://10.10.13.35:2075/services.

SSL Server Crypto Profile: None

The default is left in place. Communication with the front end clients will not employ SSL in this case.

Request Type: SOAP

The selection SOAP indicates that the clients will post SOAP-formatted documents to the firewall service. Inbound SOAP documents are automatically validated against the published SOAP schemas. If the messages do not comply with the schemas, an error is returned to the client.

Request Attachments : Strip

The default value (strip) is left in place. Any attachments sent by the clients will be stripped off before the message is handled by the firewall service.


Release 3.6 1 - 5

Here is the Advanced configuration page for this service:

Figure 1 - 3. Advanced configuration page

All defaults are left in place with the exception of the Message Duration Monitor. Here, the custom configured Xycohr Duration Monitor is assigned to the service.


1 - 6 Release 3.6

Firewall PolicyHere is the graphic representation of the firewall policy used for this implementation.

Figure 1 - 4. XycoHRServices Firewall Policy

Here is a brief explanation of the column headings under Configured Rules:Priority The order in which the rules are executed by the policy.

When two rules have a matching rule that could potentially match the inbound document, the rule with the highest priority executes first.

Match Name This lists the name of the Matching Rule used to select inbound traffic for execution by the processing actions contained in the rule.

Direction This indicates the directionality of the rule. Request rules handle inbound traffic from the front end clients, response rules handle responses from the back end services, and Error rules execute when an error is encountered.

Actions The iconic representation of the actions contained in the rule.Click on any of the rules listed here to make the rule the current rule. The main display of the page changes to that rule. The action configurations can then be modified.


Release 3.6 1 - 7

Rules

Rule #1: Request RuleHere is an examination of the components of Rule #1. Note that this is a Request rule; it will only handle messages sent to the service by the client and will not handle messages sent by the server back to the client.Match Rule: ServicesA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 1 - 5. Services Match Rule Configuration

The client must use the URL */services or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”Implied Action 0: ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it. However, the presence of this valildation action can cause inbound messages to be rejected by the firewall before any of the actions visible in the Firewall Policy have run.


1 - 8 Release 3.6

Action 1: ValidateThe first custom action of Rule #1 validates the contents of the SOAP Body element against a custom schema. This insures that the payload also contains the required elements and does not contain invalid elements. Here is the configuration of this action:

Figure 1 - 6. Validate Configuration

Input: INPUTThis is set to INPUT, the special context representing the original message received by the service.

Schema Validation Method: Schema URL

This is set to validate the document using a schema URL. A URL must be provided that identifies the location of the schema file to use.

Schema URL: local:///Xycohr.xsd

This is set to local:///Xycohr.xsd. The custom schema file has been uploaded to the device and placed in the local: directory.

Output: tmpvar2

This is set to tmpvar2. The results of the validation will be placed in this context. If the input is valid, the context will contain the validated message. If an error occurs (the message fails to validate, for example), the context is empty. Any subsequent actions can access the results by using tmpvar2 as the input context.


Release 3.6 1 - 9

Here is the schema file used for this action.<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xycohr="http://xycohr.com/hrservices" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" target-Namespace="http://xycohr.com/hrservices" elementFormDefault="qualified">

<xs:element name="request" type="xycohr:hrrequest"/><xs:complexType name="hrrequest">

<xs:sequence><xs:element name="UserName" type="xs:string" minOccurs="0"/><xs:element name="Password" type="xs:string" minOccurs="0"/><xs:element name="First_Name" type="xs:string"/><xs:element name="Last_Name" type="xs:string"/><xs:element name="Employee_ID" type="xs:string"/><xs:element name="Department" type="xs:string"/><xs:element name="Requested_Service" type="xs:string"/><xs:element name="Service_Date" type="xs:string"/>

</xs:sequence></xs:complexType>

</xs:schema>

Action 2: FilterThis action filters the validated message for the presence of required values within the message. It either accepts or rejects the message. Here is the configuration display for this action:

Figure 1 - 7. Filter Configuration

Input: tmpvar2

This is set to tmpvar2, the named context used by the preceeding action. Note that this could have been set to INPUT since this action would not execute if the validation before it failed. However, validation can sometimes change the message format, thus this action uses the result of the validation.

1 - 10 Release 3.6

Processing Control File: local:///Xycohr.xsl

This is set to local:///Xycohr.xsl. The custom XSLT file has been uploaded to the device and placed in the local: directory.

Output: (blank)

This is set to be automatically generated by the policy configuration page. Unlike a transform or a validate action, a filter action typically does not return a nodeset. It accepts or rejects the input for further processing by the next action in the rule.

Here is the XSLT file used for this Filter action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" extension-element-prefixes="dp" xmlns:dp="http://www.datapower.com/extensions" exclude-result-prefixes="dp">

<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/><xsl:template match="/"> 

<xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='request']"/>

</xsl:template><xsl:template match="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='request']">

<xsl:variable name="errtext" select="'Incomplete Input'"/><xsl:variable name="errtest">

<xsl:for-each select="./*"><xsl:if test="string-length() = 0">

<xsl:value-of select="local-name()"/>:</xsl:if>

</xsl:for-each></xsl:variable><xsl:choose>

<xsl:when test="$errtest != ''"><dp:xreject reason="$errtext"/><xsl:message dp:type="xmlfirewall" dp:priority="error"> <xsl:value-of select="$errtest"/></xsl:message>

</xsl:when><xsl:otherwise>

<dp:accept/></xsl:otherwise>

</xsl:choose></xsl:template>

</xsl:stylesheet>


Release 3.6 1 - 11

Action 3: TransformThis tranform action serves to connect the last context that contained the possibly altered message to any actions that follow. The policy configuration page automatically creates this action following a filter. Here is the configuration page display for this action.

Figure 1 - 8. Transform Configuration

Input: tmpvar2


Document Processing Instructions: Specified by rule

This is set to use an XSLT file specified in this rule rather than any instructions contained within the XML message itself.

Processing Control File: store:///identity.xsl

This is set to store:///identity.xsl. This XSLT file is supplied with the firmware. It simply copies the input to the output context.

Output tempvar3

This is set to tempvar3. The policy configuration page automatically assigned this context name.


1 - 12 Release 3.6

Action 4: RouteThis action dynamically routes the message to a target destination, which is, in this scenario, one of three Web service endpoints. This action uses an XPath Routing Map object to determine the proper destination target.

Figure 1 - 9. Route Configuration

Input: tempvar3

This is set to tempvar3, the named Output context used by the preceeding action.

Selection Method: XPath Routing Map

This is set to use an XPath Routing Map.XPath Routing Map: xycohr

This is set to xycohr. This is the name of a configured XPath Routing Map object that uses XPath expressions to extract values from the message. Those values are then used to match the message with a destination target. The XPath Routing Map is explained below.

Output: (Blank)

This is set to blank. A Route action does not output a nodeset. Note that because it does not, it will be necessary to include one more action in the rule to connect the last context that contains the full message to the special OUTPUT context, which is what is sent out on the wire to the destination target.

XPath Routing Map: xycohrAn XPath Routing Map associates an XPath expression with a destination URL. When the XPath expression evaluates to true, the target destination for the message is set to the corresponding URL. These mappings for this implementation are shown in Figure X below. An XPath Routing Map object can also use Namespace Mappings to associate namespace prefixes in the XPath expression maps to namespace URIs. This shortens the length of the XPath expressions while preserving namespace information. This example does not use namespace mapping.


Release 3.6 1 - 13

Here is the configuration display of this object.

Figure 1 - 10. XPath Routing Map Configuration

Note that the destinations are mapped according to the value of the Requested_Service node. These are mapped to endpoint operations at the destination server ports. If no match is found by this Route action using the above mappings, the object returns an error to the client. The next object never executes.Action 5: TransformLike Action 3, this transform connects the last context containing the message to the next action, or to the OUTPUT context. This is necessary because the Route action does not return a nodeset when doing its work. This is the final action of the rule; if this action executes at all, then the Route has succeeded and all is clear for delivery to the back end service.


1 - 14 Release 3.6

Here is the configuration display for this object.


Input: tempvar3

This is set to tempvar3, the named output context used by the action preceeding the Route action.


This is set to store:///identity.xsl. This stylesheet is supplied with the firmware.Output: OUTPUT

This is set to OUTPUT, the special context that is delivered to the wire. As this is the last action of the rule, whatever is in this context is sent to the destination determined by the Route action. The message goes off to the appropriate back end Web services endpoint.

When a submitted message succeeds in transversing the firewall processing policy, the message appears exactly as it did when it was submitted.


Release 3.6 1 - 15

Rule #2: Response RuleRule #2 in this policy is a Response rule. It handles messages returned to the service from the back end servers. Note that the Match rule is the same as the Request; the server must reflect the same URI in its response as the client.Implied Action 0: ValidateThe firewall automatically validates the response message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent back to the client. This SOAP schema filtering is implied and no action needs to be created for it. However, the presence of this valildation action can cause response messages to be rejected by the firewall before any of the actions visible in the Firewall Policy have run.Action 1: TransformThis action is present to transform the response from the server prior to delivering it to the requesting client. In this case, it inserts a DataPower transaction ID into the resulting message for tracing purposes. Here is the configuration display for this action:

Figure 1 - 12. Response Transform Configuration

Input: INPUT

This is set to INPUT, the special input context containing the original message from the back end server.

Processing Control File: local:///xycosvcresponse.xsl

This is set to local:///xycosvcresponse.xsl. This custom stylesheet has been uploaded to the device.

Output: OUTPUT

This is set to OUTPUT, the special context that is delivered to the wire. As this is the last action of the rule, whatever is in this context is sent back to the client as the response from the service.

1 - 16 Release 3.6

Here is the XSLT stylesheet used for this action:<?xml version="1.0" encoding="utf-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig">

<xsl:output method="xml"/><xsl:template match="/">

<xsl:apply-templates select="/*[local-name()='Envelope']"/></xsl:template><xsl:template match="/*[local-name()='Envelope']">

<S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']"/></S11:Envelope>

</xsl:template><xsl:template match="/*[local-name()='Header']">

<xsl:copy-of select="."/></xsl:template><xsl:template match="/*[local-name()='Envelope']/*[local-name()='Body']">

<S11:Body xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/"><xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='response']"/>

</S11:Body></xsl:template><xsl:template match="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='response']">

<xycohr:response xmlns:xycohr="http://xycohr.com/hrservices"><xsl:for-each select="./*">

<xsl:copy-of select="."/></xsl:for-each><xycohr:trans-id>

<xsl:variable name="rmsg" select="dp:variable('var://service/transaction-id')"/><xsl:value-of select="$rmsg"/>

</xycohr:trans-id></xycohr:response>

</xsl:template></xsl:stylesheet>


Release 3.6 1 - 17

Here is an example of the completed round-trip response to the original request:<?xml version="1.0" encoding="UTF-8"?><S11:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/">

<S11:Body><xycohr:response xmlns:xycohr="http://xycohr.com/hrservices">

<xycohr:First_Name>Samantha</xycohr:First_Name><xycohr:Last_Name>Felinish</xycohr:Last_Name><xycohr:Employee_ID>7636356</xycohr:Employee_ID><xycohr:Department>Sales</xycohr:Department><xycohr:Requested_Service>floatholiday</xycohr:Requested_Service><xycohr:Service_Date>05/01/2005</xycohr:Service_Date><xycohr:result>

<xycohr:ticket>47846787498</xycohr:ticket><xycohr:message>Your request has been received. You will receive email confir-

mation regarding the floating holiday you requested within 24 hours. Have a great day.</xycohr:message>

</xycohr:result><xycohr:trans-id>132357</xycohr:trans-id>

</xycohr:response></S11:Body>

</S11:Envelope>


1 - 18 Release 3.6

Rule #3: Error RuleRule #3 in this policy is an Error rule. It handles any errors encountered during the processing of either the request or the response rule. Note that a Matching Rule is also used for an Error rule. It is possible to match on particular error codes. In this case, however, the Match is the same for all other rules. The URL must match the expression */services. Action 1: TransformThis action is present to transform the error message generated by the DataPower processing system into something else that includes a traceable transaction number. This is often done to provide an error message that will be more acceptable to the end user community, or to provide more or different information.Here is the configuration display for this action:

Figure 1 - 13. Error Transform Configuration

Input: INPUT


Processing Control File: local:///xyerrormsg.xsl

This is set to local:///xyerrormsg.xsl. This custom stylesheet has been uploaded to the device.

Output: OUTPUT


Release 3.6 1 - 19

Here is the XSLT used for this action:<?xml version="1.0" encoding="utf-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig">




<env:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

<env:Body><env:Fault>

<xsl:variable name="err" select="dp:variable('var://service/transaction-id')"/><env:faultcode>

<xsl:value-of select="$err"/></env:faultcode><env:faultstring>Invalid submission. Please submit a valid request or notify youradministrator of this error

and reference the faultcode number.</env:faultstring></env:Fault>

</env:Body></env:Envelope>


1 - 20 Release 3.6

Duration MonitorThis firewall service employs a Duration Monitor, which watches all traffic passing through the system. When the processing of a message, from the moment the request enters the DataPower system to the moment the response leaves the DataPower system, takes more time than allowed by the monitor, the monitor posts a warning notice into the log message stream. Monitors can be configured to do more than simply post messages; monitors can throttle back traffic, allowing some component (usually the back end service) to recover from an overload of requests. In this example, a message is posted to the logs.A Duration Monitor object relies on three other objects. The relationship of these objects is shown here.

Figure 1 - 14. Monitor Object Relationship

Message MatchAt the lowest, or first level, the monitor will only watch messages that match some criteria. This is determined by the Message Match object. Here is the Message Match object configuration used by Xyco:

Figure 1 - 15. Message Match Configuration

This monitor will only watch messages that are sent to the service via an HTTP Post. Since all other fields are blank, no other restrictions are placed on the messages monitored. Note that the Request URL field could have been set to “*/services”, thus restricting the monitor to only those requests that would meet the processing rule matching criteria. In this case, it is left open, thus

Duration Monitor Message Type Message Match

Message Filter Action


Release 3.6 1 - 21

setting up a monitor that will also watch for invalid requests that take more than a set amount of time to reject.Messages can also be matched by HTTP Header Values or by messages that don’t contain certain HTTP Header values. For example, a match could be constructed to match only HTTP Header values that indicate the message is SOAP. Neither of those constraints are used in this example.

Message TypeThe Message Type object is a collection of Message Matching objects. Message Type objects make it possible to combine various Message Matching objects into one type. Each Message Type can use a different combination of Message Matching objects. Here is the configuration for this example:

Figure 1 - 16. Message Type Configuration

Only the one Message Match object is used. All HTTP Post messages are thus included in this Type.


1 - 22 Release 3.6

Message Filter ActionA Message Filter Action object determines what action to take when the Filter is invoked. Here is the Message Filter Action object used by this monitor:

Figure 1 - 17. Message Filter Action Configuration

Type: notify

A log message will be posted (notification will be sent). The next field determines the severity level of the message. This field can also be set to “reject”, in which case the monitor will reject messages once the monitor’s threshold is reached. An unseen “Block Interval” field determines for how long messages will be rejected. This configuration does not take this drastic measure. However, if enough messages are posted by the monitor, this setting may be changed here.

Log Priority: warning

Log messages (notification) posted by this monitor will have the severity level of “warning”. Any log targets set to capture messages at or below the level of warning will capture posted notification messages.


Release 3.6 1 - 23

Duration Monitor ObjectThe top level Duration Monitor object ties together the other three objects to create a single capability. Here is the configuration display for this example:

Figure 1 - 18. Duration Monitor Main Configuration

Message Type: xycohr

All messages of the type “xycohr” will be monitored. As shown above, this in effect means all HTTP Post messages.

Measure: messages

The duration monitored is that of each message - the amount of time it takes between initial receipt of the message from the client to the dispatch of the response. A monitor could be set to measure only requests (the time it takes to process the request), response (the time it takes to process the response), server (the time between dispatch of the message to the back end service to the receipt of the answer) and finally messages.


1 - 24 Release 3.6

Thresholds for this monitor are set on the Filter tab. The Filter tab configuration appears as follows:

Figure 1 - 19. Duration Monitor Filter Configuration

Name: xycohr

This is the name of the threshold.Type: average

This threshold is measuring the average duration of message processing time. This is the only available selection.

Value: 5000

The number of milliseconds at which the threshold is reached.Action: xycohrsvc

This is the Message Filter Action configured above. When the monitor discovers that the average processing time, end to end, of a message hits 5000 milliseconds, it will post a message to the logging system.


Release 3.6 1 - 25

LoggingThis example employs a custom log target, which captures messages generated by the services handling the XyCo HR web services traffic. Here is the configuration display of the custom Log Target object Main page:

Figure 1 - 20. Log Target Main Configuration

Type: File

This log target captures messages into a file on the flash.Format: XML

The log messages are stored in the file in XML format. Because this is true, it is possible to view the logs using the WebGUI interface.

Timestamp: syslog

All timestamps in the messages are formatted in the standard syslog format. This is what is commonly supported by off-device logging monitors.


1 - 26 Release 3.6

Log Size (in kb): 500

The file will grow only to 500 kilobytes. As the entire flash filesystem is limited in size, this file should not be large.

Filename: logtemp:///xycohr.log

The log entries are captured in this file.Archive Mode: Rotate

Once the log file reaches the limit in size, it is rotated. A copy of the current file is placed on the flash and a new file opened.

Rotations: 3When the archive method for a file is Rotate, this determines how many copies of the file are created before the last one is overwritten.

Note that when a device is rebooted (as opposed to the firmware reloaded), all temporary files are erased. For this reason, log files are often moved off the device for storage. Here is an example configuration using FTP to move the log file off the device when it is time to begin a new file.

Figure 1 - 21. Upload Log File Configuration

Object FiltersLog targets capture messages by Object Filters and Event Subscriptions. Object filters determine what messages will be captured according to source object.


Release 3.6 1 - 27

Figure 1 - 22. Log Target Object Filter Configuration

Only messages generated by the objects of the classes shown with the names shown are eligible for capture.

Event SubscriptionsEvent Subscrptions determine at what level of priority messages are captured. Here is the configuration display for this example:

Figure 1 - 23. Log Target Event Subscription Configuration

This indicates that all messages of severity notice or higher will be captured. Above notice are warning, error, critical, alert and emergency.


1 - 28 Release 3.6

Scenario B: An HTML Forms ServiceAfter the DataPower connection between the departmental application servers and the back end web services endpoints was successfully deployed and run for some while, the CIO looked at the architecture and asked if were possible for the DataPower system to connect directly to end user browsers, which would submit a standard HTML Form to request service, thus eliminating the application server layer from the architecture. This would reduce costs and increase simplicity. Here is the resulting architecture:

Figure 1 - 24. Browser-to-Service Architecture

It is entirely possible to implement this architecture using a DataPower system he was told. Show me, he said. Here is the HTML form supported by this service:

Figure 1 - 25. End User HTML Form

DataPower

Web Service 1

Web Service 2

Web Service 3

Many Browsers HTMLSOAP

SOAP

Scenario B: An HTML Forms Service

Release 3.6 1 - 29



These are the field values.Firewall Name: HTTPForms





The default is left in place. Firewall Policy: XycoHRForms

The custom policy built for this service, XycoHRServices, is selected. This policy is covered in detail below.


1 - 30 Release 3.6










Device Port: 2075

The automatically assigned value of 2075 is used. This could be altered to any value not used by another service on the current device. All traffic bound for this service must use port number 2075. The SOAP HTTP URL resembles http://10.10.13.35:2075/services.

SSL Server Crypto Profile: XycoHRWeb

Communication with the front end clients will employ SSL in this case. The cryptographic profile XycoHRWeb will be used, which in turn identifies the cryptographic certificate and private keys used for SSL communications.

Request Type: XML

The selection XML indicates that the clients will not post SOAP-formatted documents to the firewall service. The service will initially expect XML-formatted documents.

Request Attachments: Strip



Release 3.6 1 - 31



All defaults are left in place with the exception of the Message Duration Monitor. Here, the custom configured Xycohr Duration Monitor is assigned to the service. Note that this reuses the same Monitor as used for the Web Services implementation.


1 - 32 Release 3.6


Figure 1 - 28. XycoHRForms Firewall Policy

Note that this policy resembles that of the Web Services policy beginning with the Validate action.


Release 3.6 1 - 33

Rules

Rule #1: Request RuleHere is an examination of the components of Rule #1. Note that this is a Request rule; it will only handle messages sent to the service by the client and will not handle messages sent by the server back to the client.Match Rule: FormsA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 1 - 29. Forms Match Rule Configuration

The client must use the URL */forms or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”


1 - 34 Release 3.6

Action 1: Convert-httpThe first action of this policy converts the data posted by an HTTP Form into an XML document. The presence of this action in this rule and policy alerts the service to accept inbound submissions that are not necessarily XML documents. Here is the configuration display of this action.

Figure 1 - 30. Convert-http Action Configuration

This is a very simple configuration. If a custom conversion of HTTP Input characters were needed or desired, that could be accomplished by configuring an Input Conversion object. Note that the Output context is tmpvar1, which was entered by hand.Action 2: TransformThis tranform action serves to convert the XML created by the Convert-http action into something more usable. Here is an example of the result of the Convert-http action:<?xml version="1.0" encoding="UTF-8" ?> <request> <url>/forms</url> <base-url>/forms</base-url> <args src="url" /> <args src="body"> <arg name="UserName">JBrown</arg> <arg name="Password">lad;fj</arg> <arg name="First_Name">Jack</arg> <arg name="Last_Name">Brown</arg> <arg name="Employee_ID">03498</arg> <arg name="Department">Engineering</arg> <arg name="Requested_Service">floatholiday</arg> <arg name="Service_Date">05/10/05</arg> </args> </request>


Release 3.6 1 - 35

Here is the configuration page display for this action.


Input: tmpvar1

This is set to tmpvar1, the named context used by the preceeding action. Document Processing Instructions: Specified by rule


Processing Control File: local:///ConvertForm.xsl

This is set to local:///ConvertForm.xsl. This XSLT file was uploaded to the device and stored in the local: directory..

Output: tmpvar2

This is set to tempvr2. This value was entered during configuration.


1 - 36 Release 3.6

Here is the stylesheet used for this transform action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/><xsl:template match="/"><xsl:apply-templates select="/request/args"/></xsl:template><xsl:template match="request">

<xsl:copy-of select="."/></xsl:template>

<xsl:template match="args"><xsl:if test="@src = 'body'"><xsl:element name="xycohr:request" namespace="http://xycohr.com/hrservices">

<xsl:for-each select="arg"> <xsl:element name="xycohr:{@name}" namespace="http://xycohr.com/hrservices">

<xsl:value-of select="."/> </xsl:element>

</xsl:for-each></xsl:element></xsl:if>


Here is the result of the transform:<?xml version="1.0" encoding="UTF-8"?><xycohr:request xmlns:xycohr="http://xycohr.com/hrservices">

<xycohr:UserName>JBrown</xycohr:UserName><xycohr:Password>lad;fj</xycohr:Password><xycohr:First_Name>Joe</xycohr:First_Name><xycohr:Last_Name>Brown</xycohr:Last_Name><xycohr:Employee_ID>03498</xycohr:Employee_ID><xycohr:Department>Engineering</xycohr:Department><xycohr:Requested_Service>floatholiday</xycohr:Requested_Service><xycohr:Service_Date>05/10/05</xycohr:Service_Date>

</xycohr:request>


Release 3.6 1 - 37

Action 3: ValidateThis action validates the transformed contents of the message against a custom schema. This insures that the payload also contains the required elements and does not contain invalid elements. Here is the configuration of this action:


Input: tmpvar2

This is set to tmpvar2, the context containing the result of the transform.Schema Validation Method: Schema URL


Schema URL: local:///Xycohr.xsd

This is set to local:///Xycohr.xsd. The custom schema file has been uploaded to the device and placed in the local: directory.

Output: tmpvar3

This is set to tmpvar2. The results of the validation will be placed in this context. If the input is valid, the context will contain the validated message. If an error occurs (the message fails to validate, for example), the context is empty. Any subsequent actions can access the results by using tmpvar3 as the input context.


1 - 38 Release 3.6

Here is the schema file used for this action.<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xycohr="http://xycohr.com/hrservices" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" target-Namespace="http://xycohr.com/hrservices" elementFormDefault="qualified">

<xs:element name="request" type="xycohr:hrrequest"/><xs:complexType name="hrrequest">

<xs:sequence><xs:element name="UserName" type="xs:string" minOccurs="0"/><xs:element name="Password" type="xs:string" minOccurs="0"/><xs:element name="First_Name" type="xs:string"/><xs:element name="Last_Name" type="xs:string"/><xs:element name="Employee_ID" type="xs:string"/><xs:element name="Department" type="xs:string"/><xs:element name="Requested_Service" type="xs:string"/><xs:element name="Service_Date" type="xs:string"/>


</xs:schema>



Input: tmpvar3

This is set to tmpvar3, the named context used by the preceeding action. Processing Control File: local:///XycohrForms.xsl

This is set to local:///XycohrForms.xsl. The custom XSLT file has been uploaded to the device and placed in the local: directory.

Output: (blank)

This is set to be automatically generated by the policy configuration page. Unlike a transform or a validate action, a filter action typically does not return

Release 3.6 1 - 39

a nodeset. It accepts or rejects the input for further processing by the next action in the rule.


<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/><xsl:template match="/"> 

<xsl:apply-templates select="/*[local-name()='request']"/></xsl:template><xsl:template match="/*[local-name()='request']">




</xsl:for-each></xsl:variable><xsl:choose>

<xsl:when test="$errtest != ''"><dp:xreject reason="$errtext"/><xsl:message dp:type="xmlfirewall" dp:priority="error"> <xsl:value-of select="$errtest"/></xsl:message>

</xsl:when><xsl:otherwise>

<dp:accept/></xsl:otherwise>


</xsl:stylesheet>


1 - 40 Release 3.6

Action 5: TransformThis action serves to transform the now validated and filtered payload into a fully compliant SOAP message, and to connect the last context that contained the possibly altered message to any actions that follow. Here is the configuration page display for this action.


Input: tmpvar3



Processing Control File: local:///InsertWSSHeaders.xsl

This is set to local:///InsertWSSHeaders.xsl. This custom XSLT file converts the payload into a SOAP-compliant message with WS-Security headers.

Output: tmpvar4

This is set to tmpvar4. This was entered during configuration.


Release 3.6 1 - 41

Here is the XSLT file used for this action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/><xsl:template match="/">

<S11:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/">


<wsse:UsernameToken><wsse:Username>

<xsl:value-of select="/*[local-name()='request']/*[local-name()='UserName']"/></wsse:Username><wsse:Password>

<xsl:value-of select="/*[local-name()='request']/*[local-name()='Password']"/></wsse:Password>



<xsl:element name="xycohr:request" namespace="http://xycohr.com/hrservices"><xsl:for-each select="/*[local-name()='request']/*">

<xsl:if test="local-name() != 'UserName' and local-name() != 'Password'"><xsl:copy-of select="."/>

</xsl:if></xsl:for-each>

</xsl:element></S11:Body>

</S11:Envelope></xsl:template>

</xsl:stylesheet>

Here is the message after this transform completes successfully:<?xml version="1.0" encoding="UTF-8"?><S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">


<wsse:UsernameToken><wsse:Username>JBrown</wsse:Username><wsse:Password>lad;fj</wsse:Password>



<xycohr:request xmlns:xycohr="http://xycohr.com/hrservices"><xycohr:First_Name>Joe</xycohr:First_Name><xycohr:Last_Name>Brown</xycohr:Last_Name><xycohr:Employee_ID>377389</xycohr:Employee_ID><xycohr:Department>Engineering</xycohr:Department><xycohr:Requested_Service>floatholiday</xycohr:Requested_Service><xycohr:Service_Date>05/10/2005</xycohr:Service_Date>


</S11:Envelope>


1 - 42 Release 3.6



Input: tmpvar4

This is set to tmpvar4, the named context used by the preceeding action. Selection Method: Path Routing Map



Output: (Blank)


XPath Routing Map: xycohrAn XPath Routing Map associates an XPath expression with a destination URL. When the XPath expression evaluates to true, the target destination for the message is set to the corresponding URL. These mappings for this implementation are shown in Figure X below. An XPath Routing Map object can also use Namespace Mappings to associate namespace prefixes in the XPath expression maps to namespace URIs. This shortens the length of the XPath expressions while preserving namespace information. This example does not use namespace mapping.


Release 3.6 1 - 43

Here is the configuration display of this object.


Note that the destinations are mapped according to the value of the Requested_Service node. These are mapped to endpoint operations at the destination server ports. If no match is found by this Route action using the above mappings, the object returns an error to the client. The next object never executes.


1 - 44 Release 3.6

Action 7: TransformThis transform connects the last context containing the message to the next action, or to the OUTPUT context. This is necessary because the Route action does not return a nodeset when doing its work. This is the final action of the rule; if this action executes at all, then the Route has succeeded and all is clear for delivery to the back end service. Here is the configuration display for this object.


Input: tmpvar4

This is set to tmpvar4, the named output context used by the action preceeding the Route action.




When a submitted message succeeds in transversing the firewall processing policy, the message appears exactly as it did after the last transform completed. This message is identical in form to those submitted by the Web Services implementation of this service.


Release 3.6 1 - 45

Rule #2: Response RuleRule #2 in this policy is a Response rule. It handles messages returned to the service from the back end servers. Note that the Match rule is the same as the Request; the server must reflect the same URI in its response as the client.Implied Action 0: ValidateThe firewall automatically validates the response message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent back to the client. This SOAP schema filtering is implied and no action needs to be created for it. However, the presence of this valildation action can cause response messages to be rejected by the firewall before any of the actions visible in the Firewall Policy have run.Action 1: TransformThis action is present to transform the response from the server prior to delivering it to the requesting client. Because the requesting client is a browser, this rule must transform the SOAP response from the back end server into HTML. Note that because the service Response Type is set to SOAP that the service itself validates the server’s response against the SOAP schemas. Here is the configuration display for this action:

Figure 1 - 38. Response Transform Configuration

Input: INPUT


Processing Control File: local:///xycoformresponse.xsl

This is set to local:///xycoformresponse.xsl. This custom stylesheet has been uploaded to the device.

1 - 46 Release 3.6

Output: OUTPUT


Here is the XSLT stylesheet used for this action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig">

<xsl:output method="html" version="1.0"/><xsl:template match="/">

<html><head>

<title>As Requested</title></head><body>

<h2>XyCo HR Instant Benefits</h2><xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='response']"/><p>

<font size="2">Transaction ID:<xsl:value-of select="dp:variable('var://service/transaction-id')"/></font>

</p></body>

</html></xsl:template><xsl:template match="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='response']">

<table cellspacing="3"><xsl:for-each select="./*">

<xsl:choose><xsl:when test="local-name() != 'result'">

<tr><td align="right">

<b><xsl:value-of select="local-name()"/>:

</b></td><td align="left">

<xsl:value-of select="."/></td>

</tr></xsl:when><xsl:otherwise>

<xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='response']/*[local-name()='result']"/>

</xsl:otherwise></xsl:choose>

</xsl:for-each></table>

</xsl:template><xsl:template match="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='response']/*[local-

name()='result']"><xsl:for-each select="./*">

<tr><td align="right" valign="top"><b><xsl:value-of select="local-name()"/>:</b></td>


Release 3.6 1 - 47

<td align="left"><xsl:value-of select="."/>

</td></tr>

</xsl:for-each></xsl:template>

</xsl:stylesheet>

Here is an example of the completed round-trip response to the original request:

Figure 1 - 39. Response in Browser


1 - 48 Release 3.6

Rule #3: Error RuleRule #3 in this policy is an Error rule. It handles any errors encountered during the processing of either the request or the response rule. Note that a Matching Rule is also used for an Error rule. It is possible to match on particular error codes. In this case, however, the Match is the same for all other rules. The URL must match the expression */services. Action 1: TransformThis action is present to transform the error message generated by the DataPower processing system into an HTML file that includes a traceable transaction number. Because the client is a browser, this transform is required.Here is the configuration display for this action:

Figure 1 - 40. Error Transform Configuration

Input: NULL

This is set to NULL, a special input context containing nothing. This error response will not include any device-generated message fragment.

Processing Control File: local:///xycoformerror.xsl

This is set to local:///xycoformerror.xsl. This custom stylesheet has been uploaded to the device.

Output: OUTPUT


Here is the XSLT used for this action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp"


Release 3.6 1 - 49

exclude-result-prefixes="dp dpconfig"><xsl:output method="html" version="1.0"/><xsl:template match="/">

<html><head>

<title>As Requested</title></head><body>

<h2>XyCo HR Instant Benefits</h2><p>Please submit a complete form.</p><p>If the form you submitted is completely filled in, please report this transaction ID to Network Operations.</

p><p>Thank you.</p><p>


</p></body>

</html></xsl:template>

</xsl:stylesheet>

Action 2: SetvarWhenever the DataPower device encounters an error, it returns an HTTP 500 to the calling entity. The HTTP 500 status code prevents the browser from displaying the error message. This Setvar action changes the 500 to a 200.Here is the configuration display for this action:

Figure 1 - 41. Setvar Configuration

Context: OUTPUT

This is the special context sent on the wire.Variable Name: var://service/error-protocol-response

This is a special service variable that can be changed. This controls the HTTP status code sent on the wire.

Variable Assignment: 200

The code is reset to 200. The browser will now display the error message.


1 - 50 Release 3.6

SSL Server Crypto ProfileIn this scenario, the communication channels between the DataPower service and the requesting client are not guaranteed to be encrypted or secure in any way. For this reason, this implementation uses SSL to encrypt communications between the browser client and the DataPower system. The firewall configuration page shows the setting to use SSL communications.

Figure 1 - 42. SSL Server Crypto Profile setting

Here is the configuration of the Crypto Profile:

Figure 1 - 43. Crypto Profile Configuration

Identification Credentials: XycoHRWeb

These credentials identify the private cryptographic key and public cryptographic certificate used by this service to identify itself to clients. A browser client connecting to this service will be given a copy of the certificate identified by these credentials for use in SSL communications.

Validation Credentials: None

This setting indicates that the service will not request a certificate of authority to identify the requesting clients.

All other inputs are set to the default, requiring no configuration action. With SSL enabled, the browsers use HTTPS rather than HTTP to communicate with the DataPower system.


Release 3.6 1 - 51

Crypto Identification CredentialsThe SSL Crypto Profile relies upon the Crypto Identification Credential XycoHRWeb. Here is the configuration of the Identification Credential object:

Figure 1 - 44. Crypto Identification Credentials Configuration

The Key and Certificate objects identify the private key and public certificate used for secure communications over an SSL channel. Both of those objects were generated automatically on the DataPower system using the Cryptographic Key tool. Those objects can also use private keys and certificates uploaded to the device.

Crypto KeyHere is the configuration of the Key object:

Figure 1 - 45. Crypto Key Configuration


1 - 52 Release 3.6

The object points at a key file stored in the encrypted cert: directory on the local flash filesystem. Files placed in the cert: directory can be read by the system, but cannot be copied or moved in any way.

Crypto CertificateHere is the configuration of the Certificate object:

Figure 1 - 46. Crypto Certificate Configuration

This object points to a certificate file stored on the local flash filesystem, in the encrypted cert: directory. Files placed in the cert: directory can be read by the system, but cannot be copied or moved in any way.

Scenario C: Multi-Protocol, Single Port Service

Release 3.6 1 - 53

Scenario C: Multi-Protocol, Single Port ServiceThe CIO was duly impressed with the flexibility and capability of the DataPower system. But the CTO now saw an opportunity to combine the two services into one well-known address and port and asked if the DataPower system could take in either SOAP or HTML Forms traffic on the same port and do the right thing. This would simplify the change control process. Yes, of course, he was told, DataPower can do that.In this scenario, the DataPower firewall can accept requests directly from an end user browser, which posts HTML forms, or from an application server, which posts SOAP documents. The HTML form posting is converted into a SOAP document. The request is schema validated, filtered for complete information, and then dynamically routed to the appropriate back end server for processing. The response, whether success or error, is returned to the calling entity in the appropriate form. The browser receives an HTML page and the application server receives a SOAP response. Here is an illustration of the architecture involved.

Figure 1 - 47. Multi-portocol architecture

This configuration is explained below.

DataPower

Server 1

Server 2

Server 3

Many Browsers

Many App Servers

HTML

SOAP

SOAP

SOAP


1 - 54 Release 3.6


Figure 1 - 48. SOAP/HTTP Firewall Configuration

These are the field values.Firewall Name: XycoMultiSvc





The default is left in place. Firewall Policy: XycoHRWeb

The custom policy built for this service, XycoHRWeb, is selected. This policy is covered in detail below.


Release 3.6 1 - 55










Device Port: 2085

The value of 2085 is used. This could be altered to any value not used by another service on the current device. All traffic bound for this service must use port number 2085. The SOAP HTTP URL resembles http://10.10.13.35:2085/services or http://10.10.13.35:2085/forms.

SSL Server Crypto Profile: XycoHRWeb

Communication with the front end clients will employ SSL in this case, using the same certificates and keys as the HTML Forms service used.

Request Type: XML

The selection XML indicates that the service is expecting inbound messages in XML format. The SOAP-formatted messages sent by application servers are valid XML. However, the service will not automatically validate the inbound message against the SOAP schemas. In this scenario, that validation is performed in the Policy rule, rather than automatically by the service. The HTML forms sent by the browser clients will be accepted by this service, even though they are not well-formed XML, because of the convert-http action included in the Policy rules used.

Request Attachments: Strip



1 - 56 Release 3.6



All defaults are left in place with the exception of the Message Duration Monitor. Here, the custom configured Xycohr Duration Monitor is assigned to the service.


Release 3.6 1 - 57


Figure 1 - 50. XycoHRWeb Firewall Policy

This policy employs 6 rules to handle the two possible kinds of submissions. Three rules handle SOAP - request, response and error - all identified by the services match rule. Three rules handle HTML forms - request, response and error - all identified by the HTTP Forms match rule.Here is an overview of these rules.Rule #1 services Request Rule

This rule matches to all submissions posted to the URI */services. The Validate action uses the same schema definitions as the firewall uses when it does automatic SOAP schema validation. The subsequent Filter action verifies that values are provided for all fields and, through the use of DataPower extension functions, validates the custom payload portion (within the SOAP Body tags) of the message. If both of these steps succeed, the message is routed dynamically according to the service requested.

Rule #2 HTML Forms Request RuleThis rule matches submissions with the URI */forms. It immediately converts the HTML forms data posted to the service into XML. The next Transform action converts this XML into a well-formed SOAP document, just as would be received from an application server. The final action Calls the first rule to complete validation, filtering and routing.


1 - 58 Release 3.6

Rule #3 services Response RuleThis rule handles responses from the server bound for an application server client that expects SOAP in response. It is an identity transform that adds a transaction id to the response.

Rule #4 HTML Forms Response RuleThis rule handles responses from the server bound for a browser, that cannot handle SOAP. It converts the SOAP response into HTML for the browser’s consumption, adding a transaction id in the process.

Rule #5 services Error RuleThis rule handles all errors bound for an application server expecting SOAP.

Rule #6 HTML Forms Error RuleThis rule handles all errors bound for a browser, expecting HTML.

Rules

Rule #1: Request RuleHere is an examination of the components of Rule #1. Note that this is a Request rule; it will only handle messages sent to the service by the client and will not handle messages sent by the server back to the client. This rule is designed to handle Web Services submissions - that is, XML-formatted documents, and not HTTP Forms POST submissions.Match Rule: ServicesA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 1 - 51. Services Match Rule Configuration

The client must use the URL */services or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”


Release 3.6 1 - 59

Action 1: ValidateWhen the firewall Request Type is set to SOAP, the firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. However, this firewall uses the Request Type XML, to support submissions from browsers (handled in Rule #2 below). To ensure that inbound messages sent to the Matching URL are valid SOAP, it is necessary to validate the SOAP conformance with an action.The first validates the contents of the SOAP Body element against the SOAP schemas used internally by the firewall. This replaces the automatic behavior. Here is the configuration of this action:





Schema URL: store:///schemas/soap-envelope.xsd

This is set to store:///schemas/soap-envelope.xsd. This is the SOAP schema used by the firewall to validate SOAP messages for conformance.

Output: tmpvar1

This is set to tmpvar1. The results of the validation will be placed in this context. If the input is valid, the context will contain the validated message. If an error occurs (the message fails to validate, for example), the context is empty. Any subsequent actions can access the results by using tempvar1 as the input context.


1 - 60 Release 3.6

Action 2: FilterThis action filters the validated message for the presence of required values within the message. It also submits that portion of the message within the SOAP:Body tags for validation against the custom schema used for the particular web service. This is done by using Extension Functions within the stylesheet itself. It either accepts or rejects the message. Here is the configuration display for this action:


Input: tmpvar1


Processing Control File: local:///Xycohr3.xsl

This is set to local:///Xycohr3.xsl. The custom XSLT file has been uploaded to the device and placed in the local: directory.

Output: (Blank)




<xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='request']"/></xsl:template><xsl:template match="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='request']">



Release 3.6 1 - 61


</xsl:for-each></xsl:variable><xsl:choose>

<xsl:when test="$errtest != ''"><dp:xreject reason="$errtext"/><xsl:message dp:type="xmlfirewall" dp:priority="error"> <xsl:value-of select="$errtest"/></xsl:message>

</xsl:when><xsl:otherwise>

<dp:accept/><xsl:variable name="payload" select="/*[local-name()='Envelope']/*[local-name()='Body']/*"/><dp:set-variable name="'var://context/tempvar3/payload'" value="$payload"/><xsl:variable name="validation" select="dp:schema-validate('local:///Xycohr.xsd', $payload)"/><dp:set-variable name="'var://context/tempvar3/postval'" value="$validation"/><xsl:variable name="results">

<xsl:value-of select="$validation"/></xsl:variable><xsl:if test="$results = ''">

<dp:reject>Failed validation</dp:reject><xsl:message dp:type="xmlfirewall" dp:priority="error">Failed Payload Validation</xsl:message>

</xsl:if></xsl:otherwise>


</xsl:stylesheet>


1 - 62 Release 3.6

Input: tmpvar1

This is set to tmpvar1, the named context used by the preceeding action. Selection Method: XPath Routing Map



Output: (Blank)


XPath Routing Map: xycohrAn XPath Routing Map associates an XPath expression with a destination URL. When the XPath expression evaluates to true, the target destination for the message is set to the corresponding URL. These mappings for this implementation are shown in Figure X below. An XPath Routing Map object can also use Namespace Mappings to associate namespace prefixes in the XPath expression maps to namespace URIs. This shortens the length of the XPath expressions while preserving namespace information. This example does not use namespace mapping.Here is the configuration display of this object.



Release 3.6 1 - 63

Note that the destinations are mapped according to the value of the Requested_Service node. These are mapped to endpoint operations at the destination server ports. If no match is found by this Route action using the above mappings, the object returns an error to the client. The next object never executes.Action 5: TransformThis transform connects the last context containing the message to the next action, or to the OUTPUT context. This is necessary because the Route action does not return a nodeset when doing its work. This is the final action of the rule; if this action executes at all, then the Route has succeeded and all is clear for delivery to the back end service. Here is the configuration display for this object.


Input: tmpvar1

This is set to tmpvar1, the named output context used by the action preceeding the Route action.




When a submitted message succeeds in transversing the firewall processing policy, the message appears exactly as it did when it was submitted.


1 - 64 Release 3.6

Rule #2: Request RuleHere is an examination of the components of Rule #2. Note that this is a Request rule; it will only handle messages sent to the service by the client and will not handle messages sent by the server back to the client.Match Rule: FormsA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 1 - 57. Forms Match Rule Configuration

The client must use the URL */forms or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”Action 1: Convert-httpThe first action of this policy converts the data posted by an HTTP Form into an XML document. The presence of this action in this rule and policy alerts the service to accept inbound submissions that are not necessarily XML documents. Here is the configuration display of this action.

Figure 1 - 58. Convert-http Action Configuration


Release 3.6 1 - 65

This is a very simple configuration. If a custom conversion of HTTP Input characters were needed or desired, that could be accomplished by configuring an Input Conversion object. Note that the Output context is tmpvar1, which was entered by hand.Action 1: TransformThis tranform action serves to convert the XML created by the Convert-http action into a fully compliant SOAP document suitable for submission to Rule #1. Here is the configuration page display for this action.


Input: tmpvar1



Processing Control File: local:///InsertWSSHeader2.xsl

This is set to local:///InsertWSSHeader2.xsl. This XSLT file was uploaded to the device and stored in the local: directory..

Output: tmpvar2

This is set to tempvr2. This value was entered during configuration.


1 - 66 Release 3.6

Here is the stylesheet used for this transform action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" extension-element-prefixes="dp" xmlns:dp="http://www.datapower.com/extensions" exclude-result-prefixes="dp">


<S11:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/">


<wsse:UsernameToken><wsse:Username>

<xsl:if test="/request/args/arg/@name='UserName'"><xsl:choose>

<xsl:when test="/request/args/arg[@name='UserName'] = ''"><dp:reject>No UserName</dp:reject>


<xsl:value-of select="/request/args/arg[@name='UserName']"/></xsl:otherwise>

</xsl:choose></xsl:if>

</wsse:Username><wsse:Password>

<xsl:if test="/request/args/arg/@name='Password'"><xsl:choose>

<xsl:when test="/request/args/arg[@name='Password'] = ''"><dp:reject>No Password</dp:reject>


<xsl:value-of select="/request/args/arg[@name='Password']"/></xsl:otherwise>

</xsl:choose></xsl:if>

</wsse:Password></wsse:UsernameToken>

</wsse:Security></S11:Header><S11:Body>

<xsl:apply-templates select="/request/args"/></S11:Body>

</S11:Envelope></xsl:template><xsl:template match="request">

<xsl:copy-of select="."/></xsl:template><xsl:template match="args">

<xsl:if test="@src = 'body'"><xsl:element name="xycohr:request" namespace="http://xycohr.com/hrservices">

<xsl:for-each select="arg"><xsl:if test="@name != 'UserName' and @name != 'Password'">

<xsl:element name="xycohr:{@name}" namespace="http://xycohr.com/hrservices"><xsl:value-of select="."/>

</xsl:element></xsl:if>

</xsl:for-each></xsl:element>

</xsl:if>


Release 3.6 1 - 67


Action 3: CallThis action calls Rule #1 to complete the full processing of the submission from the browser. Since the rest of the validation, filtering and routing is identical to that of a SOAP request, and since the transform in the previous step created a fully compliant SOAP request, it is now possible to eliminate the double work by simply calling Rule #1. The Call action then sends the results of executing the actions in Rule #1 to the back end service, preserving the URI.Here is the configuration display for this action:

Figure 1 - 60. Call Action Configuration

Input: tmpvar2

This is set to tmpvar2, the named context used by the preceeding action. Processing Rule: XycoHRWeb_Rule_0

This is set to XycoHRWeb_Rule_0. This is the name stored in the system for Rule #1.

Output: OUTPUT

This is set to OUTPUT. The result of the Call will be sent directly to the back end server.


1 - 68 Release 3.6

Both the Input and the Output to this rule should resemble the following:<?xml version="1.0" encoding="UTF-8"?><S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">


<wsse:UsernameToken><wsse:Username>JBrown</wsse:Username><wsse:Password>lad;fj</wsse:Password>



<xycohr:request xmlns:xycohr="http://xycohr.com/hrservices"><xycohr:First_Name>Joe</xycohr:First_Name><xycohr:Last_Name>Brown</xycohr:Last_Name><xycohr:Employee_ID>377389</xycohr:Employee_ID><xycohr:Department>Engineering</xycohr:Department><xycohr:Requested_Service>floatholiday</xycohr:Requested_Service><xycohr:Service_Date>05/10/2005</xycohr:Service_Date>


</S11:Envelope>

Rules 3 to 6The remaining rules are identical to the Response and Error rules used for the Scenario A Web Services and Scenario B HTML Forms implementations. For full explanations, refer to those sections of this chapter.


Release 3.6 1 - 69


1 - 70 Release 3.6

2 - 1

Chapter 2Bank Checking Web Service

This example configuration implements a simple bank checking service. Requests arrive from any number of other hosts that offer the consumer the checking service. The SOAP request for service is formatted according to a published schema (available from the WSDL for the service; refer to the end of this chapter) and includes a signed Security Assertion Markup Language (SAML) Attribute Assertion. The presence of this Assertion indicates that the remote host has contacted a SAML Authority prior to sending the request to the banking service central servers. This assertion is used for authentication and authorization.Here is an illustration of the architecture involved.

All traffic between the DataPower device and the application servers travels over SSL. As defined in the WSDL for the service, requests may be one of the following:

• Plain XML text• Field level Encrypted XML text• Field Level Encrypted and Signed XML text

The DataPower system performs the following tasks on requests:• Verifies Signatures (if signed)• Decrypts Encrypted Fields (if encrypted)• Validates Request Against Schema

DataPower

Endpoint 1

Endpoint 2

Endpoint 3

Many App Servers

SOAP SOAPSAML

Authority SSL

Bank Checking Web Service

2 - 2 Release 3.6

• Filters Request Data• Authenticates and Authorizes Request (using SAML)• Forwards to Endpoint

The DataPower box performs the following tasks on the response from the server:• Vaildates Response Format• Encrypts Response Message (if request was encrypted)• Signs Response Message (if request was signed)

The traffic is monitored for service threats. All errors are logged in a special log target built for this service.

XML Firewall

Release 3.6 2 - 3

XML FirewallThe XML Firewall Service configuration page appears as shown here.


These are the field values.Firewall Name: SomeBankCheckService


Firewall Type: Static backend

The firewall forwards all requests to a single back end server IP address and Port.


The default is left in place.


2 - 4 Release 3.6

Firewall Policy: SomeBankCheckService

The custom policy built for this service, SomeBankCheckService, is selected. This policy is covered in detail below.










Device Port: 2061

The automatically assigned value of 2061 is used. This could be altered to any value not used by another service on the current device. All traffic bound for this service must use port number 2061. The SOAP HTTP URL resembles http://10.10.13.35:2061/SomeBank/services/checking.

SSL Server Crypto Profile: SomeBank

Communication with the front end clients will employ SSL. The SomeBank Crypto Profile defines the cryptographic keys and certificates used for this purpose.

Request Type: SOAP


Request Attachments : Strip


XML Firewall

Release 3.6 2 - 5



The XML Threat Protection wizard has added three Count monitors and one Duration monitor to this service. The purpose of these monitors is more easily seen on the Threat Protection page.


2 - 6 Release 3.6

Here is the excerpted Threat Protection Page.

Figure 2 - 3. Threat Protection page (top)

Figure 2 - 4. Threat Protection page (bottom)

Firewall Policy

Release 3.6 2 - 7


Figure 2 - 5. SomeBankCheckServices Firewall Policy

Here is a brief explanation of the column headings under Configured Rules:Priority The order in which the rules are executed by the policy. When two

rules have a matching rule that could potentially match the inbound document, the rule with the highest priority executes first.





2 - 8 Release 3.6

Rules

OverviewHere is an overview of the rules used in this policy.Rule 1 Request Rule Matching */SomeBank/services/checking

This rule runs when the client sends the matching URL. The rule performs the following actions:

1 Validate against the published schema for the service2 Filter requests for valid values3 Filter requests for SQL Injection threats4 Authenticate and Authorize request5 Send to back end service

Rule 2 Request Rule Matching */SomeBank/services/encryptedThis rule runs when the client sends the matching URL. The rule performs the following actions:

1 Decrypt encrypted fields2 Pass to Rule 1 for standard processing

Rule 3 Request Rule Matching */SomeBank/services/signedThis rule runs when the client sends the matching URL. The rule performs the following actions:

1 Verify signature2 Pass to Rule 2 for decryption

Rule 4 Response Rule Matching */SomeBank/services/signedThis rule runs when the client sends the matching URL. This rule operates on the response from the server. The rule performs the following actions:

1 Validate server response against schema2 Encrypt entire message body3 Sign response message

Rule 5 Response Rule Matching */SomeBank/services/encryptedThis rule runs when the client sends the matching URL. This rule operates on the response from the server. The rule performs the following actions:

1 Validate server response against schema2 Encrypt entire message body

Rule 6 Response Rule Matching */SomeBank/services/checkingThis rule runs when the client sends the matching URL. This rule operates on the response from the server. The rule performs the following actions:

1 Validate server response against schema

Rules

Release 3.6 2 - 9

Rule #1: Request RuleHere is an examination of the components of Rule #1. Note that this is a Request rule; it will only handle messages sent to the service by the client and will not handle messages sent by the server back to the client.This is the core processing rule of the policy. All messages must pass through this set of validations, filter, and authentication/authorization steps.

Match Rule: CheckingA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 2 - 6. Checking Match Rule Configuration

The client must use the URL */SomeBank/services/checking or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”

Implied Action 0: ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it. It is possible, however, for the firewall to reject a message before any of the actions in the configured policy run due to this validation.


2 - 10 Release 3.6






Schema URL: local:///SomeBankCheckService.xsd

This is set to local:///SomeBankCheckService.xsd. The custom schema file has been uploaded to the device and placed in the local: directory.

Output: tempvar1

This is set to tempvar1. If the input is valid, the context will contain the validated message. If an error occurs (the message fails to validate, for example), the context is empty. Any subsequent actions can access the results by using tempvar1 as the input context.

Rules

Release 3.6 2 - 11

Here is the schema file used for this action.<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:bank="http://somebank.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://somebank.com" elementFormDefault="qualified">

<xs:element name="CheckRequestElement" type="bank:CheckRequest"/><xs:complexType name="CheckRequest">

<xs:sequence><xs:element name="PayorAccountName" type="xs:string"/><xs:element name="PayorAccountID" type="xs:string"/><xs:element name="CheckType" type="xs:string"/><xs:element name="Payee" type="xs:string"/><xs:element name="PayeeAddr" type="xs:string" minOccurs="0"/><xs:element name="PayeeRouteNo" type="xs:string" minOccurs="0"/><xs:element name="Amount" type="xs:float"/><xs:any namespace="##any" processContents="skip" minOccurs="0"/>

</xs:sequence><xs:anyAttribute namespace="##any" processContents="skip"/>

</xs:complexType><xs:element name="CheckResponseElement" type="bank:CheckResponse"/><xs:complexType name="CheckResponse">

<xs:sequence><xs:element name="TransactionNum" type="xs:int"/><xs:element name="CheckNum" type="xs:int"/><xs:element name="CheckType" type="xs:string"/><xs:element name="PayorAccountID" type="xs:string"/><xs:element name="Payee" type="xs:string"/><xs:element name="Amount" type="xs:float"/><xs:any namespace="##any" processContents="skip" minOccurs="0"/>


</xs:complexType><xs:element name="CheckRequestErrorElement" type="bank:CheckRequestError"/><xs:complexType name="CheckRequestError">

<xs:sequence><xs:element name="TransactionNum" type="xs:int"/><xs:element name="ErrorNum" type="xs:int"/><xs:element name="CheckType" type="xs:string"/><xs:element name="PayorAccountID" type="xs:string"/><xs:element name="Payee" type="xs:string"/><xs:element name="ErrorMessage" type="xs:string"/>


</xs:schema>


2 - 12 Release 3.6



Input: tempvar1

This is set to tempvar1, the named context used by the preceeding action. Note that this could have been set to INPUT since this action would not execute if the validation before it failed. However, validation can sometimes change the message format, thus this action uses the result of the validation.

Processing Control File: local:///SomeBankCheckService.xsl

This is set to local:///SomeBankCheckService.xsl. The custom XSLT file has been uploaded to the device and placed in the local: directory.

Output: (blank)


Here is the XSLT file used for this Filter action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet extension-element-prefixes="dp" version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP12="http://www.w3.org/2003/05/soap-envelope" xmlns:dp="http://www.datapower.com/extensions" xmlns:bank="http://somebank.com">

<xsl:template name="valid-operation"><xsl:param name="op"/><xsl:choose>

<xsl:when test="$op='CheckRequestElement'"><xsl:choose>

<xsl:when test="string-length(/SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:PayorAccoun-

Rules

Release 3.6 2 - 13

tID) != 0 and length(/SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:Payee) != 0 and

/SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:Amount > 10"><xsl:copy-of select="/"/>


<xsl:variable name="errtext" select="'Invalid Input'"/><dp:xreject reason="$errtext"/><xsl:message>

<xsl:value-of select="$errtext"/></xsl:message>

</xsl:otherwise></xsl:choose></xsl:when><xsl:when test="$op='CheckResponseElement'">

<dp:accept/></xsl:when><xsl:otherwise>

<xsl:variable name="errtext" select="concat('Rejected illegal operation ', $op)"/><dp:xreject reason="$errtext"/><xsl:message>



</xsl:template><xsl:template match="/">

<xsl:choose><xsl:when test="dp:responding()">


<xsl:choose><xsl:when test="count(/SOAP:Envelope) > 0">

<xsl:call-template name="valid-operation"><xsl:with-param name="op" select="local-name(/SOAP:Envelope/SOAP:Body/*)"/>

</xsl:call-template></xsl:when><xsl:when test="count(/SOAP12:Envelope) > 0">

<xsl:call-template name="valid-operation"><xsl:with-param name="op" select="local-name(/SOAP12:Envelope/SOAP12:Body/*)"/>

</xsl:call-template></xsl:when><xsl:otherwise>

<xsl:call-template name="valid-operation"><xsl:with-param name="op" select="local-name(/*)"/>

</xsl:call-template></xsl:otherwise>

</xsl:choose></xsl:otherwise>


</xsl:stylesheet>


2 - 14 Release 3.6

Action 3: FilterThis action filters the validated message for SQL Injection attacks. It either accepts or rejects the message. Here is the configuration display for this action:


Input: tempvar1


Processing Control File: store:///Sql_Injection_Filter.xsl

This is set to store:///Sql_Injection_Filter.xsl. This is the standard SQL Injection Filter stylesheet supplied with the device.

Output: (blank)


The stylesheet and SQL Injection Threat pattern file used for this filter can be found in the store: directory of the device. Note that the pattern file can be modified to include new or custom injection threats.

Rules

Release 3.6 2 - 15

Action 4: AAAThis action authorizes and authenticates the entity (person) requesting checking services. An AAA Action simply identifies an AAA Policy that is applied to the incoming message. Here is the configuration of the action:

Figure 2 - 10. AAA Action Configuration

Input: tempvar1


AAA Policy: SAML_Attr

This is set to the AAA Policy named SAML_Attr. The Policy contains the business logic of the access and authorization policy. it is covered in detail below.

Output: tempvar4

This is set to be automatically generated by the policy configuration page. If the AAA action succeeds (the request is authenticated and authorized), this context will contain the message.


2 - 16 Release 3.6

AAA Policy: SAML-AttrExtract IdentityThis policy obtains the identity of the requestor from a SAML Attribute Assertion contained in the SOAP header of the request message. Here is an excerpted example request message SOAP header. The fields used by the AAA Policy are highlighted in bold.<soapenv:Header>

<saml:Assertion AssertionID="Ide8d5cf8c-84c5-4fb3-81cf-8e2999dc6dc0" IssueInstant="2005-05-05T19:47:19Z" MajorVersion="1" MinorVersion="1" Issuer="BankConsortium">

<saml:AttributeStatement><saml:Subject>

<saml:NameIdentifier>CN=Bob</saml:NameIdentifier></saml:Subject><saml:Attribute AttributeName="CheckingServices" AttributeNamespace="http://www.some-

bank.com"><saml:AttributeValue>Query</saml:AttributeValue><saml:AttributeValue>Request</saml:AttributeValue>

</saml:Attribute></saml:AttributeStatement><Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/

07/secext" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">...<SignatureValue>ePZifp/YHA3yrEZvUMLc+0U0cVQXgqng6GRrUyxaYLqhkMEHR2v35O82vy9wEUI/

xE7M1WLaKHzU3qj1J45HK02EEqNodDMtLXM5YJy51lIcB+ACacT+OcyGUvfd66oEjzUPpqrKevZoj2rIO9V9x34HXNGdNgRasaZECaiDlM=</SignatureValue>

...</saml:Assertion>

</soapenv:Header>

Here is the policy screen showing the Extract Identity method selected:

Figure 2 - 11. Extract Identity from SAML Assertion

Rules

Release 3.6 2 - 17

This step uses the value of the NameIdentifier element (in this case, CN=Bob)shown in the example message above.AuthenticateThe policy considers the identity authenticated if the SAML signature is valid. Here is the AAA Policy configuration screen where this is selected:

Figure 2 - 12. Authentication Method

Extract ResourceThe policy uses the top level element of the SOAP Body element to extract the requested resource. Here is an example message SOAP Body:

<soapenv:Body><bank:CheckRequestElement xmlns:bank="http://somebank.com" xmlns:xsi="http://

www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<bank:PayorAccountName>Cartoon Studios</bank:PayorAccountName><bank:PayorAccountID>8458jf8757275234</bank:PayorAccountID><bank:CheckType>P</bank:CheckType><bank:Payee>Elmer Fudd</bank:Payee><bank:PayeeAddr>124 East Sunset Drive; Sunset, AL 64846</bank:PayeeAddr><bank:PayeeRouteNo>03849032874908</bank:PayeeRouteNo><bank:Amount>999.00</bank:Amount>

</bank:CheckRequestElement></soapenv:Body>


2 - 18 Release 3.6

Here is the configuration screen establishing this policy.

Figure 2 - 13. Requested Resource configuration

AuthorizeThe policy authorizes the request using the SAML Attribute Assertion contained in an authenticated SAML Assertion. The Attribute Assertion consists of an Attribute Name and one or more values. This assertion and the corresponding values can be seen in this excerpt (repeated from above):

<saml:Attribute AttributeName="CheckingServices" AttributeNamespace="http://www.somebank.com"><saml:AttributeValue>Query</saml:AttributeValue><saml:AttributeValue>Request</saml:AttributeValue>

/saml:Attribute>

Here is the configuration screen setting this policy:

Figure 2 - 14. Authorization Method

Rules

Release 3.6 2 - 19

This policy requires that at least SAML Attribute Assertion name and value match for the request to be considered valid. The values in the message must match a set of values configured in the policy for authorization to succeed.Here are the SAML Attributes configured for matching this policy:

Figure 2 - 15. SAML Attributes

In this case, the SAML Attribute assertion matches at least one name and value. Note that Namespace URI must also match.Finally, this policy employs a Rejected Counter, which is also part of the Threat Protection established for this service. Here is the inclusion of that counter in this policy.

Figure 2 - 16. Rejected Counter configuration

Note under the Logging section that allowed accesses and rejected accesses are both logged.


2 - 20 Release 3.6

Action 5: TransformThis tranform action serves to connect the last context that contained the possibly altered message to any actions that follow. The policy configuration page automatically creates this action following a filter. Here is the configuration page display for this action.


Input: tempvar4

This is set to tempvar4, the named context used by the preceeding action. Document Processing Instructions: Specified by rule




Output OUTPUT

This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is forwarded to the back end service. If none of the filters and authorization steps have rejected the message after it is validated, it is forwarded to the back end server.

Rules

Release 3.6 2 - 21

Rule #2: Request RuleHere is an examination of the components of Rule #2. Note that this is a Request rule; it will only handle messages sent to the service by the client and will not handle messages sent by the server back to the client.This rule handles encrypted requests.

Match Rule: EncryptedA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 2 - 18. Encrypted Match Rule

The rule will not run unless the client submits the URL */SomeBank/services/encrypted.

Action 1: DecryptA Decrypt action decrypts encrypted messages. In this case, only certain fields of the message have been encrypted. Here is an example message, with two encrypted fields:<soapenv:Body>

<bank:CheckRequestElement xmlns:bank="http://somebank.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<bank:PayorAccountName>Cartoon Studios</bank:PayorAccountName><EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:ds="http://www.w3.org/2000/

09/xmldsig#" xmlns="http://www.w3.org/2001/04/xmlenc#"><EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/><ds:KeyInfo>

<EncryptedKey Recipient="name:SomeBank"><EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/><ds:KeyInfo>

<ds:KeyName>SomeBank</ds:KeyName></ds:KeyInfo><CipherData>

<CipherValue>OXgQ...KUaE=</CipherValue></CipherData>

</EncryptedKey></ds:KeyInfo><CipherData>

<CipherValue>A1v7C...jvJyw=</CipherValue></CipherData>


2 - 22 Release 3.6

</EncryptedData><bank:CheckType>P</bank:CheckType><bank:Payee>Elmer Fudd</bank:Payee><bank:PayeeAddr>124 East Sunset Drive; Sunset, AL 64846</bank:PayeeAddr><EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:ds="http://www.w3.org/2000/

09/xmldsig#" xmlns="http://www.w3.org/2001/04/xmlenc#"><EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/><ds:KeyInfo>

<EncryptedKey Recipient="name:SomeBank"><EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/><ds:KeyInfo>

<ds:KeyName>SomeBank</ds:KeyName></ds:KeyInfo><CipherData>

<CipherValue>b2NMi...f1jIo=</CipherValue></CipherData>

</EncryptedKey></ds:KeyInfo><CipherData>

<CipherValue>nH1oQ...ehsYMv</CipherValue></CipherData>

</EncryptedData><bank:Amount>999.00</bank:Amount>


Here is the configuration of the Decrypt action:

Figure 2 - 19. Decrypt Action Configuration

Input: INPUTThis is set to INPUT, the special context that contains the original response message.

Message Type: Selected Elements (Field Level)

The action will decrypt only certain elements within the message. This requires the configuration of a Document Crypto Map object.

Document Crypto Map: SBSCE

This is set to the SBSCE Document Crypto Map object. That object is explained in detail below.

Rules

Release 3.6 2 - 23

Output: tempvar1

This context name was assigned automatically by the system. The results of the decrption will be placed in this context.

Here is the configuration of the SBSCE Document Crypto Map object:

Figure 2 - 20. Document Crypto Map Object Configuration

The XPath Expression identifies the elements that are encrypted. Note that although this is only one expression, it can apply to more than one element in the node containing the EncryptedData element. If the identified encrypted elements do not appear in the submission, no decryption is performed. A client could submit an unencrypted message to this URL and it would be processed successfully.


2 - 24 Release 3.6

Action 2: CallThis action calls Rule #1 to complete the full processing of the submitted message. This eliminates the need to duplicate that complicated set of actions for the supported encrypted service endpoint.The Call action then sends the results of executing the actions in Rule #1 to the back end service, preserving the URI.Here is the configuration display for this action:


Input: tempvar1

This is set to tempvar1, the named context used by the preceeding action. Processing Rule: SomeBankCheckService_Rule_0

This is the name stored in the system for Rule #1.Output: OUTPUT


Rules

Release 3.6 2 - 25

Rule #3: Request RuleHere is an examination of the components of Rule #3. Note that this is a Request rule; it will only handle messages sent to the service by the client and will not handle messages sent by the server back to the client.This rule handles signed encrypted requests.

Match Rule: SignedA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 2 - 22. Signed Match Rule

The rule will not run unless the client submits the URL */SomeBank/services/signed.


2 - 26 Release 3.6

Action 1: VerifyA Verify action verifies the signature contained in the message. If the signature cannot be verified, the message is rejected. If the signature is valid, the rule passes processing to Rule #2, which then decrypts any encrypted fields. The WSDL specifies that signed messages may also be encrypted.Here is the configuration of the Verify action:

Figure 2 - 23. Verify Action Configuration

Input: INPUT

This is set to the special INPUT context, which contains the original message submission.

Filter Method: Standard Filter

The Standard Filter just checks the signature for validity.Signer Certificate: (Blank)

This setting causes the system to use the certificate contained in the signature to verify the signature in the message. If this field had a value, it would need to point to the Crypto Certificate object that would be used for verification.


This setting indicates that the system will not perform certificate validation. If this field had a value, it would point to a Crypto Validation Credential object, that in turn would have to include the certificate included in the message to validate that certificate. Additional trust chain checking can also be performed by a Validation Credential object.

Output: (Blank)

This setting indicates that the system will automatically use the correct context in the following actions. A Verify action is a type of filter that only accepts or rejects the message and does not output the contents of the message.

Rules

Release 3.6 2 - 27

Action 2: TransformThis tranform action serves to connect the last context that contained the message to any actions that follow. The policy configuration page automatically creates this action following a filter. Here is the configuration page display for this action.


Input: INPUT

This is set to INPUT, the special context containing the submitted message.Document Processing Instructions: Specified by rule




Output tempvar2

This is set to tempvar2. The policy configuration page automatically assigned this context name. Any subsequent actions can use this context to operate on the message.


2 - 28 Release 3.6

Action 3: CallThis action calls Rule #2 to complete the full processing of the submitted message. If the message contains encrypted elements, the system will decrypt them. The result is passed to Rule #1 for complete processing.This eliminates the need to duplicate that complicated set of actions for the supported service endpoint.The Call action then sends the results of executing the actions in Rule #2 (and subsequently Rule#1) to the back end service, preserving the URI.Here is the configuration display for this action:


Input: tempvar2

This is set to tempvar2, the named context used by the preceeding action. Processing Rule: SomeBankCheckService_Rule_1

This is the name stored in the system for Rule #2.Output: OUTPUT


Here is an example of the message sent to the back end server after full processing by the DataPower device:<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Header><saml:Assertion AssertionID="Ide8d5cf8c-84c5-4fb3-81cf-8e2999dc6dc0" IssueInstant="2005-05-

05T19:47:19Z" MajorVersion="1" MinorVersion="1" Issuer="BankConsortium"><saml:AttributeStatement>

<saml:Subject><saml:NameIdentifier>CN=Bob</saml:NameIdentifier>

</saml:Subject><saml:Attribute AttributeName="CheckingServices" AttributeNamespace="http://www.somebank.com">

<saml:AttributeValue>Query</saml:AttributeValue><saml:AttributeValue>Request</saml:AttributeValue>

</saml:Attribute></saml:AttributeStatement><Signature xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext" xmlns:SOAP="http://sche-

Rules

Release 3.6 2 - 29

mas.xmlsoap.org/soap/envelope/" xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo>

<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#Ide8d5cf8c-84c5-4fb3-81cf-8e2999dc6dc0">

<Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

</Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>oLZZRO+Gc/7TSASkipyqCkeBp6I=</DigestValue>

</Reference></SignedInfo><SignatureValue>ePZifp/YHA3yrEZvUMLc+0U0cVQXgqng6GRrUyxaYLqhkMEHR2v35O82vy9wEUI/

xE7M1WLaKHzU3qj1J/45HK02EEqNodDMtLXM5YJy51lIcB+ACacT+OcyGUvfd66oEjzUPpqrKevZoj2rIO9V9x34HXNGdNgRasaZECaiDlM=</SignatureValue>

<KeyInfo><X509Data>

<X509Certificate>MIICNTCCAZ6gAwIBAgIBADANBgkqhkiG9w0BAQUFADAdMQ0wCwYDVQQKEwRCYW5rHhcNMDUwMzMxMDMyNDIxWhcNMDYwMzMxMDMyNDIxWjAdCwYDVQQKEwRCYW5rMQwwCgYDVQQDEwNDVE8wgZ8wDQYJKoZIhvcNAQEBBQADMIGJAoGBAMM5YZbKZHUR50pUE4ohL7I2uwP/2rssa5c2E0LPLzdEn7n7bWYZY9ScQ0SRUnEbp19eLWkDwQjELCq/92Yk3UaOYVQPB8x//sxFnRoXYn02QHRnzys+gn99WEhTWTNgzIP934DXCnYNQ8h/G3mbpMwEoUlTa8oxAgMBAAGjBAUwAwEB/zAdBgNVHQ4EFgQU7QpIZden38pyV+N5qcCUQW0GRQYDVR0jBD4wPIAU7QpIZden38pyV+N5qcCUQW0Gn5+hIaQfMB0xDTALBgNVUT4IBADALBgNVHQ8EBAMCArwwDQYJKoZIhvcNLl17YMpx4o47ZkM3qxBx3ylIHo3boLq9KS1TbLPyAKatIB0CvG0RXVcf9985jWVNM31QfNY0XMjZ/vLL0tQkgx5v/5aPB1VOHk6jZNlje443jejfASSBMH/JEtSVZ987UHGo1p9NBOIQWIELl0GOljjIU=</X509Certificate>

<X509IssuerSerial><X509IssuerName>CN=CTO, O=Bank</X509IssuerName><X509SerialNumber>0</X509SerialNumber>

</X509IssuerSerial></X509Data>

</KeyInfo></Signature>

</saml:Assertion></soapenv:Header><soapenv:Body>

<bank:CheckRequestElement Id="G109f6618-3fD" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bank="http://somebank.com">

<bank:PayorAccountName>Cartoon Studios</bank:PayorAccountName><bank:PayorAccountID>8458jf8757275234</bank:PayorAccountID><bank:CheckType>P</bank:CheckType><bank:Payee>Elmer Fudd</bank:Payee><bank:PayeeAddr>124 East Sunset Drive; Sunset, AL 64846</bank:PayeeAddr><bank:PayeeRouteNo>03849032874908</bank:PayeeRouteNo><bank:Amount>999.00</bank:Amount><Signature xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://schemas.xml-

soap.org/ws/2002/07/secext" xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo>

<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#G109f6618-3fD">

<Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>


2 - 30 Release 3.6

</Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>m61euoh0SdFqgTBE1JHky2EylT8=</DigestValue>

</Reference></SignedInfo><SignatureValue>FsQP6YeA7Fjnl4huOtqiPhzciFCHx5qofsCVvr/xFAoPcjDHqmp/2fMeoxkCKDA6UO/

509ijbxICZQlr+BINptJkEF5SBQaAj2ut1PasCkQFr92AuKAlwwPRz5ORda7ZjlOgkfezf2AwqYXz0UB6YKdYAgRJ1EIf0H5HquAVQQI=</SignatureValue>

<KeyInfo><X509Data>

<X509Certificate>MIICNTCCAZ6gAwIBAgIBADANBgkqhkiG9w0BAQUFADAdMQ0wCwYDVQQKEwRCYW5rHhcNMDUwMzMxMDMyNDIxWhcNMDYwMzMxMDMyNDIxWjAdCwYDVQQKEwRCYW5rMQwwCgYDVQQDEwNDVE8wgZ8wDQYJKoZIhvcNAQEBBQADMIGJAoGBAMM5YZbKZHUR50pUE4ohL7I2uwP/2rssa5c2E0LPLzdEn7n7bWYZY9ScQ0SRUnEbp19eLWkDwQjELCq/92Yk3UaOYVQPB8x//sxFnRoXYn02QHRnzys+gn99WEhTWTNgzIP934DXCnYNQ8h/G3mbpMwEoUlTa8oxAgMBAAGjBAUwAwEB/zAdBgNVHQ4EFgQU7QpIZden38pyV+N5qcCUQW0GRQYDVR0jBD4wPIAU7QpIZden38pyV+N5qcCUQW0Gn5+hIaQfMB0xDTALBgNVUT4IBADALBgNVHQ8EBAMCArwwDQYJKoZIhvcNLl17YMpx4o47ZkM3qxBx3ylIHo3boLq9KS1TbLPyAKatIB0CvG0RXVcf9985jWVNM31QfNY0XMjZ/vLL0tQkgx5v/5aPB1VOHk6jZNlje443jejfASSBMH/JEtSVZ987UHGo1p9NBOIQWIELl0GOljjIU=</X509Certificate>

<X509IssuerSerial><X509IssuerName>CN=CTO, O=Bank</X509IssuerName><X509SerialNumber>0</X509SerialNumber>


</KeyInfo></Signature>


</soapenv:Envelope>

Rules

Release 3.6 2 - 31

Rule #4: Response RuleHere is an examination of the components of Rule #4. Note that this is a Response rule; it will only handle messages sent by the server back to the client and will not handle messages sent to the service by the client.This rule handles server responses to messages that were sent signed and encrypted by the client. The response rule returns a message that is encrypted and signed.

Match Rule: SignedThis rule uses the same Signed match rule as Rule #3. The client must have used the URL */SomeBank/services/signed when making the request for service.









2 - 32 Release 3.6

Output: tempvar1

This is set to tempvar1. The system automatically assigned this output context.

Action 2: EncryptThis action encrypts the entire body of the message using the WS-Security encryption standard. Here is the configuration page for this action.

Figure 2 - 27. Encrypt Response Action

Input: tempvar1

This is set to the output context of the previous action.Envelope Method: WS-Sec Encryption

This is set to encrypt the message according to the WS-Security Encryption standards. This places much of the information about the encrypted methods in the SOAP Header.

Message Type: SOAP Message

This setting causes the entire Body of the SOAP message to be encrypted, rather than just given elements.

Recipient Certificate: SomeBank

This indicates what Cryptographic Certificate object to use to encrypt the message. This is the certificate issued by the recipient of the message

Output: tempvar2

The results of the encryption action will be placed in the tempvar2 context.

Rules

Release 3.6 2 - 33

Action 3: SignThis action signs the encrypted response. The configuration display appears as follows.

Figure 2 - 28. Sign Response Action

Input: tempvar2

This is the output context of the previous action, containing the encrypted message.

Envelope Method: WS-Sec

This method causes the signature to be placed in the SOAP header of the message, in accordance with the WS-Security specifications.

Message Type: SOAP

The entire contents of the Body of the SOAP message will be signed.Key: SomeBank

The private cryptographic key contained in the SomeBank key object will be used for the signature. The configuration of this object is covered below.

Certificate: SomeBank

The public cryptographic certificate contained in the SomeBank certificate object will be used for the signature. The configuration of this object is covered below.


2 - 34 Release 3.6

Output: OUTPUT

This is the special OUTPUT context, sent back to the client.This rule returns an encrypted, signed message to the client.<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">

<soapenv:Header><wsse:Security>

<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509" wsu:Id="cert">MIICN...ljjIU=</wsse:BinarySecurityToken>

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">

<SignedInfo xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#Body" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">

<Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>nIY+QHKv+g+/pTxHOSVVxnAmCgw=</DigestValue>

</Reference></SignedInfo><SignatureValue>kARx6lAeA...dHvc=</SignatureValue><KeyInfo>

<wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="">

<wsse:Reference URI="#cert" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509"/>

</wsse:SecurityTokenReference></KeyInfo><KeyInfo>

<X509Data><X509Certificate>MIICNTCCAZ6...</X509Certificate><X509IssuerSerial>

<X509IssuerName>CN=CTO, O=Bank</X509IssuerName><X509SerialNumber>0</X509SerialNumber>


</KeyInfo></Signature><xenc:EncryptedKey>

<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns="http://www.w3.org/2001/04/xmlenc#"/>

<dsig:KeyInfo><wsse:SecurityTokenReference>

<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-mes-sage-security-1.0#X509SubjectKeyIdentifier"> 7QpIZden38pyV+N5qcCUQW0Gn58= </wsse:KeyIdentifier>

</wsse:SecurityTokenReference></dsig:KeyInfo><CipherData xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns="http://www.w3.org/2001/04/xmlenc#">

Rules

Release 3.6 2 - 35

<CipherValue>msag...9zu8tVTA=</CipherValue></CipherData><xenc:ReferenceList>

<xenc:DataReference URI="#body"/></xenc:ReferenceList>

</xenc:EncryptedKey></wsse:Security>

</soapenv:Header><soapenv:Body wsu:Id="Body" id="Body">

<xenc:EncryptedData Id="body" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:bank="http://some-bank.com">

<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>

<CipherData xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><CipherValue>aYYD...2oPo</CipherValue>

</CipherData></xenc:EncryptedData>

</soapenv:Body></soapenv:Envelope>

Rule #5: Response RuleHere is an examination of the components of Rule #5. Note that this is a Response rule; it will only handle messages sent by the server back to the client and will not handle messages sent to the service by the client.This rule handles server responses to messages that were sent signed and encrypted by the client. The response rule returns a message that is encrypted and signed.

Match Rule: EncryptedA Match Rule examines the response message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. As with the corresponding request rule, the response rule will not run unless the client submits the URL */SomeBank/services/encrypted.The firewall automatically validates the response message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the calling client. This SOAP schema filtering is implied and no action needs to be created for it.


2 - 36 Release 3.6








Output: (Blank)

This is set to Blank. The system will automatically configure the correct output context.

Rules

Release 3.6 2 - 37

Action 2: EncryptThis action encrypts the entire body of the message using the WS-Security encryption standard. Here is the configuration page for this action.

Figure 2 - 30. Encrypt Response Action

Input: INPUT

This is set to the special INPUT context, which contains the message submitted by the server.

Envelope Method: WS-Sec Encryption

This is set to encrypt the message according to the WS-Security Encryption standards. This places much of the information about the encrypted methods in the SOAP Header.

Message Type: SOAP Message

This setting causes the entire Body of the SOAP message to be encrypted, rather than just given elements.

Recipient Certificate: SomeBank

This indicates what Cryptographic Certificate object to use to encrypt the message. This is the certificate issued by the recipient of the message

Output: OUTPUT

The results of the encryption action will be sent directly back to the client.


2 - 38 Release 3.6

Here is an example response sent to the client.<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

<soapenv:Header xml:space="preserve"><wsse:Security soapenv:mustUnderstand="1">

<xenc:EncryptedKey><EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" xmlns="http://www.w3.org/

2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/><dsig:KeyInfo>

<wsse:SecurityTokenReference><wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-

message-security-1.0#X509SubjectKeyIdentifier"> 7QpIZden38pyV+N5qcCUQW0Gn58= </wsse:KeyIdentifier>

</wsse:SecurityTokenReference></dsig:KeyInfo><CipherData xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmld-

sig#"><CipherValue>YhZpyC...Z26Ws=</CipherValue>

</CipherData><xenc:ReferenceList><xenc:DataReference URI="#body"/></xenc:ReferenceList>

</xenc:EncryptedKey></wsse:Security>

</soapenv:Header><soapenv:Body xmlns:bank="http://somebank.com">

<xenc:EncryptedData Id="body" Type="http://www.w3.org/2001/04/xmlenc#Content"><EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" xmlns="http://

www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/><CipherData xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmld-

sig#"><CipherValue>+I8I+EO2...a7Cycd0</CipherValue>

</CipherData></xenc:EncryptedData>

</soapenv:Body></soapenv:Envelope>

Rules

Release 3.6 2 - 39

Rule #6: Response RuleHere is an examination of the components of Rule #6. Note that this is a Response rule; it will only handle messages sent by the server back to the client and will not handle messages sent to the service by the client.This rule handles server responses to messages that were sent unsigned and unencrypted by the client. The response rule returns a message that is neither encrypted and signed.Match Rule: CheckingA Match Rule examines the response message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. As with the corresponding request rule, the response rule will not run unless the client submits the URL */SomeBank/services/checking.The firewall automatically validates the response message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the calling client. This SOAP schema filtering is implied and no action needs to be created for it.Action 1: ValidateThe first custom action of Rule #6 validates the contents of the SOAP Body element against a custom schema. This insures that the payload also contains the required elements and does not contain invalid elements. Here is the configuration of this action:






2 - 40 Release 3.6



Output: (Blank)


Action 2: TransformThis action connects the original response message to the OUTPUT context, if the Validate action succeeds.

Figure 2 - 32. Transform Action Configuration

Input: INPUT

This is set to INPUT, the special context containing the submitted message.Document Processing Instructions: Specified by rule




Rules

Release 3.6 2 - 41

Output: OUTPUT

The action sends the INPUT message directly to OUTPUT, which is then transmitted to the client.

Here is an example response message.<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:bank="http://somebank.com">

<soapenv:Body><bank:CheckResponseElement>

<bank:TransactionNum>66287</bank:TransactionNum><bank:CheckNum>23423</bank:CheckNum><bank:CheckType>P</bank:CheckType><bank:PayorAccountID>8458jf8757275234</bank:PayorAccountID><bank:Payee>Elmer Fudd</bank:Payee><bank:Amount>999.00</bank:Amount>

</bank:CheckResponseElement></soapenv:Body>

</soapenv:Envelope>


2 - 42 Release 3.6

MonitorsThis service employs four different monitors for security against XML threats. These monitors were listed on the Advanced page of the Firewall configuration. These monitors are as follows.

All of these monitors were configured automatically by the device. All but the SomeBank-RejectedAccess monitor can be easily altered from the XML Threat Protection page of the firewall service. On the Control Panel, click Edit XML Firewall. Click the firewall name in the list of firewalls. Finally, scroll to the bottom of the page and click the XML Threat Protection button.Altering the SomeBank-RejectedAccess monitor can be done from the Firewall Policy page; however, it is easier to alter the Count Monitor object directly. Click the Services navigation bar and then click Message Monitors. The following page appears.

Figure 2 - 33. Message Monitor Listing

Click SomeBank-RejectedAccess. The Message Monitor appears.

Monitor Name Type Purpose

SomeBank-RejectedAccess

Count Track the number of access requests rejected by the Authentication and Authorization system. If more than x submissions are rejected within x milliseconds, the monitor will block access. This is one method to detect dictionary attacks.

SomeBankCheckService-count-monitor-firewall

Count Track the total number of access requests to the service. If more than x requests occur within x milliseconds, the monitor will block access for a period of time. This detects a DDOS attack.

SomeBankCheckService-count-monitor-from-ip

Count Track the total number of access requests from any given host IP address. If more than x requests occur within x milliseconds, the monitor will block access for a period of time. This detects a DOS attack.

SomeBankCheckService-duration-monitor

Duration Track the total duration of request processing. If the average duration exceeds a threshold, the monitor will block access for a period of time. This is another type of DOS attack and also enforces service response time levels.

Monitors

Release 3.6 2 - 43

Figure 2 - 34. Message Monitor Properties

Click Next. The following page appears.

Figure 2 - 35. Count Monitor Filters

Click the filter name. The following page appears.

Figure 2 - 36. Edit Count Monitor Filter

You can now change the thresholds for this monitor. When you have made the needed changes, click Submit. The screen redisplays the previous page.


2 - 44 Release 3.6

If you wish to change the Action taken when the threshold is reached, click the ... button alongside the Action. The following appears.

Figure 2 - 37. Editing a Message Filter Action

Make any necessary changes and click Apply. This window closes.After making the necessary changes to the Count Monitor filter and clicking either Submit or Cancel, the following page reappears.

Figure 2 - 38. Monitor Filters

Click Next.

Monitors

Release 3.6 2 - 45

The following page appears.

Figure 2 - 39. Confirm Monitor changes

Click Commit.


2 - 46 Release 3.6

LoggingThis example employs a custom log target, which captures messages generated by the services handling the SomeBank Checking web services traffic. Here is the configuration display of the custom Log Target object Main page:


Type: syslog

This log target sends captured log messages to a syslog process elsewhere on the network..

Local Identifier: DP

The Local Identifier embedded in the syslog message. Syslog management tools can filter on this value.

Remote Host Address: 10.10.100.3

This is the IP address of the remote syslog utility.Remote Port: 263

The syslog listens on port 263.Syslog Facility: user

The log entries are sent to the syslog with this facility.Backup Log: default-log

In the event the syslog facility cannot be reached, this back up log will capture log messages.

Logging

Release 3.6 2 - 47

Note that when a device is rebooted (as opposed to the firmware reloaded), all temporary files on the filesystem are erased. For this reason, log files are often moved off the device for storage. Using a remote logging utility is a common strategy.







2 - 48 Release 3.6


SSL Communications

Release 3.6 2 - 49

SSL CommunicationsIn this scenario, the communication channels between the DataPower service and the requesting client use SSL to encrypt communications. The firewall configuration page shows the setting to use SSL communications.


Here is the configuration of the Crypto Profile:


Identification Credentials: SomeBank




All other inputs are set to the default, requiring no configuration action. With SSL enabled, the browsers use HTTPS rather than HTTP to communicate with the DataPower system.


2 - 50 Release 3.6

Crypto Identification CredentialsThe SSL Crypto Profile relies upon the Crypto Identification Credential SomeBank. Here is the configuration of the Identification Credential object:




SSL Communications

Release 3.6 2 - 51






2 - 52 Release 3.6

SomeBank Checking Service WSDL<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace="http://somebank.com" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:bank="http://somebank.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <wsdl:types> <xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://somebank.com"> <xs:element name="AccountRequestElement" type="bank:AccountRequest"/> <xs:complexType name="AccountRequest"> <xs:sequence> <xs:element name="accountName" type="xs:string"/>  <xs:element name="accountID" type="xs:string"/>  <xs:element name="accountType" type="xs:string"/>  </xs:sequence> </xs:complexType> <xs:element name="AccountResponseElement" type="bank:AccountResponse"/> <xs:complexType name="AccountResponse"> <xs:sequence> <xs:element name="balance" type="xs:float"/> </xs:sequence> </xs:complexType></xs:schema><xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://somebank.com">








<xs:sequence> <xs:element name="TransactionNum" type="xs:int"/> <xs:element name="ErrorNum" type="xs:int"/>

SomeBank Checking Service WSDL

Release 3.6 2 - 53

<xs:element name="CheckType" type="xs:string"/> <xs:element name="PayorAccountID" type="xs:string"/> <xs:element name="Payee" type="xs:string"/>

<xs:element name="ErrorMessage" type="xs:string"/></xs:sequence>

</xs:complexType></xs:schema> </wsdl:types> <wsdl:message name="AccountResponse"> <wsdl:part element="bank:AccountResponseElement" name="response"/> </wsdl:message> <wsdl:message name="AccountRequest"> <wsdl:part element="bank:AccountRequestElement" name="request"/> </wsdl:message> <wsdl:message name="CheckResponse"> <wsdl:part element="bank:CheckResponseElement" name="checkresponse"/> </wsdl:message> <wsdl:message name="CheckRequest"> <wsdl:part element="bank:CheckRequestElement" name="checkrequest"/> </wsdl:message> <wsdl:message name="CheckRequestError"> <wsdl:part element="bank:CheckRequestErrorElement" name="checkrequesterror"/> </wsdl:message> <wsdl:portType name="SomeBankPortType"> <wsdl:operation name="accountEnquiry" parameterOrder="request"> <wsdl:input message="bank:AccountRequest"/> <wsdl:output message="bank:AccountResponse"/> </wsdl:operation> <wsdl:operation name="checkRequest" parameterOrder="request"> <wsdl:input message="bank:CheckRequest"/> <wsdl:output message="bank:CheckResponse"/> <wsdl:fault message="bank:CheckRequestError"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="SomeBankBinding" type="bank:SomeBankPortType"> <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="accountEnquiry"> <wsdlsoap:operation soapAction=""/> <wsdl:input> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="checkRequest"> <wsdlsoap:operation soapAction=""/> <wsdl:input> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output> <wsdlsoap:body use="literal"/> </wsdl:output> <wsdl:fault name="bank:CheckRequestError"> <wsdlsoap:fault use="literal"/> </wsdl:fault> </wsdl:operation> </wsdl:binding> <wsdl:service name="SomeBankService">


2 - 54 Release 3.6

<wsdl:port binding="bank:SomeBankBinding" name="SomeBankPort"> <wsdlsoap:address location="http:/10.10.13.35:2068/SomeBankService/services/SomeBankPort"/> </wsdl:port> <wsdl:port binding="bank:SomeBankBinding" name="SomeBankPortSignedAndEncrypted"> <wsdlsoap:address location="http:/10.10.13.35:2068/SomeBank/services/signed"/> </wsdl:port> <wsdl:port binding="bank:SomeBankBinding" name="SomeBankPortEncrypted"> <wsdlsoap:address location="http:/10.10.13.35:2068/SomeBank/services/encrypted"/> </wsdl:port> <wsdl:port binding="bank:SomeBankBinding" name="SomeBankPortChecking"> <wsdlsoap:address location="http:/10.10.13.35:2068/SomeBank/services/checking"/> </wsdl:port> </wsdl:service></wsdl:definitions>

3 - 1

Chapter 3Multi-Protocol Gateway

This example configuration implements a simple bank checking service. Requests arrive from any number of other hosts that offer the consumer the checking service. Requests may arrive using the MQ, HTTP or HTTPS protocol. The SOAP request for service is formatted according to a published schema (available from the WSDL for the service; refer to the end of this chapter), and is signed. Requests are validated against well-known SOAP schemas, the published schema for the service, filtered for data correctness and finally the WS-Security signature on the message is verified. Here is an illustration of the architecture involved.

All traffic between the DataPower device and the application server travels over plain HTTP. The DataPower system performs the following tasks on requests:

• Validates Request Against Schema• Filters Request Data• Verifies Signatures• Forwards to Endpoint

The DataPower box performs the following tasks on the response from the server:• Vaildates Response Format• Signs Response Message (if request was signed)

XML Threat Protection is applied to all traffic passing through the Gateway.

DataPowerEndpoint

Many App Servers

HTTP

HTTPHTTPS

MQ

Multi-Protocol Gateway

3 - 2 Release 3.6

Multi-Protocol GatewayThe upper portion of the Multi-Protocol Gateway Service configuration page appears as shown here.

Figure 3 - 1. Multi-Protocol Gateway Configuration (partial)

These are the field values.Multi-Protocol Gateway Name: CheckingService

The name of the gateway object. This name may appear in the Via: field of the HTTP headers returned during SOAP and XML web service transactions. It also appears in the log files.

Multi-Protocol Gateway Type: Static backend

The gateway forwards all requests to a single back end server IP address and Port.


The default is used. Multi-Protocol Gateway Policy: CheckServicePolicy

The custom processing policy built for this service, CheckServicePolicy, is selected. This policy is covered in detail below.


The default is used. The URLs sent by the clients are not altered in any way before the processing policy is run.


Release 3.6 3 - 3

Back Side SettingsBack End URL: http://10.10.13.35:2068

All traffic is routed to the address given here. Note that no URI is included in this value. This is because the Propogate URI property is set to on - the default. The gateway will automatically append whatever the client provides from the first forward-slash in the URL to the last character. Thus if the client uses the URL http://gwaddr:3001/SomeBank/services/checking, the complete URL employed by the gateway when sending to the back end service is http://10.10.13.35:2068/SomeBank/services/checking.

Front Side SettingsFront Side Protocol: (HTTP, HTTPS and MQ Protocol Handlers)

The gateway has three Front Side Protocol Handlers configured, one for the HTTP protocol, one for the HTTPS protocol and one for the MQ protocol. The Front Side Handlers determine the IP address, port number and other transport-layer properties. These handlers are covered in detail below.


Back End Settings (left column)User Agent Settings: None

The default is used. No User Agent settings will affect gateway communications.


3 - 4 Release 3.6

SSL Client Crypto Profile: None

The default is used. Communication with the back end server will not employ SSL in this case. Even if a profile were selected, the Back End URL indicates that the traffic will pass over HTTP and not HTTPS, so this setting would be ignored.

Response Type: SOAPThe selection SOAP indicates that the back end server will post SOAP documents in response to requests from the gateway service. The gateway service automatically validates the documents against the SOAP schemas now in use (SOAP 1.1, 1.2 and variants).


The default value (strip) is used. Any attachments sent by the server will be stripped off before the message is handled by the gateway service.

Back Attachment Processing Format:: Automatically detect

The default value (Automatically detect) is used. Leaving this at the default ensures that all attachments may pass through the gateway regardless of format. Since the gateway is configured to pass through attachments, selecting the wrong format could cause an error.

Front End Settings (right column)Request Type: SOAP

The selection SOAP indicates that the clients will post SOAP-formatted documents to the gateway service. Inbound SOAP documents are automatically validated against the published SOAP schemas. If the messages do not comply with the schemas, an error is returned to the client.

Request Attachments: : Attachments are sent but unprocessed.

This setting allows the gateway to accept and forward any attachments contained in the message payload but frees the gateway from the need to apply any processing to attachments. Thus, this service may receive a MIME or DIME message containing the primary XML document in the root part of the message and perhaps a check image in an attachment but the image will not be handled in any way. The root part XML document, however, will be processed by the Policy selected.

Front Attachment Processing Format: Automatically detect

The default value (Automatically detect) is used. As any attachments sent by the back end service will be stripped off before the message is handled by the gateway service, this setting has no meaning.


Release 3.6 3 - 5


The service accepts a number of other inputs, all of which are set to the default. These are shown above.

Advanced TabThe Advanced tab offers several properties that were changed from the defaults. Here is the page:

Figure 3 - 4. Advanced Configuration

All of these inputs have been left at the defaults with the exception of the following properties.


3 - 6 Release 3.6

Loop Detection: On

This has been changed to On from the default. The gateway will automatically insert the HTTP Header Via: and the name of the gateway service into messages it processes. This will allow the gateway to detect loops.

Follow Redirects: On

This has been changed to On from the default. If the back end server sends the gateway an HTTP Redirect, the Gateway will follow it, and resend the HTTP message to the redirected URL. This allows the back end service to redirect traffic during maintenance windows. This can be considered a security risk.

Allow Chunked Uploads: On

This has been changed to On from the default. This setting allows the gateway to send large files in chunked uploads to the back end server. The back end server must implement HTTP 1.1 to support this. This can speed transmission.

XML Threat ProtectionThe gateway has been configured to provide a degree of XML Threat Protection. These settings automatically create a set of monitors for the service.

Figure 3 - 5. XML Threat Protection Configuration

Only the Single Message and Multiple Message sections have been configured, as shown above.


Release 3.6 3 - 7

Single Message XML Denial of Service (XDOS)Maximum Message Size: 0

This is zero, the default. The gateway will accept a message of any size.Gateway Parser Limits: On

This has been changed to On from the default. The following inputs will override any similar settings in the XML Manager used by the gateway.

XML Attribute Count: 32

This has been changed to 32 from the default of 128. This setting applies significantly more stringent limits on the number of attributes allowed within submitted documents.

XML Element Depth: 64

This has been changed to 64 from the default of 512. This setting applies significantly more stringent limits on the depth of elements allowed within submitted documents.

XML Attribute Maximum Node Size: 500000

This has been changed to 500K from the default. No single element node within the submitted document can exceed 500K in size.

Attachment Byte Count Limit: 20000000

This has been changed to 20 Meg from the default of 2 gigabytes. Very large binary attachments will not be accepted by the gateway

Multiple Message XML Denial of Service (MMDOS)Max Duration for a Request: 10000

Ten thousand milliseconds (10 seconds) are allowed for processing any one request.

Interval for Measuring Request Rate from Host: 3000

The value of 3000 measures how many requests are received from any given host every 3 seconds. Note that this is not set lower due to the fact that a busy gateway will not execute this check as the highest priority task; instead it will process documents and then check this measurement.

Max. Request Rate from Host: 50

No host can send more than 50 requests every 3 seconds.Interval for Measuring Request Rate for Gateway: 3000

The value of 3000 sets the measurement interval at 3 seconds.Max Request Rate for Gateway: 300

The gateway will accept 300 requests every 3 seconds.Block Interval: 500

The gateway will block access after one of the other thresholds have been reached for 500 milliseconds.

Log Level

When a threshold is reached, the gateway generates an error log message.


3 - 8 Release 3.6

MonitorsThe XML Threat Protection settings automatically create the monitors shown on the Monitors tab.

Figure 3 - 6. Monitors

It is easier to modify these monitors through the XML Threat Protection Page than through the Monitors directly.

Front Side Protocol Handlers

Release 3.6 3 - 9

Front Side Protocol HandlersThis gateway employs two Front Side Protocol Handlers.

HTTP Front Side Protocol Handler

Figure 3 - 7. HTTP Front Side Protocol Handler

All of the defaults have been used with the exception of the following information.Name: chk-http-handler

The name of the handler. This is the name that appears in the gateway configuration page.

Local IP Address: 0000

This has been left at the default. The default indicates that this Handler will listen on the port number indicated for all configured IP addresses.

Port Number: 3001

This was entered by hand. The system does not assign the next available number. This value must be unique throughout the device.


3 - 10 Release 3.6

HTTPS Front Side Protocol Handler

Figure 3 - 8. HTTPS Front Side Protocol Handler

All of the defaults have been used with the exception of the following information.Name: chk-https-handler


Local IP Address: 0000

This has been left at the default. The default indicates that this Handler will listen on the port number indicated for all configured IP addresses.

Port Number: 3002

This was entered by hand. The system does not assign the next available number. This value must be unique throughout the device.


Release 3.6 3 - 11

Figure 3 - 9. SSL Proxy Setting

SSL Proxy: SomeBanks

The SSL Proxy Proflle SomeBanks is selected. The configuration of this Proxy is discussed in detail below.

MQ Front Side Protocol Handler

Figure 3 - 10. MQ Front Side Protocol Handler

All of the defaults have been used with the exception of the following information.Name: SomeBank-MQ


Queue Manager: ZippyBanker

This is the name of a Websphere MQ Queue Manager object configured in the same application domain on the device. The configuration of this object is covered below.

Get Queue: QUEUE1

This is the name of a queue available on the remote MQ Queue Manager. The Protocol Handler will constantly poll this queue for requests to process. This name must be provided by the local MQ administrator.


3 - 12 Release 3.6

Put Queue: QUEUE2

This is the name of a queue available on the remote MQ Queue Manager. The Protocol Handler will place responses on this queue. This name must be provided by the local MQ administrator.

Websphere MQ Queue Manager

Figure 3 - 11. Websphere MQ Queue Manager Configuration

All of the defaults have been used with the exception of the following information.Name: ZippyBanker

The name of the Queue Manager object. This is the name that appears in the Protocol Handler configuration page.

Host Name: 10.10.100.74(5558)

The Remote Host running the remote MQ Queue Manager instance managing the queues. This takes the format address(port) in accordance with the MQ client specifications.


Release 3.6 3 - 13

Queue Manager Name: WAS_ip1_server1

The name of the remote Queue Manager to use for this connection. Multiple Queue Managers may be available on the host indicated. This name must match the remote name exactly. The Get and Put queues used by the Front Side Protocol Handler must be managed by this Queue Manager.

Channel Name: SYSTEM.DEF.SVRCONN

This is the default channel. The Queue Manager could use a different channel, if configured.

User Name: mqm

This is the user name the Protocol Handler will present to the Queue Manager when connecting to queues. This is optional.

Convert Input: Off

Normally, the Queue Manager will automatically convert messages to the native MQ format. Turning this off preserves the format of the submitted message.


3 - 14 Release 3.6

Multi-Protocol Gateway PolicyHere is the graphic representation of the gateway policy used for this implementation.

Figure 3 - 12. SomeBankCheckServices Multi-Protocol Gateway Policy






Rules

Release 3.6 3 - 15

Rules

OverviewHere is an overview of the rules used in this policy.Rule 1 Request Rule Matching */SomeBank/services/checking


1 Validate against the published schema for the service2 Filter requests for valid values3 Verify the WS-Security digital signature4 Send to back end service

Rule 2 Response Rule Matching */SomeBank/services/checkingThis rule runs when the server sends the matching URL. This rule operates on the response from the server. The rule performs the following actions:

1 Validate server response against schema2 Sign the response using a WS-Security signature

Here is an example of a message submitted to the gateway.<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Header><saml:Assertion AssertionID="ac980a79b0ee3d3f4824318155b790ec" IssueInstant="2004-04-15T21:48:03Z"

Issuer="BankConsortium" MajorVersion="1" MinorVersion="1" xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

<saml:AttributeStatement><saml:Subject>

<saml:NameIdentifier>CN=Bob</saml:NameIdentifier></saml:Subject><saml:Attribute AttributeName="CheckingServices" AttributeNamespace="http://www.somebank.com">

<saml:AttributeValue>Query</saml:AttributeValue><saml:AttributeValue>Request</saml:AttributeValue>

</saml:Attribute></saml:AttributeStatement>

</saml:Assertion><wsse:Security soapenv:mustUnderstand="1">

<wsu:Timestamp wsu:Id="Timestamp-5b766324-0c15-4ce7-8c3a-6d65eaf90c48"><wsu:Created>2005-07-22T00:48:37Z</wsu:Created><wsu:Expires>2005-07-22T00:53:37Z</wsu:Expires>

</wsu:Timestamp><wsse:BinarySecurityToken wsu:Id="SecurityToken-99d46647-a66c-419b-9257-146ee48fec7f" Encoding-

Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" Value-Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509">MIICBjCCAW+gAwIBAgIBADANBgkqhkiG9w0BAQUFADAOMQwwCgYDVQQDEwNDVE8wHhcNMDUwNTI3MDAyMzM3WhcNMDYwNTI3MDAyMzM3WjAOMQwwCgYDVQQDEwNDVE8wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMvT9vYN8iULhSQUHJXpduB6gFKHebqoUog9a+an2lOG5tKm4sgPLF2EEMZPiMLPxfK8wYmKZ+L3hp4O4Rl3UDNfhTIBebQeS0OIUQUKdOu/DnvPuISgf1f1UJYuI/ovRoohfLLiIIUBrAnDzR2EMb7vfMgb+pf/JcOtzfvROJ8jAgMBAAGjdDByMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFLtFYCU8LH0ro2lqI0g1t3bSV8C3MDYGA1UdIwQvMC2AFLtFYCU8LH0ro2lqI0g1t3bSV8C3oRKkEDAOMQwwCgYDVQQDEwNDVE+CAQAwCwYDVR0PBAQDAgK8MA0GCSqGSIb3DQEBBQUAA4GBAD+MdbIDf7UPY71khyCwCIj9c/ggPraNWMI34b+upJM+O8tI7s55


3 - 16 Release 3.6

qUDyfdY1/ne1mh7yOPW6l8Gg3aXw2k1Pkpefs+Ol5vwUvtSu53sKM4lZZbBywa3JoYzFfsmVPbyXx58UsxAfajryHtHN7110/C/I0RuZRgVhyW4s6eBu1/qj</wsse:BinarySecurityToken>

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo>

<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#Body-2e12f754-09ec-47bd-9db0-a59e0461ebf2">


</Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>D1VOiRZo3+90OIERsEzm9PYUcjw=</DigestValue>

</Reference><Reference URI="#Timestamp-5b766324-0c15-4ce7-8c3a-6d65eaf90c48">


</Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>pMZucLpEEkJ8cF976C1GbWqQFjs=</DigestValue>

</Reference></SignedInfo>

<SignatureValue>F1mns6cSay4W1znuZ3W4Ao94bDFdhmeBN5MLpYZrMch9dUD5hL4AO6ApZdKpLHm623BXAr+oP54CJEs9OA9vpWYJYMXwDfFIuuu278g7sZyp56tIdQyE3V1PHLTnONhpjTTiiEfXZ89u8vmvBQYoj2r8/qRc8J7j8n1Ke5ZRkvY=</SignatureValue>

<KeyInfo><wsse:SecurityTokenReference xmlns="">

<wsse:Reference URI="#SecurityToken-99d46647-a66c-419b-9257-146ee48fec7f" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509"/>

</wsse:SecurityTokenReference></KeyInfo>

</Signature></wsse:Security>

</soapenv:Header><soap:Body wsu:Id="Body-2e12f754-09ec-47bd-9db0-a59e0461ebf2">

<bank:CheckRequestElement xmlns:bank="http://somebank.com"><bank:PayorAccountName>Cartoon Studios</bank:PayorAccountName><bank:PayorAccountID>8458jf8757275234</bank:PayorAccountID><bank:CheckType>P</bank:CheckType><bank:Payee>Elmer Fudd</bank:Payee><bank:PayeeAddr>124 East Sunset Drive; Sunset, AL 64846</bank:PayeeAddr><bank:PayeeRouteNo>03849032874908</bank:PayeeRouteNo><bank:Amount>999.00</bank:Amount>

</bank:CheckRequestElement></soap:Body>

</soapenv:Envelope>

Rules

Release 3.6 3 - 17

Rule #1: Request RuleHere is an examination of the components of Rule #1. Note that this is a Request rule; it will only handle messages sent to the service by the client and will not handle messages sent by the server back to the client.This is the core processing rule of the policy. All messages must pass through this set of validation, filter, and verification steps.

Match Rule: CheckingA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 3 - 13. Checking Match Rule Configuration

The client must use the URL */SomeBank/services/checking or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”

Implied Action 0: ValidateThe gateway automatically validates the inbound message against the SOAP schemas, to ensure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it. Consequently, the gateway may reject a message before any of the actions in the configured policy run.


3 - 18 Release 3.6





This is set to validate the document using a specified schema URL. A URL must be provided that identifies the location of the schema file.



Output: tempvar1

This is set to tempvar1. If the input is valid, the context will contain the validated message. If an error occurs (the message fails to validate, for example), the context is empty. Any subsequent actions can access the results by using tempvar1 as the input context.

Rules

Release 3.6 3 - 19

Here is the schema file used for this action.<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:bank="http://somebank.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://somebank.com" elementFormDefault="qualified">








<xs:sequence><xs:element name="TransactionNum" type="xs:int"/><xs:element name="ErrorNum" type="xs:int"/><xs:element name="CheckType" type="xs:string"/><xs:element name="PayorAccountID" type="xs:string"/><xs:element name="Payee" type="xs:string"/><xs:element name="ErrorMessage" type="xs:string"/>


</xs:schema>


3 - 20 Release 3.6



Input: tempvar1


Processing Control File: local:///SomeBankCheckService.xsl

This is set to local:///SomeBankCheckService.xsl. The custom XSLT file has been uploaded to the device and placed in the local: directory.

Output: (blank)


Here is the XSLT file used for this Filter action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet extension-element-prefixes="dp" version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP12="http://www.w3.org/2003/05/soap-envelope" xmlns:dp="http://www.datapower.com/extensions" xmlns:bank="http://somebank.com">

<xsl:template name="valid-operation"><xsl:param name="op"/><xsl:choose>

<xsl:when test="$op='CheckRequestElement'"><xsl:choose>

<xsl:when test="string-length(/SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:PayorAccoun-

Rules

Release 3.6 3 - 21

tID) != 0 and length(/SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:Payee) != 0 and

/SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:Amount > 10"><xsl:copy-of select="/"/>


<xsl:variable name="errtext" select="'Invalid Input'"/><dp:xreject reason="$errtext"/><xsl:message>


</xsl:otherwise></xsl:choose></xsl:when><xsl:when test="$op='CheckResponseElement'">


<xsl:variable name="errtext" select="concat('Rejected illegal operation ', $op)"/><dp:xreject reason="$errtext"/><xsl:message>



</xsl:template><xsl:template match="/">

<xsl:choose><xsl:when test="dp:responding()">


<xsl:choose><xsl:when test="count(/SOAP:Envelope) > 0">

<xsl:call-template name="valid-operation"><xsl:with-param name="op" select="local-name(/SOAP:Envelope/SOAP:Body/*)"/>

</xsl:call-template></xsl:when><xsl:when test="count(/SOAP12:Envelope) > 0">

<xsl:call-template name="valid-operation"><xsl:with-param name="op" select="local-name(/SOAP12:Envelope/SOAP12:Body/*)"/>

</xsl:call-template></xsl:when><xsl:otherwise>

<xsl:call-template name="valid-operation"><xsl:with-param name="op" select="local-name(/*)"/>

</xsl:call-template></xsl:otherwise>

</xsl:choose></xsl:otherwise>


</xsl:stylesheet>


3 - 22 Release 3.6

Action 3: VerifyThis action verifies the digital signature contained in the WS-Security header. It either accepts or rejects the message. Here is the configuration display for this action:

Figure 3 - 16. Verify Configuration

Input: tempvar1


Signer Certificate: (blank)

This is left at the default (blank). The certificate will be retrieved from the message itself. If no certificate is included, verification will fail.

Validation Credentials: SomeBanks

This is set to the Validation Credential object SomeBanks. The validation credential object must have an exact copy of the certificate presented by the message or the verification will fail.

Output: (blank)


Rules

Release 3.6 3 - 23

Action 5: TransformThis tranform action serves to connect the last context that contained the possibly altered message to any actions that follow. The policy configuration page automatically creates this action following a filter or verification. Here is the configuration page display for this action.


Input: tempvar4

This is set to tempvar4, the named context used by the preceeding action. Document Processing Instructions: Specified by rule




Output OUTPUT

This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is forwarded to the back end service. If none of the filters and authorization steps have rejected the message after it is validated, it is forwarded to the back end server.


3 - 24 Release 3.6

Rule #2: Response RuleHere is an examination of the components of Rule #2. Note that this is a Response rule; it will only handle messages sent by the server back to the client and will not handle messages sent to the service by the client.This rule handles server responses to signed client messages. The response rule returns a signed message.

Match Rule: CheckingA Match Rule examines the response message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the server to determine a match. As with the corresponding request rule, the response rule will not run unless the server submits the URL */SomeBank/services/checking.The gateway automatically validates the response message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the calling client. This SOAP schema filtering is implied and no action needs to be created for it.




Rules

Release 3.6 3 - 25





Output: (Blank)


Action 3: SignThis action signs the response. The configuration display appears as follows.


Input: INPUT

This is the special INPUT context, containing the original message.Envelope Method: WS-Sec



3 - 26 Release 3.6

Message Type: SOAP

The entire contents of the Body of the SOAP message will be signed.Key: SomeBanks

The private cryptographic key contained in the SomeBanks key object will be used by the gateway to sign the message. The configuration of this object is covered below.

Certificate: SomeBanks

The public cryptographic certificate contained in the SomeBanks certificate object will be placed within the binary security token element. The configuration of this object is covered below.

Output: OUTPUT

This is the special OUTPUT context, sent back to the client.Here is an example response message.<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:bank="http://somebank.com">

<soapenv:Header><wsse:Security soapenv:mustUnderstand="1">

<wsu:Timestamp wsu:Id="Timestamp-b4f998b3-6ed0-4b50-919b-9a15fd64d72d"><wsu:Created>2005-07-22T00:49:11Z</wsu:Created><wsu:Expires>2005-07-22T00:54:11Z</wsu:Expires>

</wsu:Timestamp><wsse:BinarySecurityToken wsu:Id="SecurityToken-579dc38e-8990-4b5f-a544-1c1cfb717d1d" Encoding-

Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" Value-Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509">MIICBjCCAW+gAwIBAgIBADANBgkqhkiG9w0BAQUFADAOMQwwCgYDVQQDEwNDVE8wHhcNMDUwNTI3MDAyMzM3WhcNMDYwNTI3MDAyMzM3WjAOMQwwCgYDVQQDEwNDVE8wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMvT9vYN8iULhSQUHJXpduB6gFKHebqoUog9a+an2lOG5tKm4sgPLF2EEMZPiMLPxfK8wYmKZ+L3hp4O4Rl3UDNfhTIBebQeS0OIUQUKdOu/DnvPuISgf1f1UJYuI/ovRoohfLLiIIUBrAnDzR2EMb7vfMgb+pf/JcOtzfvROJ8jAgMBAAGjdDByMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFLtFYCU8LH0ro2lqI0g1t3bSV8C3MDYGA1UdIwQvMC2AFLtFYCU8LH0ro2lqI0g1t3bSV8C3oRKkEDAOMQwwCgYDVQQDEwNDVE+CAQAwCwYDVR0PBAQDAgK8MA0GCSqGSIb3DQEBBQUAA4GBAD+MdbIDf7UPY71khyCwCIj9c/ggPraNWMI34b+upJM+O8tI7s55qUDyfdY1/ne1mh7yOPW6l8Gg3aXw2k1Pkpefs+Ol5vwUvtSu53sKM4lZZbBywa3JoYzFfsmVPbyXx58UsxAfajryHtHN7110/C/I0RuZRgVhyW4s6eBu1/qj</wsse:BinarySecurityToken>

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo>

<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#Body-d4415997-3451-4f0c-bb03-c643f544f240">


</Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>wWjxCIQokEOkVxBZ492DzLfDu3M=</DigestValue>

</Reference><Reference URI="#Timestamp-b4f998b3-6ed0-4b50-919b-9a15fd64d72d">


</Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>+edo5TI4QIVN67wGXRSB4cbEB1Q=</DigestValue>

</Reference></SignedInfo>

Rules

Release 3.6 3 - 27

<SignatureValue>ywkgMt9s038n3l1FYMZJkAjeuTaYnc+gyGLZobFnqqRsSrxEH+BhwoE77eZVHDQOKwvL21gF+RsT6Zs7A6VonMhE96E9beA3coBjBckwVIBmNH4QJYX1Wbd7DcfAOjpN8U4DlNvtxvmJApZ7uVqWbF85RBtYbq1CwtFiFDXfkF4=</SignatureValue>

<KeyInfo><wsse:SecurityTokenReference xmlns="">

<wsse:Reference URI="#SecurityToken-579dc38e-8990-4b5f-a544-1c1cfb717d1d" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509"/>

</wsse:SecurityTokenReference></KeyInfo>

</Signature></wsse:Security>

</soapenv:Header><soapenv:Body wsu:Id="Body-d4415997-3451-4f0c-bb03-c643f544f240">

<bank:CheckResponseElement><bank:TransactionNum>74494</bank:TransactionNum><bank:CheckNum>23423</bank:CheckNum><bank:CheckType xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/

XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">P</bank:CheckType><bank:PayorAccountID xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/

2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">8458jf8757275234</bank:PayorAccoun-tID>

<bank:Payee xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Elmer Fudd</bank:Payee>

<bank:Amount xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">999.00</bank:Amount>

</bank:CheckResponseElement></soapenv:Body>

</soapenv:Envelope>


3 - 28 Release 3.6

LoggingThis example employs a custom log target, which captures messages generated by the services (such as the Multi-Protocol Gateway, the assigned Processing Policy, and the Front Side Protocol Handlers) handling the SomeBank Checking web services traffic. Here is the configuration display of the custom Log Target object Main page:


Type: syslog

This log target sends captured log messages to a syslog process elsewhere on the network..

Local Identifier: DP

The Local Identifier embedded in the syslog message. Syslog management tools can filter on this value.

Remote Host Address: 10.10.100.3

This is the IP address of the remote syslog utility.Remote Port: 263

The syslog listens on port 263.Syslog Facility: user

The log entries are sent to the syslog with this facility.Backup Log: default-log

Logging

Release 3.6 3 - 29

In the event the syslog facility cannot be reached, this back up log will capture log messages.

Note that when a device is rebooted (as opposed to the firmware reloaded), all temporary files on the filesystem are erased. For this reason, log files are often moved off the device for storage. Using a remote logging utility is a common strategy.





3 - 30 Release 3.6




SSL Communications

Release 3.6 3 - 31

SSL CommunicationsIn this scenario, the communication channels between the DataPower service and the requesting client can use SSL to encrypt communications. The HTTPS Front Side Handler configuration page shows the SSL Proxy used for communications.


SSL Proxy ProfileHere is the configuration of the selected SSL Proxy Profile.

Figure 3 - 24. SSL Proxy Profile Configuration

Direction: reverse

This indicates that this is server rather than a client profile. As such, only a Reverse (Server) Crypto Profile is required.

Reverse (Server) Crypto Profile: SomeBanks

The SomeBanks profile is selected. It is covered in detail in the next section.All other values are left at the default.


3 - 32 Release 3.6

Crypto ProfileHere is the configuration of the Crypto Profile:


Identification Credentials: SomeBanks




All other inputs are set to the default, requiring no configuration action. With SSL enabled, the browsers must use HTTPS rather than HTTP to communicate with the DataPower system.

SSL Communications

Release 3.6 3 - 33

Crypto Identification CredentialsThe SSL Crypto Profile relies upon the Crypto Identification Credential SomeBank. Here is the configuration of the Identification Credential object:




3 - 34 Release 3.6






Validation Credential

Release 3.6 3 - 35


Validation CredentialThe Sign processing action employs a Validation Credential, to verify that the certificate presented by the remote client is valid. Here is the configuration of the Validation Credential used.

Figure 3 - 29. Validation Credential Configuration

Note that this uses the same SomeBanks certificate object as is used in SSL communications. This is not often the case; the Validation Credential would use a different certificate.


3 - 36 Release 3.6

4 - 1

Chapter 4Example Web Application Firewall

This example configuration implements a Web Application Firewall protecting a human resources web portal benefits administration service, allowing employees to request services from human resources through a web browser interface. Because the back end service also supports a Web Services endpoint (XML over HTTP), the Web Application Firewall also handles XML traffic. The Web Application Firewall service consists of the following component objects.Web Application Firewall

The top level service that provides a range of proxy and security services to web-based applications. Web browser clients connect directly to this firewall, rather than the real back end service. References an Application Security Policy.

Application Security PolicyEstablishes the security policy to enforce. References Web Request Profile, Web Response Profile and Error Policy.

Error Policy Establishes a policy for handling errors. In this example, custom error messages are returned to the browser client.

Web Request ProfileEstablishes a profile, or policy, providing content filtering, rate limiting, error handling and other security services for requests originating from Web clients. References Error Policy, Rate Limiter and Name-Value Profile objects.

Web Response ProfileEstablishes a profile, or policy, providing filtering, error handling and other security services for responses originating from Web application servers. References Error Policy object.

Session Management PolicyEstablishes session management. Not used in this example.

Rate Limiter Limits request traffic rates.Name-Value Profile Enforces filters on URL-encoded name-value pairs, such as Query String

parameters, URL-encoded HTTP Post body content, or HTTP headers.

Example Web Application Firewall

4 - 2 Release 3.6

Web Application FirewallThis Web Application Firewall offers:

• Destination Service Proxy, masking back end resources • Rate Limiting, preventing Denial of Service attacks• URL-Encoded Name-Value Input Processing, protecting against malicious or spooked

content posting• HTTP Protocol Filtering, removing unwanted or dangerous headers• Threat Protection, such as SQL Injection filtering, protecting the back end database

system• Error Handling, returning a custom error message when needed• XML Content Processing and Dynamic Routing• SSL Termination and Instantiation

Figure 4 - 1. Web Application Firewall Configuration (partial)

Configuration Values

Name XycoHRThis is a unique name for this object.

SSL Proxy Profile XycoMultiSvcCommunications with the back end server will employ SSL in accordance with the configured Profile. The profile specifies the Cryptographic Keys and Certificates used to negotiate SSL connections. If this field had been left

Web Application Firewall

Release 3.6 4 - 3

blank, the Firewall would not use SSL to communicate with the back end service.

XML Manager defaultAn XML Manager manages the compilation and caching of XSL stylesheets, the caching of XML documents, and provides configuration constraints on the size and parsing depth of XML documents. A default Manager is used if you do not create one. Because this Web Application Firewall does handle XML traffic, the selection of an XML Manager could change the handling of XML requests. A Web Application Firewall that does not handle XML content would not be affected by the XML Manager selected.

Error Policy noneIf any part of the Application Security Policy selected below is violated, the service will handle the violation, or error, in accordance with the rules set forth in the selected Error Policy. This is the default policy that will handle the response sent to the client. An Application Security Policy can also establish an Error Policy; the Error Policy established by the Application Security Policy overrides this default selection. In the case of this service, Error Handling policies are set within the Security Policy, for greater control of execution.

Security Policy XycoHRThis is the security policy enforced by this firewall. See Application Security Policy in this chapter for more information. Note that this is required.

Back Side SettingsRemote Host 10.10.36.11

The name or IP address of the web application (backend) server. All requests handled by this service will be forwarded to this address, unless an error occurs or rate limiting policies do not allow forwarding. When XML traffic is submitted to this Web Application Firewall, the remote host is dynamically determined by the operation requsted.

Remote Port 2085The TCP port number of the web application (backend) server. All requests handled by this service will be forwarded to this port, unless an error occurs or rate limiting policies do not allow forwarding. When XML traffic is submitted to this Web Application Firewall, the remote port is dynamically determined by the operation requsted.

Source AddressesLocal IP Address 0.0.0.0

The address on which the service listens. The default of 0.0.0.0 indicates that the service is active on all addresses.

Port Number 3011An integer (within the range 1 through 65535, with a default of 80) that specifies the port monitored by the Firewall.


4 - 4 Release 3.6

SSL OnThe service will act as an SSL server for client communications and employ the SSL Proxy Profile configured for the service to handle these communications.Note that the SSL Proxy Profile is configured to handle both Forward and Reverse SSL connections. Because of this, the entire end-to-end transaction is conducted with SSL protection.

Application Security PolicyAn Application Security Policy establishes the rules used to enforce security for a Web Application Firewall service. This policy employs Request Maps, Response Maps, and Error Maps. Each of these maps, in turn, matches a Web Request Profile, Web Response Profile, or Error Policy, as the case may be, to client requests based on a set of matching criteria. The Profiles selected then provide the detailed security configuration.

Figure 4 - 2. Application Security Policy Main Configuration Page

Inputs

Name XycoHRThis is the name that appears in all Policy listings.

Request MapsRequest Maps select Web Request Profiles to execute on client requests based on a set of matching criteria. If the client request meets the matching criteria, the corresponding Web Request Profile executes. At least one Request Map entry is required. This Security Policy employs two Request Profiles, one for standard HTML forms input originating from a browser, and one for XML traffic submitted by a Web Services client.

Application Security Policy

Release 3.6 4 - 5

Figure 4 - 3. Request Map configuration

Configuration ValuesMatch:Profile HTMLForms:Xyco-form-request

The match rule HTMLForms selects requests for handling by the corresponding Xyco-form-request Web Request Profile. The HTMLForms Match Rule is configured as follows:

Figure 4 - 4. HTMLForms Match Rule configuration

All requests with the URI /forms will be handled by the Xyco-form-request Request map. The configuration of the Web Request Profile is covered in detail below.

Match:Profile services:XycoHR-xml

The match rule services selects requests for handling by the corresponding XycoHR-xml Web Request Profile. The services Match Rule is configured as follows:


4 - 6 Release 3.6

Figure 4 - 5. services Match Rule Configuration

All requests with the URI /services will be handled by the XycoHR-xml Request Profile. The configuration of the Web Request Profile is covered in detail below.

Response MapsResponse Maps select Web Response Profiles to execute on server responses based on a set of matching criteria. If the server response meets the matching criteria, the corresponding Web Response Profile executes. At least one Response Map entry is required. In this case, all responses are handled by a single Response Profile.

Figure 4 - 6. Application Security Policy Response Maps

InputsMatch:Profile Any:Xyco-form-response

The match rule Any selects requests for handling by the corresponding Xyco-form-response Web Response Profile. The Any Match Rule is configured as follows:


Release 3.6 4 - 7

Figure 4 - 7. Any Match Rule configuration

All responses will be handled by the Xyco-form-response Response Profile. The configuration of the Web Response Profile is covered in detail below.

Error MapsError Maps select a Processing Rule to execute on errors based on a set of matching criteria. If the error meets the matching criteria, the corresponding Processing Rule executes. In this case, the Security Policy uses one Error Rule to handle HTML Forms submissions from a browser and another rule to handle XML content submitted from a Web Services client.

Figure 4 - 8. Error Map Configuration

Configuration ValuesMatch:Rule HTMLForms:WAFW-custom-error

The HTMLForms Match rule (covered above) selects errors for processing by the WAFW-custom-error Processing Rule.Here is the configuration of the WAFW-custom-error Processing Rule.


4 - 8 Release 3.6

Figure 4 - 9. Processing Rule Configuration

This rule executes two Actions. First the Rule executes the WAFW-error-headers action, which resets the HTTP Error Response code to 200, rather than 500. This causes the browser to display the custom error page, rather than the browser’s default 500 page.

Figure 4 - 10. WAFW-error-headers Configuration

Release 3.6 4 - 9

The second action constructs the HTML sent to the browser for display in the event of an error.

Figure 4 - 11. wafw-error-return Action Configuration

Here is the stylesheet used to generate the error message sent to the browser:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig">

<xsl:output method="html" version="1.0"/><xsl:template match="/">

<html><head><title>Portal Error Encountered</title></head>

<body><p>The server has encountered some difficulty returning the requested page. If you are receiving this message, it is likely that you:<ul><li>Mistyped the input</li><li>Let your session expire</li><li>Have not established the required SSL connection</li></ul></p>

<p>


</p></body>


4 - 10 Release 3.6

</html></xsl:template>

</xsl:stylesheet>

Match:Rule services:WAFW-soap-fault

The Match Rule services selects errors for processing by the WAFW-soap-fault Processing Rule. The Match Rule configuration is shown above. This URL is used by Web Services clients submitting XML requests to the portal.Here is the configuration of the Processing Rule:

Figure 4 - 12. WAFW-soap-fault Processing Rule Configuration

This rule executes one Action to create a custom error return to Web Services agents.Here is the configuraton of the WAFW-soap-fault action.

Release 3.6 4 - 11

Figure 4 - 13. WAFW-soap-fault Action Configuration

Here is the stylesheet executed by this Action to produce the error returned to the calling agent.

<?xml version="1.0" encoding="utf-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig">




<env:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

<env:Body><env:Fault>

<xsl:variable name="err" select="dp:variable('var://service/transaction-id')"/><env:faultcode>

<xsl:value-of select="$err"/></env:faultcode><env:faultstring>Invalid web services submission. Please submit a valid request or notify your

network administrator of this error and reference the faultcode number.</env:faultstring></env:Fault>

</env:Body></env:Envelope>


4 - 12 Release 3.6

Error PolicyA Web Application Firewall service can employ an Error Policy to handle errors returned by the back end service. An Error Policy can take action on the error, changing the error response received by the requesting client. This Firewall uses no Error Policy at the Firewall level.

Web Request ProfilesThis Web Application Firewall employs two Web Request Profiles to provide security. Each will be examined in detail here.

HTML Form RequestsThe WAFW-form-request Profile handles content posted from a form by a Web browser.

Figure 4 - 14. Main Profile Configuration

Configuration ValuesStyle admission

This is an admission style Profile. The requirements of this Profile must be met or the request does not pass through to the back end.

Web Request Profiles

Release 3.6 4 - 13

Figure 4 - 15. Request Profile Configuration

Allow SSL allow

This Request Profile will allow SSL communications. Because the Source Addresses for the Web Application Firewall are set to require SSL, this value must be at least allow.

AAA Policy none

No Authentication and Authorization is enforced by this Firewall.Rate Limiting RateShaper

The RateShaper Rate Limiting object is selected to provide rate limiting of requests to this Firewall. The configuration of the Rate Limiting object is covered in greater detail below.

Access Control List none

No restrictions by IP address are applied.Error Policy none

No Error Policy is applied at this level. Note that the Application Security Policy does include Error Maps.

Session Policy none

This relatively simple Benefits service requires no session handling.Content-Type List various

HTTP requests from browsers will be restricted to the two Content Types listed. Any other Content-Type will result in the rejection of the request by the Firewall.


4 - 14 Release 3.6

Figure 4 - 16. Request Profile HTTP Methods Configuration

Methods Various

The checkboxes establish the HTTP Methods allowed to pass to the back end service by this Firewall. The standard defaults (POST, GET, HEAD) are left in place.

Versions Various

Both HTTP/1.0 and HTTP/1.1 are supported by the back end service, so both are allowed by this Request Profile. This is the default.

Figure 4 - 17. Name Value Configuration

Header Name Value Profile HeaderFilter

The names and values of HTTP headers will be evaluated in accordance with the HeaderFilter Name Value Profile. This provides security for malicious HTTP headers. The configuration of the Name Value Profile is covered in detail under Name Value Profiles below.


Release 3.6 4 - 15

URL-Encoded Body Name-Value Profile XycoPost

The URL-Encoded Post body contents will be evaluated in accordance with the XycoPost Name Value Profile. This provides security for malicious body content. The configuration of the Name Value Profile is covered in detail under Name Value Profiles below.

Allow Query String deny

Query strings in the URL are not allowed. The presence of a Query String (something after a ? in the URL) will cause the entire request to be rejected. This is done to protect the back end system from attempting to consume a malicioius Query String.

Figure 4 - 18. Cookie Configuration

Allow Cookies deny

Cookies will be rejected by this Profile. Requests containing cookies will be rejected completely, to protect the back end system from malicious content.

Figure 4 - 19. Threat Protection Configuration


4 - 16 Release 3.6

SQL Injection FilteronThis value is set to on (rather than the default off) to cause the Firewall to scan all inbound values for SQL Injection threats (such as a form input that resembles the string ‘select * from table). All other default values are left in place, to provide the standard threat protection.

XML-Based RequestsThe XycoHR-xml Profile handles XML content posted by a Web Services client.

Figure 4 - 20. Main Profile Configuration

Configuration ValuesStyle admission

This is an admission style Profile. The requirements of this Profile must be met or the request does not pass through to the back end.

Figure 4 - 21. Request Profile Configuration


Release 3.6 4 - 17

Allow SSL allow

This Request Profile will allow SSL communications. Because the Source Addresses for the Web Application Firewall are set to require SSL, this value must be at least allow.

AAA Policy none

No Authentication and Authorization is enforced by this Firewall.Rate Limiting RateShaper

The RateShaper Rate Limiting object is selected to provide rate limiting of requests to this Firewall. The configuration of the Rate Limiting object is covered in greater detail below.

Access Control List none

No restrictions by IP address are applied.Error Policy none

No Error Policy is applied at this level. Note that the Application Security Policy does include Error Maps.

Session Policy none

This relatively simple Benefits service requires no session handling.Content-Type List text/xml

Only requests with Content-Type of text/xml will be allowed. Any other Content-Type will result in the rejection of the request by the Firewall. This protects the Web Services endpoint from inadvertent (or malicious) posts from browsers and eliminates the possibility of attachments.

Figure 4 - 22. Request Profile HTTP Methods Configuration

Methods Various

The checkboxes establish the HTTP Methods allowed to pass to the back end service by this Firewall. The standard defaults (POST, GET, HEAD) are left in place.


4 - 18 Release 3.6

Versions Various

Both HTTP/1.0 and HTTP/1.1 are supported by the back end service, so both are allowed by this Request Profile. This is the default.

Figure 4 - 23. Processing Configuration

XML Processing Well Formed XML

When the submission contains XML, the content will be checked for well-formedness. In addition, the XML Transformation Rule selected will run against the submitted request.

XML Transformation Rule XycoHRWeb_Rule_0

This rule applies a series of filters and an Authentication and Authorization policy to the request content. See the section in this Guide entitled Rules in the Scenario A: Web Services section of the Human Resources Web Portal chapter of this Guide for more information about this Rule. Note that this is a fully featured standard Processing Rule using a number of actions to provide the kind of security that an XML Firewall might provide.


Header Name Value Profile HeaderFilter

The names and values of HTTP headers will be evaluated in accordance with the HeaderFilter Name Value Profile. This provides security for malicious HTTP headers. The configuration of the Name Value Profile is covered in detail under Name Value Profiles below.


Release 3.6 4 - 19

URL-Encoded Body Name-Value Profile none

This Request Profile uses no Name Value Profile to evaluate HTTP Post body content, in large part because the body is XML and not URL-Encoded, because the content is not being posted by a browser.

Allow Query String deny

Query strings in the URL are not allowed. The presence of a Query String (something after a ? in the URL) will cause the entire request to be rejected. This is done to protect the back end system from attempting to consume a malicioius Query String.

Figure 4 - 25. Cookie Configuration

Allow Cookies deny

Cookies will be rejected by this Profile. Requests containing cookies will be rejected completely, to protect the back end system from malicious content.


SQL Injection FilteronThis value is set to on (rather than the default off) to cause the Firewall to scan all inbound values for SQL Injection threats (such as a form input that


4 - 20 Release 3.6

resembles the string ‘select * from table). All other default values are left in place, to provide the standard threat protection.

Web Response ProfileA Web Response Profile establishes the security policy applied to responses returned from application servers. This Security Policy uses one Response Profile to handle all responses, regardless of calling client (browser or Web Services client). This Web Response Profile does the following:

• Filter HTTP Methods• Filter HTTP header values• Provide Service Threat Protection, by managing response sizes

Configuration ValuesName Xyco-form-response

This name appears in the catalog listing and in all drop down lists of available Web Response Profiles.

Style admissionAll responses must pass the evaluations applied by this Profile or the transaction will be aborted by the Firewall.

Web Response Profile

Release 3.6 4 - 21

Figure 4 - 27. Response Profile Configuration

Error Policy noneErrors generated by the Response are not handled by this profile. Any Error conditions sent by the back end services are passed through to the calling client.

Content-Type List .*

All Content-Types will be allowed by this Response Profile. This is done because the back end application generates known Types.

Figure 4 - 28. Codes and Versions Configuration

Response Codes Defaults + Server Error

The ability to pass the Server Error (HTTP 500) Response Code is added to the default Response Codes allowed by the Firewall.


Header Name Value Profile Suppressor

The Suppressor Name Value Profile is used to control HTTP Headers passed back to the calling client. The configuration of this Profile is covered in detail below.


Min Max Sizes defaults

The default values are used for Threat Protection. An empty response will not be passed to the calling client, nor a very large response.

Rate Limiter

Release 3.6 4 - 23

Rate LimiterA Rate Limiter object establishes policies used to control the rate at which requests are received by a Web Application Firewall. When the rate exceeds the limits set, the Limiter can reject requests, post notification or shape, or delay traffic to remain within the limits set. A Rate Limiter object is used by a Web Request Profile.

Inputs

Name RateShaperThis is the name that appears in all catalog lists and Rate Limiter drop down lists.

Rate 20This Limiter will allow only 20 transactions per second from any single distinct user (determined by IP Address) Because the service is not used very often, and because browser clients should actually only use the service perhaps once a day, this number is set artificially low.

Enforcement Style shapeDelay requests as much as possible to lower the transaction rate to the configured limit. Once too many messages are buffered, creating a low memory state, transactions are rejected until rate drops. The ability to shape transactions is limited when concurrent connections are high.

Concurrent Connections

The number of simultaneous connections allowed per user. Set to 0 to disable this enforcement. A single client may not instantiate any concurrent connections. This is to prevent denial of service attacks.


4 - 24 Release 3.6

Name Value ProfileWeb applications communicate with clients using the various mechanisms of the HTTP protocol. The protocol provides for HTTP headers, cookie values, url-encoded query strings, and url-encoded request messages. Each of these kinds of communication mechanisms operate using a string of name-value pairs (such as token=valueA&token1=valueB&broken=bomb). To provide integrity and security for such an application, it is necessary to inspect and take action on these names and values. A Name Value Profile provides a means to implement this inspection and action configuration.A Name Value Profile filters names, and for names that match a given expression, sets constraints on the corresponding values, again expressed as a match expression. The Name Value Profile works by comparing each name in a Name Value pair to all entries in a configured Validation List. If a match is found, the corresponding value is compared to a corresponding match expression. If a match is found, the pair passes. If no match is found, one of several actions is taken.For example, given the URL-encoded string “token=valueA&token1=valueB&broken=bomb”, only names that contain the substring “token” will be accepted, and those that are accepted must have a value that contains the string “value”. The Name Value Pair with a name of “broken” can optionally be passed through, stripped from the string or replaced with a known value, or the entire string can be rejected (in which case, the profile will fail to pass).This Web Application Firewall uses several Name Value Profiles to enforce security.

HeaderFilter Profile

Figure 4 - 31. HeaderFilter General Configuration

Configuration ValuesNo Match Policy Passthrough

This Profile is configured to pass any unmatched Name Value pairs evaluated by this profile through to the back end service. This allows custom headers to pass through to the back end.

Name Value Profile

Release 3.6 4 - 25

Figure 4 - 32. Name Value Profile Configuration Page

Figure 4 - 33. Validation Entry Configuration

Name Expression ^X-(.*)$ Any Header Name that begins with the characters “X-”, followed by any string of characters, will be matched.

Value Constraint ^[a-zA-Z0-9]+$ Headers that match the above expression must have a value that begins with either a capital or small letter alphabetic character or a number.

Failure Policy stripIf the Name Value pair does not match the Value Constraint, the pair is stripped from the request.

Name Expression ^Y-(.*)$ Any Header Name that begins with the characters “Y-”, followed by any string of characters, will be matched.

Value Constraint (.*)-(.*) Headers that match the above expression must have a value that includes a - character.

Failure Policy set


4 - 26 Release 3.6

If the Name Value pair does not match the Value Constraint, the value of the matching header is set to “BogieAlert”. The back end application knows that if this value appears in the headers that the request is bogus and a tracing process is set in motion.

Suppressor Profile

Figure 4 - 34. HeaderFilter General Configuration

Configuration ValuesNo Match Policy strip

This Profile is configured to strip any unmatched Name Value pairs evaluated by this profile from the response from the back end service. This prevents man-in-the-middle hijacking of the client, leading to subsequent phishing attacks.


Name Value Profile

Release 3.6 4 - 27

Figure 4 - 36. Validation Entry Configuration

Name Expression Host Any Header Name that contains “Host” will be matched.

Value Constraint unlikely

Headers that match the above expression must contain the string “unlikely” or the failure policy is executed.

Failure Policy stripIf the Name Value pair does not match the Value Constraint, the pair is stripped from the request.

Name Expression Server Any Header Name that contains “Server” will be matched.



Failure Policy error

If the Name Value pair does not match the Value Constraint, the Response Profile throws an error for consumption by the Security Policy.

Name Expression Warning Any Header Name that contains “Warning” will be matched.


4 - 28 Release 3.6



Failure Policy strip

If the Name Value pair does not match the Value Constraint, the pair is stripped from the request.

XycoPost Profile

Figure 4 - 37. XycoPost General Configuration

Configuration ValuesNo Match Policy strip

This Profile is configured to strip any unmatched Name Value pairs evaluated by this profile from the response from the back end service. This prevents attempts to add fields to the inbound form.


Name Value Profile

Release 3.6 4 - 29

Name Expression Date Any Header Name that contains “Date” will be matched.

Value Constraint ^\d{1,2}(.*)\d{1,2}\1\d{4}$

The values corresponding to the Name Expression must conform to the above date format expression or the failure policy is executed.


If the Name Value pair does not match the Value Constraint, an error is generated, to be handled by the Security Policy Error Map.

Name Expression Department, ID and Password Header Names that contains the Name Expression will be matched.

Value Constraint .*

The value cannot be null (empty) or the failure policy will execute.Failure Policy error


Name Expressions Name and Service Header Names that contains the Name Expression will be matched.

Value Constraint ^[a-zA-Z]+$ The value must begin with an alphabetic character (small or capital) or the failure policy will execute.




4 - 30 Release 3.6

5 - 1

Chapter 5SOAP with Attachments

This example configuration demonstrates a number of different methods for handling SOAP messages that include attachments (SwA). The Firewall service performs any one of the following manipulations on attachments:

• Send stripped attachment to third party agent, return message without attachments.• Process root SOAP XML document using attached XSL• Return the binary attachment• Attach a requested file to the message and return SOAP with Attachment package• Sign a message with attachments• Verify signature of a signed message with attachments• Strip attachment, place in zip file, add external file to zip, return SOAP with zip attached• Extract and return a file from an attached zip file• Pass a DIME-formatted message through the firewall

The firewall service is configured as a loopback proxy; the service returns the results of the manipulation of the SwA message directly to the calling client without involving a back end server.

SOAP with Attachments

5 - 2 Release 3.6

XML FirewallThe XML Firewall Service configuration page appears as shown here.


These are the field values.Firewall Name: Attachments


Firewall Type: Loopback proxy

The firewall returns the result of any policy processing directly to the client. No back end server is involved.


The default is left in place. Firewall Policy: Tache

The custom policy built for this service, Tache, is selected. This policy is covered in detail below.



XML Firewall

Release 3.6 5 - 3

Back EndResponse Attachments: Strip




Device Port: 2071

The automatically assigned value of 2071 is used. This could be altered to any value not used by another service on the current device. All traffic bound for this service must use port number 2071. The SOAP HTTP URL resembles http://10.10.13.35:2071/strip.

SSL Server Crypto Profile: None

Communication with the front end clients will not employ SSL. Request Type: SOAP


Request Attachments : Allow

Attachments are allowed. This setting must be changed from the default (strip) or the firewall will remove the attachments to the message automatically.

There are no monitors configured for this demonstration firewall.


5 - 4 Release 3.6


Figure 5 - 2. Tache Firewall Policy






Firewall Policy

Release 3.6 5 - 5

Rules

OverviewHere is an overview of the rules used in this policy.Rule 1 Two Way Rule Matching */strip


1 Fetch the binary attachment from the message2 Send the attachment to a third party agent3 Strip off attachments4 Return the message without attachments

Rule 2 Two Way Rule Matching */procloadThis rule runs when the client sends the matching URL. The rule performs the following actions:

1 Fetch the text attachment from the message2 Strip off the attachment3) Transform the root message with the XSL instructions

captured from the attachment and return the transformed message

Rule 3 Two Way Rule Matching */returnattachThis rule runs when the client sends the matching URL. The rule performs the following actions:

1 Fetch the binary attachment2 Return the binary attachment

Rule 4 Two Way Rule Matching */cliponThis rule runs when the client sends the matching URL. The rule performs the following actions:

1 Fetch an image file from an external location2 Attach the image file to the submitted XML document3 Return the original message with the attachment

Rule 5 Two Way Rule Matching */signThis rule runs when the client sends the matching URL. The rule performs the following actions:

1 Sign the message with attachments2 Return the signed message with attachments

Rule 6 Two Way Rule Matching */verifyThis rule runs when the client sends the matching URL. The rule performs the following actions:

1 Verify the signature of the signed message with attachments2) Return the verified message


5 - 6 Release 3.6

Rule 7 Two Way Rule Matching */zipupThis rule runs when the client sends the matching URL. The rule performs the following actions:

1 Fetch the binary attachment from the message2) Strip off the attachment3)Insert the fetched attachment into a zip archive and attach it to the

message4)Fetch an additional binary file from an external source5)Insert the fetched file into the zip archive created above6)Return the message with the zip file attached

Rule 8 Two Way Rule Matching */zipoutThis rule runs when the client sends the matching URL. The rule performs the following actions:

1 Fetch a file from inside the zip archive attached to the message

2) Return the extracted file.Rule 9 Two Way Rule Matching */passdime


1 Set the value of the var://local/_extension/attachment-format variable to application/dime to enable pass through of DIME messages

2) Pass through the DIME message.

Firewall Policy

Release 3.6 5 - 7

Rule #1: Two Way RuleThis rule relies upon the existence, in the submitted message, of an attachment with the Content-ID of bin. Here is an example message (docwsnd.swa) suited to this rule:

--MIME_boundaryContent-Type: text/xml; charset=UTF-8Content-Transfer-Encoding: 8bitContent-ID: <main>

<?xml version='1.0' ?><SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><sndt:soundtrack xmlns:sndt="http://schemas.sndpups.com/soundtracks"><sndt:name>Madrid Race 5 announcer</sndt:name><sndt:desc>BeneBene rounds the final turn and wins by one length</sndt:desc></sndt:soundtrack></SOAP-ENV:Body></SOAP-ENV:Envelope>

--MIME_boundaryContent-Type: audio/mpegContent-Transfer-Encoding: binaryContent-ID: <bin>

{binary content omitted}--MIME_boundary--

Match Rule: stripA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 5 - 3. strip Match Rule Configuration

The client must use the URL */strip or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”


5 - 8 Release 3.6

Action 0: Implied ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it.Action 1: FetchThe first custom action of Rule 1 fetches the binary attachment from the SwA message. Here is the configuration of this action:

Figure 5 - 4. Fetch Configuration

Source: cid:bin

A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL cid:bin indicates that the target of the fetch is the message attachment with the Content-ID of bin. Refer to the example message above.

Output: fresult

This is set to fresult. This context will contain the binary attachment. Action 2: Results AsynchThis action sends the contents of a named context (fresult) to a destination. The send is asynchronous; the rule does not wait for a result of the action to continue executing. Here is the configuration display for this action:

Figure 5 - 5. Results Asynch Configuration

Firewall Policy

Release 3.6 5 - 9

Input: fresult

This is set to fresult, the named context used by the preceeding action. This context contains the binary attachment data.

Send Results Asynchronously: On

This setting causes the system to send the contents of the named input context to the Destination given. Processing of the rule continues without waiting for any kind of result of this action. It can, for example, fail with no impact on the execution of the rule.

Destination: http://myhost.mydomain.com:1111

The content will be send to the URL given.

There is no Output context for this action because there is no result.Action 3: Strip AttachmentsThis action strips off all attachments from the message. Here is the configuration display for this action:

Figure 5 - 6. Strip Attachment Configuration

Input: INPUT

This is set to INPUT, the special context that contains the original message.Attachment URI: blank

This input is left blank. This indicates that all attachments are removed from the SwA message. Once removed, the attachments cannot be again retrieved.

This action has no Output context because it returns nothing. It operates only on the Input context.


5 - 10 Release 3.6

Action 4: TransformThis tranform action serves to connect the last context that contained the possibly altered message to any actions that follow. The policy configuration page automatically created this action. Here is the configuration page display for this action.


Input: INPUT

This is set to INPUT, the special context containing the original message. Note that the Strip Attachments action has altered this message by removing the attachments.





Output OUTPUT

This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is returned to the client. In this case, it is the original message without attachments.

Firewall Policy

Release 3.6 5 - 11

Rule #2: Two Way RuleThis rule relies upon the existence, in the submitted message, of an attachment with the Content-ID of xsl. The contents of the attachment are used to transform the root part of the message. Here is an example message (orderform.swa) suited to this rule:

--MIME_boundaryContent-type: text/xml; charset=UTF-8Transfer-Encoding: 8bitContent-ID: <order>

<?xml version='1.0' ?><SOAP-ENV:EnvelopeSOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><cbc:Order xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0" xmlns:cur="urn:oasis:names:specification:ubl:schema:xsd:CurrencyCode-1.0" xmlns:cac="urn:oasis:names:specifica-tion:ubl:schema:xsd:CommonAggregateComponents-1.0">

<cbc:BuyersID>20031234-1</cbc:BuyersID><cbc:IssueDate>2003-01-23</cbc:IssueDate><cbc:LineExtensionTotalAmount amountCurrencyCodeListVersionID="0.3" amountCurren-

cyID="USD">438.50</cbc:LineExtensionTotalAmount><cac:BuyerParty>{omitted content}</cac:BuyerParty><cac:SellerParty>

{omitted content}</cac:SellerParty>{omitted content}<cac:OrderLine>

{omitted content}<cac:LineItem>

<cac:BuyersID>7</cac:BuyersID><cbc:Quantity quantityUnitCode="UNIT">12</cbc:Quantity><cbc:LineExtensionAmount amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">6.00</

cbc:LineExtensionAmount><cac:Item>

<cbc:Description>Mousepad, blue</cbc:Description><cac:SellersItemIdentification>

<cac:ID>21457-3</cac:ID></cac:SellersItemIdentification><cac:BasePrice>

<cbc:PriceAmount amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">.50</cbc:PriceAmount>

</cac:BasePrice></cac:Item>

</cac:LineItem></cac:OrderLine>

</cbc:Order></SOAP-ENV:Body></SOAP-ENV:Envelope>

--MIME_boundaryContent-type: text/xml; charset=UTF-8Transfer-Encoding: 8bitContent-ID: <xsl>

<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/


5 - 12 Release 3.6

extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig">


<joe:Order xmlns:joe="http://schemas.joes.com/schemas"><joe:OrderNo>25</joe:OrderNo><joe:OrderDate>

<xsl:value-of select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='Order']/*[local-name()='IssueDate']"/>

</joe:OrderDate><joe:BuyerID>

<xsl:value-of select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='Order']/*[local-name()='BuyersID']"/>

</joe:BuyerID><xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='Order']/

*[local-name()='BuyerParty']"/><xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='Order']/

*[local-name()='Delivery']"/><joe:Items>

<xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='Order']/*[local-name()='OrderLine']/*[local-name()='LineItem']"/>

</joe:Items></joe:Order>

</xsl:template>{omitted content}

</xsl:stylesheet>

--MIME_boundary--

Match Rule: procloadA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 5 - 8. procload Match Rule Configuration

The client must use the URL */procload or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”

Firewall Policy

Release 3.6 5 - 13

Action 0: Implied ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it.Action 1: FetchThe first custom action of Rule #1 fetches the XSL attachment from the SwA message. Here is the configuration of this action:


Source: cid:xsl

A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL cid:bin indicates that the target of the fetch is the message attachment with the Content-ID of xsl. Refer to the example message above.

Output: proc

This is set to proc. This context will contain the XSL instructions for transforming the root part of the message.

Action 3: Strip AttachmentsThis action strips off all attachments from the message. Here is the configuration display for this action:



5 - 14 Release 3.6

Input: INPUT

This is set to INPUT, the special context that contains the original message.Attachment URI: blank

This input is left blank. This indicates that all attachments are removed from the SwA message. Once removed, the attachments cannot be again retrieved.

This action has no Output context because it returns nothing. It operates only on the Input context.Action 4: TransformThis tranform action uses the XSL taken from the attachment and uses it to transform the root part of the message. Here is the configuration page display for this action.


Input: INPUT

This is set to INPUT, the special context containing the original message. Note that the Strip Attachments action has altered this message by removing the attachments.



Processing Control File: proc

This is set to proc, the name of the context that now contains the XSL instructions.

Output OUTPUT

This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT

Firewall Policy

Release 3.6 5 - 15

context, which is returned to the client. In this case, it is the root part of the message after transformation by the attached XSL.

Here is an example output:<?xml version="1.0" encoding="UTF-8"?><joe:Order xmlns:joe="http://schemas.joes.com/schemas">

<joe:OrderNo>25</joe:OrderNo><joe:OrderDate>2003-01-23</joe:OrderDate><joe:BuyerID>20031234-1</joe:BuyerID><joe:BuyerName>

Microdevices</joe:BuyerName>

<joe:BuyerContact>George Tirebiter</joe:BuyerContact><joe:ShipToAddress>413 N Spring St</joe:ShipToAddress><joe:ShipToCity>Elgin</joe:ShipToCity><joe:ShipToState>IL</joe:ShipToState><joe:ShipToZip>60123</joe:ShipToZip><joe:Items>

<joe:Item><joe:Qty>5</joe:Qty><joe:ProdID>32145-12</joe:ProdID><joe:ProdDesc>Pencils, box #2 red</joe:ProdDesc><joe:ProdUnitPrice amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">2.50</joe:Pro-

dUnitPrice><joe:ItemTotal amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">12.50</joe:ItemTo-

tal></joe:Item>{content omitted}<joe:Item>

<joe:Qty>5</joe:Qty><joe:ProdID>091344-5</joe:ProdID><joe:ProdDesc>Pens, box red felt tip </joe:ProdDesc><joe:ProdUnitPrice amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">5.00</joe:Pro-

dUnitPrice><joe:ItemTotal amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">22.50</joe:ItemTo-

tal></joe:Item><joe:Item>

<joe:Qty>12</joe:Qty><joe:ProdID>21457-3</joe:ProdID><joe:ProdDesc>Mousepad, blue</joe:ProdDesc><joe:ProdUnitPrice amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">.50</joe:ProdUn-

itPrice><joe:ItemTotal amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">6.00</joe:ItemTotal>

</joe:Item></joe:Items>

</joe:Order>


5 - 16 Release 3.6

Rule #3: Two Way RuleThis rule relies upon the existence, in the submitted message, of an attachment with the Content-ID of bin. The contents of the attachment are returned to the client. Match Rule: ReturnAttachA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 5 - 12. ReturnAttach Match Rule Configuration

The client must use the URL */returnattach or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”Action 0: Implied ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it.Action 1: FetchThe first custom action of Rule #1 fetches the attachment from the SwA message. Here is the configuration of this action:


Firewall Policy

Release 3.6 5 - 17

Source: cid:bin

A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL cid:bin indicates that the target of the fetch is the message attachment with the Content-ID of bin.

Output: tache

This is set to tache. This context will contain the content of the attachment. Action 2: ResultThis action returns the contents of the tache context to the client. Here is the configuration display for this action:

Figure 5 - 14. Result Action Configuration

Input: tache

This action takes the context tache as its input. This context contains the content of the attachment.

Send Results Asynchronously: Off

The processing of the rule will wait for this Result action to complete before continuing.

Destination: (blank)

Entering no value for the Destination indicates that the Result action should send the contents of the Input context to the Output context.

Output: (blank)

Entering no value allows the system to determine the appropriate Output context. As this is the last action of the rule, the system will automatically send the content of the Input context to the special OUTPUT context, which is what is sent on the wire back to the client.


5 - 18 Release 3.6

Rule #4: Two Way RuleThis rule fetches additional content from elsewhere and attaches this content to the message as a new attachment. A rule such as this might be used to return requested resources, such as in this SOAP XML message requesting an image:

<?xml version='1.0' ?>

<SOAP-ENV:EnvelopeSOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Body>

<request>Declaration of Independence</request>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

The rule fetches an image of the Declaration of Independence and returns it to the client.Match Rule: cliponA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 5 - 15. clipon Match Rule Configuration

The client must use the URL */clipon or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”Action 0: Implied ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it.

Firewall Policy

Release 3.6 5 - 19

Action 1: FetchThe first action fetches an external resource. Here is the configuration of this action:


Source: local:///declaration.jpg

A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL local:///declaration.jpg indicates that the target of the fetch is a file stored in the local directory system. This could easily be a URL such as http://www.archives.gov/national_archives_ experience/charters/declaration/declaration.jpg.

Output: image

This is set to image. This context will contain the fetched resource. Action 2: ResultThis action attaches the contents of the image context to the message. Here is the configuration display for this action:



5 - 20 Release 3.6

Input: image

This action takes the context image as its input. This context contains the fetched information.



Destination: attachment://INPUT/cid:bin

This attaches the content of the Input context to the INPUT context (the original message)value creates the attachment with the Content-ID of <bin> and attaches.

Output: (blank)

When a Destination is provided, the Output context is ignored.Action 3: ResultThis action sends the Input context to the Output context. The Input context INPUT contains the original message with the attachment added in the previous action. Here is the configuration display for this action:


Input: INPUT

This action takes the special context INPUT as its input. This context contains the original message plus the attachment added in the previous action.



Destination: (blank)

Entering no value for the Destination indicates that the Result action should send the contents of the Input context to the Output context.

Output: (blank)

Entering no value allows the system to determine the appropriate Output context. As this is the last action of the rule, the system will automatically

Firewall Policy

Release 3.6 5 - 21

send the content of the Input context to the special OUTPUT context, which is what is sent on the wire back to the client.

Here is an example of the document returned by this rule:

--67f8c5e9-0c96-4d41-b369-7f0a42d2b83ccontent-type: text/xml

<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><request>Declaration of Independence</request></SOAP-ENV:Body></SOAP-ENV:Envelope>--67f8c5e9-0c96-4d41-b369-7f0a42d2b83cContent-ID: <bin>Content-Transfer-Encoding: binaryContent-Type: application/octet-stream

?JFIFs456h4t645hur8216y

--67f8c5e9-0c96-4d41-b369-7f0a42d2b83c--

Note that the DataPower system has created the MIME boundaries because there were none in the original request. To control these boundary values, submit a SwA message with bounaries included. The DataPower system will use the extant MIME boundary values rather than values it creates.


5 - 22 Release 3.6

Rule #5: Two Way RuleThis rule signs SOAP with Attachment messages.Match Rule: signA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 5 - 19. sign Match Rule Configuration

The client must use the URL */sign or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”Action 0: Implied ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it.

Firewall Policy

Release 3.6 5 - 23

Action 1: SignThis action signs the encrypted response. The configuration display appears as follows.


Input: INPUT

This is the special INPUT context, containing the original SwA message.Envelope Method: WS-Sec


Message Type: SOAP with Attachments

The message and its attachments will be signed.Key: Jefferson

The private cryptographic key contained in the Jefferson key object will be used for the signature.

Certificate: Jefferson

The public cryptographic certificate contained in the Jefferson certificate object will be used for the signature.

Output: OUTPUT

This is the special OUTPUT context, sent back to the client.


5 - 24 Release 3.6

Rule #6: Two Way RuleThis rule verifies the signature on SOAP with Attachment messages.Match Rule: verifyA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.


The client must use the URL */verify or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”Action 0: Implied ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it.Action 1: VerifyA Verify action verifies the signature contained in the message. If the signature cannot be verified, the message is rejected. If the signature is valid, the message passes through the firewall.

Firewall Policy

Release 3.6 5 - 25

Here is the configuration of the Verify action:

Figure 5 - 22. Verify Action Configuration

Input: INPUT


Filter Method: Standard Filter

The Standard Filter just checks the signature for validity.Signer Certificate: (Blank)

This setting causes the system to use the certificate contained in the signature to verify the signature in the message. If this field had a value, it would need to point to the Crypto Certificate object that would be used for verification.


This setting indicates that the system will not perform certificate validation. If this field had a value, it would point to a Crypto Validation Credential object, that in turn would have to include the certificate included in the message to validate that certificate. Additional trust chain checking can also be performed by a Validation Credential object.

Output: (Blank)

This setting indicates that the system will automatically use the correct context in the following actions. A Verify action is a type of filter that only accepts or rejects the message and does not output the contents of the message.


5 - 26 Release 3.6



Input: INPUT

This is set to INPUT, the special context containing the original message. Document Processing Instructions: Specified by rule




Output OUTPUT

This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is returned to the client. In this case, it is the original message with attachments.

Firewall Policy

Release 3.6 5 - 27

Rule #7: Two Way RuleThis rule strips off the binary attachment in the SwA message and creates a new attachment containing a zip archive. The original attachment to the message is placed in this zip archive along with additional content fetched from elsewhere. This rule demonstrates the ability of the DataPower system to manipulate zip archives contained in attachments. A rule such as this might be used to create message archives.Match Rule: zipupA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 5 - 24. zipup Match Rule Configuration

The client must use the URL */zipup or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”Action 0: Implied ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it.


5 - 28 Release 3.6

Action 1: FetchThe first custom action fetches the attachment from the SwA message. Here is the configuration of this action:


Source: cid:bin

A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL cid:bin indicates that the target of the fetch is the message attachment with the Content-ID of bin.

Output: fbin

This is set to fbin. This context will contain the fetched resource. Action 2: Strip AttachmentsThis action strips off all attachments from the message. Here is the configuration display for this action:


Input: INPUT

This is set to INPUT, the special context that contains the original message.Attachment URI: cid:bin

This strips the attachment with the Content-ID of bin from the message. Once removed, the attachments cannot be again retrieved.

This action has no Output context because it returns nothing. It operates only on the Input context.

Firewall Policy

Release 3.6 5 - 29

Action 3: ResultThis action creates a zip archive, inserts the contents of the fbin context into the archive and then attaches the archive to the message. Here is the configuration display for this action:


Input: fbin

This action takes the context fbin as its input. This context contains the fetched information.



Destination: attachment://INPUT/cid:bin?Archive=zip&Filename=order.pdf

This creates the attachment with the Content-ID of <bin>. This attachment is formatted as a zip archive. The contents of the Input context are inserted into the archive as a file named order.pdf.

Output Type: binary

This explicitly declares the content sent by the action as binary (not xml).Output: (blank)

When a Destination is provided, the Output context is ignored.


5 - 30 Release 3.6

Action 4: FetchThis action fetches an additional resource from elsewhere (in this case, the image of a signature) and places it into a context for further use. Here is the configuration of this action:


Source: local:///sig.gif

A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL local:///sig.gif indicates that the target of the fetch is a file stored in the local directory system. This could easily be a URL such as http://sigserver.domain.com/sigs/sig.gif.

Output: fsig

This is set to fsig. This context will contain the fetched resource.

Action 5: ResultThis action inserts the contents of the Input context into the zip archive now contained in the attachment to the message. Here is the configuration display for this action:


Firewall Policy

Release 3.6 5 - 31

Input: fsig

This action takes the context fbin as its input. This context contains the signature image fetched in the previous action.



Destination: attachment://INPUT/cid:bin?Archive=zip&Filename=sig.gif

The contents of the Input context are inserted into the archive as a file named sig.gif.

Output Type: binary

This explicitly declares the content sent by the action as binary (not xml).Output: (blank)

When a Destination is provided, the Output context is ignored. Action 6: TransformThis tranform action serves to connect the last context that contained the possibly altered message to any actions that follow. The policy configuration page automatically created this action. Here is the configuration page display for this action.


Input: INPUT




5 - 32 Release 3.6



Output OUTPUT

This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is returned to the client. In this case, it is the original message with the zip archive replacing the cid:bin attachment.

Rule #8: Two Way RuleThis rule extracts a file from an attached zip archive and returns the file to the client.Match Rule: zipoutA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.

Figure 5 - 31. zipout Match Rule Configuration

The client must use the URL */zipout or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”Action 0: Implied ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it.

Firewall Policy

Release 3.6 5 - 33

Action 1: FetchThis action fetches a file from within the zip archive attached to the message. Here is the configuration of this action:


Source: cid:bin?Archive=zip&Filename=order.pdf

A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL cid:bin?Archive=zip&Filename=order.pdf indicates that the target of the fetch is a file stored within the zip archive attached to the message.

Output: outfile

This is set to outfile. This context will contain the fetched resource. Action 2: ResultThis action returns the file obtained from the zip archive attached to the original message. Here is the configuration display for this action:


Input: outfile

This action takes the context outfile as its input. This context contains the file fetched in the previous action.


5 - 34 Release 3.6



Destination: (blankThe action will send the contents of the Input context to the Output context.

Output: (blank)

When the Output context is set to blank, the system automatically sends the message to the appropriate context. As this is this last action in the rule, the system sends the content to the OUTPUT context, which is sent back immediately to the client. Note that this is not wrapped in SOAP XML.

Rule #9: Two Way RuleThis rule allows DIME messages to pass through the firewall. The firewall, by default, converts DIME to MIME format unless action is taken. The rules demonstrates that action.Match Rule: passdimeA Match Rule examines the inbound message and determines whether or not the rule should be run against the message. In this case, the match rule examines the URL used by the client to determine a match. Here is the configuration display of the match rule maps.


The client must use the URL */passdime or this rule will not be applied to the message. Note that the expression * means “any substring of any characters.”Action 0: Implied ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insure that no message that does not conform to the SOAP schemas will be sent to the back end web service endpoints. This SOAP schema filtering is implied and no action needs to be created for it.Action 1: SetvarA Setvar action sets the value of a variable, for use in subsequent processing. In this case, the action sets the variable that keeps the message in DIME format.

Firewall Policy

Release 3.6 5 - 35

Here is the configuration of the Setvar action:

Figure 5 - 35. Setvar Action Configuration

Input: INPUT


Variable Name: var://local/_extension/attachment-format

The action sets the value of the variable named var://local/_extension/attachment-format. This is a special variable maintained by the system for the purpose of determining the format of attachments.

Variable Value: application/dime

This setting causes the system to format the message according to the DIME protocol. Note that if the original message had been in MIME format, this setting would cause the message to be reformatted, in effect creating a gateway.


5 - 36 Release 3.6



Input: INPUT





Output OUTPUT

This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is returned to the client. In this case, it is the original message with attachments.

Additional Capabilities

Release 3.6 5 - 37

Additional CapabilitiesAdditional capabilities for handling SOAP with Attachment messages are available in the DataPower system. These are:

• Encode archives as Base64• Decode base64-encoded archives• List all attachments• List contents of archives within attachments• Addressing DIME attachments using uuid:

Each are covered in more detail here.

Base64 EncodingAttachments containing archives can be base64 encoded or decoded using the Fetch action. For example, when extracting a file from a base64 encoded archive, the archive can first be decoded, allowing for the file extraction. The Destination property for the Fetch action would resemble the following:cid:bin?Archive=zip&Filename=order.pdf?Decode=base64

Similarly, archives that are not encoded can be base64 encoded using a Fetch Destination such as the following:cid:bin?Archive=zip&Encode=base64

Attachment ManifestIt is possible to access a manifest of all attachments in a given message. This manifest is a nodeset held in the variable var://context/INPUT/attachment-manifest. Here is an example manifest:<?xml version="1.0" encoding="UTF-8"?><manifest>

<package-headers/><root-headers>

<header><name>Content-Type</name><value>text/xml; charset=UTF-8</value>

</header><header>

<name>Content-ID</name><value><main></value>

</header><header>

<name>Content-Transfer-Encoding</name><value>binary</value>

</header></root-headers><media-type>

<value>multipart/related; type="text/xml"; boundary="MIME_boundary"</value><type>multipart</type><sub-type>related</sub-type>

</media-type><attachments>

<attachment>


5 - 38 Release 3.6

<uri>cid:bin</uri><size>13044</size><header>

<name>Content-Type</name><value>audio/mpeg</value>

</header><header>

<name>Content-ID</name><value><bin></value>

</header><header>

<name>Content-Transfer-Encoding</name><value>binary</value>

</header></attachment>

</attachments></manifest>

DIME Attachment AddressingDIME attachments can be addressed using the prefix uuid:, which is typically used in DIME messages. The same attachment may also be addressed using the cid: prefix. For example, both of the following expressions address the same DIME attachment.

uuid:f1e8ef38-b4f6-4991-94fb-3a0b97922901

cid:f1e8ef38-b4f6-4991-94fb-3a0b97922901

Notices-#

Notices

This information was developed for products and services offered in the U.S.A.IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to:IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

TrademarksIBM, DataPower, Domino, Lotus, Tivoli, and WebSphere are registered trademarks of the International Business Machines Corporation in the United States and/or other countries.Internet Explorer, Microsoft, and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others.

Index - 1

Index

A

AAA Policy 2 - 16Action 1

Transform 1 - 45, 1 - 48Validate 1 - 59

Action 2Filter 1 - 60Setvar 1 - 49

Action 3Route 1 - 61Validate 1 - 37

Action 5Transform 1 - 40, 1 - 63

Action 7Transform 1 - 44

Allow Chunked Uploads 3 - 6Application Security Policy 4 - 4

Error Maps 4 - 7Request Maps 4 - 4Response Maps 4 - 6

Application Security PolicyName 4 - 4

B

Back Attachment Processing Format 3 - 4Back End URL 3 - 3

C

Count Monitor 2 - 42Crypto Certificate 1 - 52, 2 - 51, 3 - 34Crypto Identification Credentials 1 - 51, 2 -50, 3 - 33Crypto Key 1 - 51, 2 - 50, 3 - 34Crypto Profile 2 - 49, 3 - 32

D

DIME 5 - 34Document Crypto Map 2 - 23Duration Monitor 1 - 20, 1 - 23, 2 - 42

E

Error Policy 4 - 12Error Rule 1 - 18, 1 - 48Event Subscriptions 1 - 27

F

Firewall Policy 1 - 6, 1 - 32, 1 - 57, 2 - 7,5 - 4Follow Redirects 3 - 6Front Attachment Processing Format 3 - 4Front Side Protocol 3 - 3

H

HTTP Front Side Protocol Handler 3 - 9HTTP Protocol Handler

Local IP Address 4 - 3HTTPS Front Side Protocol Handler 3 - 10

L

Log Target 1 - 25Event Subscriptions 1 - 27, 2 - 47, 3 -

30Object Filters 1 - 26, 2 - 47, 3 - 29

Logging 1 - 25, 2 - 46, 3 - 28Loop Detection 3 - 6

Index - 2 Release 3.6

M

Match 4 - 5Match Rule 1 - 7, 1 - 33, 1 - 58, 1 - 64, 2- 9, 2 - 21, 2 - 25, 2 - 31, 2 - 35, 2 - 39,3 - 17, 3 - 24, 5 - 7, 5 - 12, 5 - 16, 5 -18, 5 - 22, 5 - 24, 5 - 27, 5 - 32, 5 - 34Message Filter Action 1 - 22Message Match 1 - 20Message Monitor 2 - 42Message Type 1 - 21MIME 5 - 34MMDOS 3 - 7Monitors 2 - 42MQ Front Side Protocol Handler 3 - 11Multi-Protocol Gateway 3 - 2Multi-Protocol Gateway Name 3 - 2Multi-Protocol Gateway Policy 3 - 2, 3 - 14Multi-Protocol Gateway Type 3 - 2

N

Name Value Profile 4 - 24

O

Object Filters 1 - 26

P

Port Number 4 - 3Processing Action

AAA 2 - 15Call 1 - 67, 2 - 24Convert-http 1 - 34, 1 - 64Decrypt 2 - 21Encrypt 2 - 32, 2 - 37Fetch 5 - 8, 5 - 13, 5 - 16, 5 - 19, 5

- 28, 5 - 30, 5 - 33Filter 1 - 9, 1 - 38, 2 - 12, 2 - 14, 3 -

20Result 5 - 17, 5 - 19, 5 - 20, 5 - 29,

5 - 30, 5 - 33Results Asynch 5 - 8Route 1 - 12, 1 - 42

Setvar 5 - 34Sign 2 - 33, 3 - 25, 5 - 23Strip Attachments 5 - 9, 5 - 13, 5 - 28Transform 1 - 11, 1 - 13, 1 - 15, 1 -

18, 1 - 34, 1 - 65, 2 - 20, 2- 27, 2 - 40, 3 - 23, 5 - 10,5 - 14, 5 - 26, 5 - 31, 5 - 36

Validate 1 - 8, 2 - 10, 2 - 31, 2 - 36,2 - 39, 3 - 18, 3 - 24

Verify 2 - 26, 3 - 22, 5 - 24Processing Rules 1 - 7, 1 - 33, 1 - 58, 2 - 8,3 - 15, 5 - 5

R

Rate LimiterConcurrent Connections 4 - 23Enforcement Style 4 - 23

Rejected Counter 2 - 19RemoteAddress 4 - 3Request Attachments 3 - 4Request Type 3 - 4Response Attachments 3 - 4Response Type 3 - 4

S

SAML Attribute Assertion 2 - 16, 2 - 18SAML Attributes 2 - 19SAML Signature 2 - 17SQL Injection Attack 2 - 14SSL Client Crypto Profile 3 - 4SSL Communications 2 - 49, 3 - 31SSL Proxy Profile 3 - 31SSL Server Crypto Profile 1 - 50

T

Threat Protection 2 - 6

U

URL Rewrite Policy 3 - 2User Agent Settings 3 - 3

X-Series Device Reference Guide

Release 3.6 1 - 3

V

Validation Credential 3 - 35

W

Web Application FirewallError Policy 4 - 3Local IP Address 4 - 3Name 4 - 2Port Number 4 - 3Remote Host 4 - 3RemotePort 4 - 3Security Policy 4 - 3SSL 4 - 4SSLProxyProfile 4 - 2XMLManager 4 - 3

Web Request Profile 4 - 12Name 4 - 20

Web Response ProfileContent-Type List 4 - 21Error Policy 4 - 21

WS-Security 2 - 32

X

XDOS 3 - 7XML Firewall 2 - 3, 5 - 2XML Firewall Service 1 - 3, 1 - 29, 1 - 54XML Manager 3 - 2XML Threat Protection 2 - 42, 3 - 6XPath Routing Map 1 - 12, 1 - 42, 1 - 62

Z

zip archive 5 - 27, 5 - 32

1 - 4 Release 3.6

xi 3[1].6.0-example configs

Education

request rule

match rule

error rule

implied action

message filter action

xml firewall service

message match

firewall policy1