IBM Software Group
An IBM Proof of Technology
Discovering the Value of IBM WebSphere
DataPower SOA Appliances (Firmware 3.6.1)
Student Workbook
© 2008 IBM Corporation
PoT.WebSphere.08.4.060.05
Document Version Number: 6.0
Document Creation Date: March 28, 2008
Author: Gerry Kaplan, DataPower ITS
Firmware version: 3.6.1
Contributors: Shiu-Fun Poon
Jeffrey Lam
Lou Rivas
James De Luca
Bill Hines
© Copyright International Business Machines Corporation, 2008. All rights reserved.
US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
IBM
Contents
ENVIRONMENT OVERVIEW ...........................................................................................................................5
DATAPOWER FAMILY OVERVIEW ...............................................................................................................7
BEFORE YOU BEGIN....................................................................................................................................15
LAB 1
INTRODUCTION TO THE DATAPOWER WEBGUI .......................................................17
1.1
LOGGING INTO THE WEBGUI ...............................................................................................17
1.2
WEBGUI ORGANIZATION.....................................................................................................18
1.3
DATAPOWER LOGGING .......................................................................................................20
1.4
DATAPOWER’S ON-BOARD FILE SYSTEM .............................................................................22
1.5
SUMMARY ..........................................................................................................................23
LAB 2
XSL ACCELERATION .....................................................................................................25
2.1
SAVING YOUR CHANGES .....................................................................................................29
2.2
SUMMARY ..........................................................................................................................29
LAB 3
WORKING WITH XML MESSAGES AND SCHEMAS ...................................................31
3.1
CREATING AN XML FIREWALL SERVICE ...............................................................................31
3.2
SAVING YOUR CHANGES .....................................................................................................36
3.3
SUMMARY ..........................................................................................................................36
LAB 4
XML THREAT PROTECTION..........................................................................................37
4.1
WHAT IS AN SQL INJECTION THREAT? .................................................................................37
4.2
HOW DOES DATAPOWER PROTECT AGAINST SQL THREATS? ................................................37
4.3
ADDING SQL INJECTION THREAT PROTECTION ....................................................................38
4.4
MALFORMED CONTENT .......................................................................................................42
4.5
ADDITIONAL XML THREAT PROTECTION ..............................................................................42
4.6
SUMMARY ..........................................................................................................................43
LAB 5
TRANSFORMING WITH XSL..........................................................................................45
5.1
ADDING A TRANSFORM ACTION ...........................................................................................45
5.2
SUMMARY ..........................................................................................................................49
LAB 6
WS-SECURITY: DIGITAL SIGNATURES .......................................................................51
6.1
WHAT IS A DIGITAL SIGNATURE? .........................................................................................51
6.2
ADDING A DIGITAL SIGNATURE TO A MESSAGE .....................................................................51
6.3
VERIFYING A DIGITAL SIGNATURE ........................................................................................57
6.4
SUMMARY ..........................................................................................................................60
LAB 7
WS-SECURITY: ENCRYPTION & DECRYPTION ..........................................................61
7.1
ENCRYPTION BASICS ..........................................................................................................61
7.2
ENCRYPTING THE BODY OF THE SOAP MESSAGE .................................................................61
7.3
DECRYPTING THE MESSAGE ................................................................................................63
7.4
FIELD LEVEL ENCRYPTION...................................................................................................65
7.5
WORKING WITH THE TRANSACTION PROBE ...........................................................................66
7.6
SUMMARY ..........................................................................................................................68
LAB 8
AUTHENTICATION AND AUTHORIZATION WITH LDAP.............................................69
8.1
AAA POLICY OVERVIEW......................................................................................................69
8.2
LDAP AUTHENTICATION & AUTHORIZATION .........................................................................70
8.3
ADDING AAA TO YOUR FIREWALL ........................................................................................70
8.4
AAA POST PROCESSING .....................................................................................................74
8.5
SUMMARY ..........................................................................................................................76
LAB 9
CUSTOMIZING AAA WITH XSLT ...................................................................................77
9.1
THE SCENARIO ...................................................................................................................78
9.2
THE CUSTOMIZED SOLUTION ...............................................................................................79
9.3
USING A CUSTOM STYLESHEET FOR AUTHORIZATION ...........................................................80
9.4
SUMMARY ..........................................................................................................................86
LAB 10
AAA WITH XACML (OPTIONAL LAB) ...........................................................................87
10.1
XACML OVERVIEW ............................................................................................................87
Contents
Page 1
IBM
10.2
10.3
10.4
10.5
10.6
LAB 11
11.1
11.2
LAB 12
12.1
12.2
12.3
12.4
LAB 13
13.1
13.2
13.3
13.4
LAB 14
14.1
14.2
LAB 15
15.1
15.2
15.3
15.4
LAB 16
16.1
16.2
16.3
16.4
LAB 17
17.1
17.2
17.3
LAB 18
18.1
18.2
18.3
APPENDIX A.
( A)
( B)
(C)
(D)
( E)
APPENDIX B.
APPENDIX C.
APPENDIX D.
Page 2
THE XACML POLICY DOCUMENT ........................................................................................88
THE XACML AUTHORIZATION REQUEST DOCUMENT ............................................................88
DATAPOWER’S ROLE IN THE XACML STORY .......................................................................89
HOW IT’S DONE ...................................................................................................................89
SUMMARY ..........................................................................................................................95
PROTOCOL LEVEL SECURITY: SSL/HTTPS ...............................................................97
ADDING SSL ......................................................................................................................97
SUMMARY ........................................................................................................................100
PROTECTING WEB SERVICES ...................................................................................101
CREATE THE WS-PROXY SERVICE ....................................................................................101
TESTING THE WEB SERVICE PROXY...................................................................................104
ADDING AAA TO THE WEB SERVICE ..................................................................................105
SUMMARY ........................................................................................................................107
WS-POLICY SUPPORT.................................................................................................109
WS-POLICY OVERVIEW.....................................................................................................109
EXAMPLE 1 – ATTACHING A POLICY ...................................................................................110
EXAMPLE 2: WSDL EMBEDDED WS-POLICY ......................................................................114
SUMMARY ........................................................................................................................119
WEBSPHERE SERVICES REGISTRY AND REPOSITORY INTEGRATION ..............121
UPDATING THE WS-PROXY FOR WEBSPHERE SERVICES REGISTRY AND REPOSITORY ........121
SUMMARY ........................................................................................................................124
PROTOCOL BRIDGING: HTTP TO WEBSPHERE MQ ...............................................125
CREATING THE QUEUE MANAGER OBJECT .........................................................................125
CREATE THE MULTI-PROTOCOL GATEWAY SERVICE ...........................................................126
SUMMARY ........................................................................................................................131
DO YOU STILL HAVE MORE TIME? .......................................................................................131
MULTI-PROTOCOL CONTENT-BASED ROUTING.....................................................133
CREATING THE MULTI-PROTOCOL GATEWAY ......................................................................133
CREATING THE FRONT SIDE HANDLER ...............................................................................134
CREATING THE POLICY ......................................................................................................134
SUMMARY ........................................................................................................................138
PROTOCOL BRIDGING: FTP TO MQ ..........................................................................139
FTP SERVER FRONT SIDE HANDLER (XI50 ONLY) ............................................................139
CREATING THE FTP SERVER FRONT SIDE HANDLER ..........................................................140
SUMMARY ........................................................................................................................142
TRANSFORMING NON-XML PAYLOADS ...................................................................143
UPLOADING THE WEBSPHERE TRANSFORMATION EXTENDER ARTIFACTS ............................143
CREATE A NEW MULTI-PROTOCOL GATEWAY .....................................................................144
SUMMARY ........................................................................................................................153
THE (XML) THREAT IS OUT THERE…........................................................................155
SINGLE MESSAGE XDOS ...................................................................................................156
MULTIPLE MESSAGE XDOS ...............................................................................................156
UNAUTHORIZED ACCESS ...................................................................................................156
DATA INTEGRITY/CONFIDENTIALITY ....................................................................................156
SYSTEMS COMPROMISE ....................................................................................................157
IBM TECHWORKS ........................................................................................................159
NOTICES........................................................................................................................161
TRADEMARKS AND COPYRIGHTS ............................................................................163
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Revision History
Revision 1
Revision 2
Revision 3
Gerry Kaplan
Gerry Kaplan
Gerry Kaplan
August 2007
September 2007
February 2008
Revision 4
Revision 5
Revision 6
Gerry Kaplan
Gerry Kaplan
Gerry Kaplan
March 2008
June 2008
July 2008
Contents
Document created
Integration labs added
Updated for firmware 3.6.1
Added WS-Policy lab
Added XACML lab
Added Custom AAA lab
Added WSRR Lab
Miscellaneous corrections
Miscellaneous corrections
Miscellaneous corrections
Page 3
IBM
Page 4
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Environment Overview
The IBM® WebSphere® DataPower® SOA Appliances Proof of Technology labs are conducted in an
environment consisting of the following:



IBM® DataPower SOA Appliance
o
XI50 can perform all labs in this document
o
XS40 can perform only labs 1 through 14
A VMware virtual machine consisting of the following components (on instructor machine only):
o
Microsoft® Windows® Server 2003 release 2 + current fixpacks
o
IBM WebSphere Application Server 6.1 Network Deployment
o
IBM DB2® v 9.1
o
IBM WebSphere MQ 6.0
o
IBM WebSphere Service Registry and Repository 6.1
o
Apache HTTP Server, version 2.2
o
OpenLDAP for use in the authentication and authorization labs
o
A Java™-based legacy application simulator (for use with MQ labs)
Student workstations, which require:
o
A Web browser such as Internet Explorer or Firefox
o
Curl - a tool used for submitting HTTP and HTTPS requests
o
A simple editor or a command line utility to view XML files
Environment Overview
Page 5
IBM
Page 6
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
DataPower Family Overview
IBM WebSphere DataPower SOA Appliances represent an important element in IBM's holistic approach
to Service Oriented Architecture (SOA). IBM SOA appliances are purpose-built, easy-to-deploy network
devices that simplify, help secure, and accelerate your XML and Web services deployments while
extending your SOA infrastructure. These new appliances offer an innovative, pragmatic approach to
harness the power of SOA while simultaneously enabling you to leverage the value of your existing
application, security, and networking infrastructure investments.
WebSphere DataPower XML Accelerator XA35
As XML adoption within the enterprise increases, the growing number of slow-performing applications
demonstrates that existing overtaxed software systems cannot support next-generation applications.
Enterprises need a platform that addresses XML's performance, security, and management
requirements head-on.
Powered by unique purpose-built technology, IBM WebSphere DataPower XML Accelerator XA35 is a
true network device capable of off-loading overtaxed servers by processing XML, XSD, XPath, and XSLT
at wirespeed. The XA35 ensures that time and capital invested in new applications produce results. The
flexibility of the XA35 allows it to be installed in any number of different locations within the enterprise to
off-load Web and application servers from the arduous task of XML processing.
Features and benefits include:
Dynamic content generation
XML is gaining rapid adoption because it can be repurposed for an endless range of device types and
applications. In practice, dynamically generating content with traditional software results in unacceptable
latency and costs. On demand publishing, wireless device support, and content syndication are all
applications in which the XA35 provides transformation of XML into any format without requiring
expensive and unwieldy infrastructure.
Enablement of high-performance portals
Enterprise portals have quickly become a necessity for sharing information and even applications both
internally and externally. Behind the scenes, XML Web services are the standard for the integration of
DataPower Family Overview
Page 7
IBM
disparate data sets and applications into portal applications. In these environments the XA35 boosts the
number of transactions per second while helping to lower the overall cost and complexity of portal
applications.
Enablement of data and forms processing
Enterprises increasingly aggregate information from a number of sources, including telephone data entry,
facsimile, online form submission, and manual data entry. Using XML and XSLT, enterprises can
automate forms processing and normalize data received from any number of sources.
Wirespeed performance
The purpose-built message processing engine delivers wirespeed performance for both XML to XML and
XML to HTML transformations with increased throughput and decreased latency.
Ease of use
The XA35 provides drop-in acceleration with virtually no changes to the network or application software.
Reduced infrastructure costs
The XA35 fully parses, processes, and transforms XML with wirespeed performance and scalability to
help reduce the need for stacks of servers.
Lower development costs
The XA35 enables multiple applications to leverage a single, uniformed XML processing layer for all XML
processing needs.
Intelligent XML processing
The XA35 supports XML routing, XML pipeline processing, XML compression, XML/XSL caching, as well
as other intelligent processing capabilities to help manage XML traffic.
Advanced management
The XA35 provides real-time visibility into critical XML statistics such as throughput, transaction counts,
errors, and other processing statistics.
Broad management interface support
The XA35 includes WSDM, WSDL-based policy creation, Eclipse/WebSphere Application Studio,
command line interface, SNMP, and SOAP management.
Page 8
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
WebSphere DataPower XML Security Gateway XS40
While there is tremendous business value in SOA and XML Web services, security remains an unsolved
problem and one of the largest single barriers to adoption. Enterprises require a new pragmatic approach
to XML Web services security, one that simultaneously recognizes the uncertainty of new standards, the
value of existing infrastructure investments, the organizational challenges and the performance impact of
XML security.
Because corporations are struggling to deal with resource constraints, diverging business goals, and the
requirement to assimilate new technology, IBM WebSphere DataPower XML Security Gateway XS40 is
a network appliance that is easy to install and maintain, satisfying both application and network groups
while supporting current and pending security standards out-of-the-box.
Features and benefits include:
XML firewall
The XS40 provides protection against XML vulnerabilities by acting as an XML proxy and performing
XML well-formedness checks, buffer overrun checks, XML schema validation, XML filtering, and XDoS
protection. XS40 also includes many essential security functions beyond those of an XML firewall: Web
services access control (AAA), XML Encryption and Digital Signature, WS-Security, and content-based
routing.
XML denial of service protection
A single low-byte XML message can bypass traditional perimeter protection and instantly crash missioncritical applications. The XS40 validates incoming requests and logs malformed and malicious traffic to
provide valuable post-attack forensics.
Field level message security
The XS40 selectively shares information through encryption/decryption and signing/verification of entire
messages or of individual XML fields. These granular and conditional security policies can be based on
nearly any variable, including content, IP address, hostname, or other user-defined filters.
Web services access control
Since the XML Security Gateway is much more than just an XML Firewall; it provides access control
functions which can be used to enable secure access to Web services based applications to both internal
and external clients. Both commercial and standards-based integration is supported, including LDAP,
SAML and WS-Security.
DataPower Family Overview
Page 9
IBM
Fine-grained authorization
Instead of URL-based or connection-level access control, fine-grained authorization allows the XS40 to
interrogate every individual SOAP/XML transaction and determine whether it should be allowed through
based on payload contents, security policy, and identity information. For example, a purchase order that
is (1) over $500, (2) digitally signed by the CFO's certificate, (3) targeted for vendor X, and (4) sent
before 5 p.m. may be allowed through, while one immediately following it would be rejected. SAML, WSSecurity, and XACML are key emerging standards for implementing this kind of fine-grained access
control in an open, cross-platform environment which joins a variety of policy enforcement points (such
as the XS40) and central policy repositories.
Service virtualization
XML Web services require companies to link partners to resources without leaking information about
their location or configuration. With the combined power of URL rewriting, high-performance XSL
transforms and XML/SOAP routing, the XS40 can transparently map a rich set of services to protected
back-end resources with high performance.
Centralized policy management
The XS40's wirespeed performance enables enterprises to centralize security functions in a single dropin device that can enhance security and help reduce ongoing maintenance costs. Simple firewall
functionality can be configured via a GUI and running in minutes, and using the power of XSLT, the XS40
can also create sophisticated security and routing rules. Because the XS40 works with leading Policy
Managers such as IBM Tivoli® Access Manager, is an ideal policy execution engine for securing next
generation applications. Manageable locally or remotely, the XS40 supports SNMP, script-based
configuration, and remote logging to integrate seamlessly with leading management software.
Web services management/service level management
With support for Web Services Distributed Management (WSDM), Universal Description, Discovery, and
Integration (UDDI), Web Services Description Language (WSDL), and Dynamic Discovery, and broad
support for Service Level Management configurations, the XS40 natively offers a robust Web services
management framework for the efficient management of distributed Web service endpoints and proxies
in heterogeneous SOA environments. The XS40 also offers SLM alerts and logging and pull and enforce
policies, which help enable broad integration support for third-party management systems and unified
dashboards, in addition to robust support and enforcement for governance frameworks and policies.
Inter-enterprise application sharing
XML can Internet-enable nearly every enterprise application, driving an instant need for centralized
message filtering and validation. The XS40 can process and validate messages at a central point in realtime so only known-good requests reach valued back-end resources. High-speed message signing and
verification prevents falsified requests and securely logs all transactions.
Secure portal connections
Portal applications tie into high-value back-end databases and application servers, ensuring access
control is paramount. The XS40 supports legacy systems such as RADIUS and LDAP, along with
emerging standards such as Security Assertion Markup Language (SAML) and Extensible Access
Control Markup Language (XACML).
Page 10
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Secure architecture
Powered by robust patented XML processing technology built from the ground up to be secure, the XS40
can help to enable full XML Security with the wirespeed performance necessary for real-world
applications. The XS40 is more than just an XML firewall: it is an XML proxy with carrier-grade features
that can parse, filter, validate schema, decrypt, verify signatures, access-control, transform, sign and
encrypt XML message flows at wirespeed so that enterprises can implement comprehensive XML
security practices without the performance penalties or security weaknesses typical of other solutions.
The XS40's flexible, XML-based architecture offers future-proof functionality and the agility to easily
adapt to changing standards, policies, and services.
Web services security is XML processing
Web services security functions, such as XML schema validation, XML Encryption, XML Signature, WSSecurity and others, require extensive XML processing. The security of the underlying XML processing
engine is essential to the security of a Web services security solution. Secure XML processing is also
very resource-intensive. This often forces organizations to choose between performance and protection,
because fully securing XML requires processing power not available in traditional XML engines.
DataPower Family Overview
Page 11
IBM
Page 12
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
WebSphere DataPower Integration Appliance XI50
IBM WebSphere DataPower Integration Appliance XI50 delivers common message transformation,
integration, and routing functions in a network device, cutting operational costs and improving
performance. By making on demand data integration part of the shared Service-Oriented Architecture
(SOA) infrastructure, the XI50 is one of the few non-disruptive technologies for application integration.
Features and benefits include:
Acceleration of existing integration hubs
Powered by wirespeed transformation technology, the XI50 can be used to off-load XSLT processing,
XPath routing, legacy-XML conversion, and other resource-intensive tasks from servers to reduce
latency, improve throughput, and free up compute resources.
Diagram 1: XI50 Message bus
Mainframe modernization and Web services
The XI50 can help protect and XML-enable mainframe systems, instantly connecting them to enterprise
SOA and Web services.
Diagram 2: XI50 Mainframe
Appliance simplicity
Easy to configure, operate, and own, the XI50 reduces the operational complexity of the IT environment
while cutting costs and risks.
Any-to-any transformation
The XI50 can parse and transform arbitrary binary, flat text, and XML messages, including EDI, COBOL
Copybook, ISO 8583, CSV, ASN.1, and ebXML. Unlike approaches based on custom programming,
DataGlue technology uses a fully declarative, metadata-based approach.
DataPower Family Overview
Page 13
IBM
Integrated message level security
The XI50 includes mature message-level security and access control functionality. Messages can be
filtered, validated, encrypted, and signed, helping to provide more secure enablement of high-value
applications. Supported technologies include WS-Security, WS-Trust, SAML, and LDAP. The XI50 is a
sealed network device for high reliability and increased security assurance.
Sophisticated multi-step message routing, filtering, and processing
Multiple synchronous and asynchronous transport protocols
Detailed logging and audit trail
The XI50 includes non-repudiation support.
Standards-based interfaces
The XI50 features standards-based interfaces for broad, uniform connectivity across enterprise
infrastructure.
Agile, highly flexible underlying scripting/configuration support
The XI50 enables comprehensive "out-of-the-box" support for fast, easy-to-handle standard, nonstandard, or off-standard, partner/vendor implementations.
XML enablement and wirespeed application integration
The XI50 helps reduce the time, cost, risk, and complexity of traditional integration approaches.
Metadata-based integration
Unlike approaches based on hard-coded middleware adapters, the XI50 uses a fully declarative,
metadata-based approach. The unique technology enables data-oriented programming (DOP)
paradigms to be employed without introducing bottlenecks. Easy-to-use visual tools are available to
assist business analysts in configuring format descriptors, mappings, and message choreography.
Security and performance
Powered by robust technology built from the ground up with security in mind, the XI50 provides XML
integration on a more secure foundation with the performance necessary for real-world applications. The
XI50 can parse, filter, transform, route, and enforce access-control messages of disparate format at
wirespeed. It also provides encryption and decryption, as well as digital signature signing and verification
capabilities.
Page 14
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Before You Begin
There are a few things you can do to make the rest of the PoT journey a bit easier.
Tip 1: Set up the hosts file for easy access to the servers.
Throughout the course of the PoT, you’ll be accessing the DataPower device® and a Web server. Since
the workstation you’re using may not have access to a DNS that contains a reference to the DataPower
device or the Web server, you can add entries to the hosts file on your workstation instead.
In a command window, determine if your workstation can access datapower and demoserver. Use the
ping command as follows:
ping datapower
ping demoserver
If both hosts are reachable, jump to the next tip. If either of the hosts is unreachable, you’ll need to edit
the hosts file on your workstation.
First, using Notepad, open the hosts file to prepare for editing. It is located in the following directory:
C:\WINDOWS\system32\drivers\etc
Now add entries to the host file depending on which servers weren’t reachable:
xx.xx.xx.xx
xx.xx.xx.xx
datapower
demoserver
Save (and close) the hosts file, and then ping the hosts again to make sure you can access them now.
In a Web browser, type in the following URL:
http://demoserver
If you receive the list of labs for the PoT, you’ve successfully accessed demoserver.
Tip 2: Make sure the curl executable is in the path.
From the command window, type the command: curl. If the command is not found, you should modify
the workstation’s path to include c:\student\curl. If you need assistance with this, please ask the
instructor.
Tip 3: Add links for easy access.
Once you can access the DataPower device, make a shortcut link in your browser or on your desktop so
that you can access it without having to type the URL each time.
Before You Begin
Page 15
IBM
Page 16
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 1
Introduction to the DataPower WebGUI
In this lab, we examine some of the aspects of DataPower’s Web-based user interface (WebGUI). The
WebGUI can be used for all aspects of configuring the DataPower device. For example, it can be used to
setup the various network interfaces, as well as create sophisticated policies for accessing Web services.
In Lab 1, we will demonstrate the following:





Logging into the WebGUI
Getting familiar with the organization of the WebGUI
Exploring the various icons and menus
Exploring the DataPower logging capabilities
Exploring the on-board file system
Each student has been provided with a unique student number. Your user id is based on the number you
received. For example, if your student number is “1”, then your user id is student01. All students will use
the password “password”.
The DataPower appliance uses the concept of Domains to separate logical configurations. For example,
in a production environment, a domain may represent a business area, like “shipping” or “accounting”.
Configurations that are created in a domain are secure from other domains and are not visible.
For the purpose of this PoT, a domain has been assigned to each student, and the name of the domain
corresponds to the user id. If your user id is student01, then you should select the Student01 domain
when doing the various lab exercises.
To summarize:

Your User ID is the word studentNN where NN is your assigned student number.

Your password is password

Your domain is the StudentNN.
Let’s get started!
1.1
Logging into the WebGUI
Your instructor should have provided you with a URL to use when connecting to the DataPower
appliance.
__1.
Open a Web browser on your workstation.
__2.
In the address line, type the URL provided by the instructor. Notice that the URL is a secured
address, using HTTPS instead of HTTP.
__3.
In the User field, type your user id, such as student01.
__4.
In the Password field, type the word password.
__5.
In the Domain field, select the domain associated with your user id.
__6.
Click the Login button.
Introduction to the DataPower WebGUI
Page 17
IBM
__7.
You will probably be requested to change your password. Change your password to anything of
your choice then follow the prompts to re-login again.
After you log into the appliance, you will see the following page:
1.2
WebGUI Organization
There are several areas in the WebGUI worth noting:

On the banner section of the page, there is a drop-down menu named Domain. It shows you the
current domain you’re working within, and also allows you to change to other domains that you
have access rights to.

The Save Config button is used to save all of your changes into the device’s flash memory.
When you make changes to a configuration, the changes are immediately active, but they are not
saved to the flash memory until you click this button.

The “Logout” button will end the current session. Any changes you made will remain active within
the device.
Page 18
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM


The left side of the page is the navigation bar. At the top is a link (labeled “Control Panel”) to
access the main control panel page, as well as several expanding menus.
o
Status provides menu options to view the overall status of the device, network
connections, configurations, and many other objects within the system.
o
Services provides some shortcuts for creating and managing the various services and
any associated objects.
o
Network provides menu options that help you work with network status and settings such
as DNS, Ethernet settings, etc.
o
Administration provides menu options that help you administer the device, such as
creating domains, users, exporting and importing configurations, etc.
o
Objects provides a list of all available object types on the device.
The body of the page shows the Control Panel. The Control Panel provides a concise set of
icons that represent the most commonly used services and tasks. It is divided into three sections:
o
Services provides access to wizards that help create the various types of services that
the device offers.

Web Service Proxy is used whenever a Web Service is being protected. This
service is associated with a WSDL (or a WebSphere Services Registry and
Repository or UDDI subscription to a WSDL).

Multi-Protocol Gateway is used whenever protocol mediation is required, such as
converting between HTTP and MQ. (This option is only available on the
DataPower XI50)

XML Firewall is used whenever protecting generic HTTP traffic such as XML data
(when no WSDL is required). It can also handle non-XML data.

Web Application Firewall is used whenever a Web application is being protected.

XSL Accelerator is used when only high speed XML/XSL transformations are
required.
o
Monitoring and Troubleshooting, which provides easy access to system logs,
troubleshooting tools, Web service monitors and device status pages.
o
Files and Administration, which provides easy access to the onboard flash-based file
system, a control panel, import and export tools, and a keys and certificates management
tool.
At any time, you can click the Control Panel link at the top of the navigation bar to redisplay the control
panel.
Introduction to the DataPower WebGUI
Page 19
IBM
1.3
DataPower Logging
__8.
Click on the View Logs icon. The default system log will be displayed and should look similar to
the following image (there may or may not be any log entries depending on the state of the
device):
The DataPower logging mechanism supports various types of log targets. Log targets define where
messages are sent. You can create additional log targets, enabling the device to send log entries to offdevice logging services such as a syslog server, a pager, or a generic SOAP-based Web service.
Each domain has its own log target, so the logged messages from one domain won’t appear in another
domain’s log. Furthermore, log targets can be configured to listen only for specific types of messages.
When creating configurations, the logs provide detailed information as to what events are occurring and
how they are handled by the appliance. You can adjust the logging level to one of many settings, ranging
from information only to debug, which provides the most detail about internal events.
__9.
In the Navigation Pane (on the left side), click on the Administration link to reveal the various
options in the Administration Menu.
__10.
Under the Miscellaneous heading (towards the bottom of the list), click on Manage Log Targets.
Page 20
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__11.
Click on the Add button to display the Configure Log Target page as shown below:
__12.
Click on the Target Type drop-down list to see the various log target types. If you select any of
them, you can see the various options associated with each log target type.
At the top of the page are several tab headers. Those additional tabs allow you to further refine how the
target responds to various messages.
__13.
Click on the Event Filters tab. This tab configures the log target to listen only for specific event
codes.
__14.
Click on the Object Filters tab. This tab configures the log target to listen to messages generated
by specific objects (or services).
__15.
Click on the Event Subscriptions tab. This tab configures which events the log target should
listen for.
__16.
Click on the Cancel button to exit.
Introduction to the DataPower WebGUI
Page 21
IBM
1.4
DataPower’s On-Board File System
__17.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__18.
Click on the File Management icon. You should see a page similar to the one below.
The DataPower on-board file system has a set of predefined directories. Each directory has a specific
function.

local: is where you will upload any files specific to your domain.

logtemp: holds the output of the logging system.

store: is visible by all domains and contains many pre-composed XSL templates that can be
used out of the box.

cert: holds any keys or certificates that were uploaded onto the appliance. It’s important to note
that all of the contents within the cert: directory is encrypted and cannot be exported off the
device. Furthermore, you can only see a list of the names of the keys and certificates, but you
cannot view them.

temporary: is like a scratchpad that you can use. Once you sign off, the contents are cleared.
Page 22
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__19.
Let’s upload a file that we’ll be using in a later lab exercise. Click on the Actions link associated
with the local: directory to reveal the actions pop-up menu (see below).
__20.
Click on the Upload Files link.
__21.
Click on the Browse button, and from the student/artifacts directory select the file named
soapMsg.xml.
__22.
Click Open to select the file.
__23.
Click the Upload button to upload the file into the local: directory.
__24.
Click the Continue button to dismiss the upload confirmation window.
__25.
Click on the small plus sign to the left of the local: directory name to reveal the contents of the
local: directory.
1.5
Summary
As you have seen so far, the DataPower WebGUI is organized much like any typical Web site. The
layout remains consistent throughout all phases of configuration, with the navigation pane on the left and
the main page presenting various configuration options in the center.
If you have additional time remaining before the next lab begins, feel free to click on some of the various
icons or menu options to become more comfortable with the WebGUI. While exploring, please make sure
to cancel out of any functions, or simply click on the Control Panel link to cancel and exit.
Introduction to the DataPower WebGUI
Page 23
IBM
Page 24
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 2
XSL Acceleration
The primary function of the XSL Proxy is to offload and accelerate XSL transformations. This service is
primarily intended for browser-based traffic.
The objective of this lab is to learn about:

XSL Proxy objects and how they are used

Proxy mode vs. co-processor mode

Stylesheet caching

Streaming mode
The most typical use case of the XSL Proxy is for offloading XSL transformations from a server.
Ultimately, this results in a substantial reduction in processor cycles on the server. A browser may make
a request for a particular Web page. The request first hits the XSL proxy, but is passed through to the
backend. The backend returns an XML document to the XSL proxy. At that point, depending on how the
proxy is configured, the proxy will obtain the necessary stylesheet and transform the XML. The result is
then passed back to the original client.
Which XSL stylesheet, and where to obtain it from is configurable in the XSL proxy. The required
stylesheet can be explicitly defined, or it can be determined as a result of an XML processing instruction.
The location of the stylesheet is also configurable. For example, it is possible to load the stylesheet into
the onboard DataPower file system, or provide a URL to where the stylesheet is located. Once the
stylesheet is obtained, it is compiled and then cached for future use.
One notable point that differentiates the XSL Proxy from the XML Firewall that you’ll be using later is that
the XSL proxy will allow non XML traffic to flow through without incident. For example, if a request is
made that results a returned HTML page that contains <img> tags, the browser will GET those images
through the XSL proxy, and the returned non-XML content will be permitted to flow through the proxy. In
contrast, the XML Firewall will generally (there are exceptions) attempt to parse inbound traffic as if it
were XML. A non-XML document would result in a parse exception.
In this lab, you’ll create an XSL Proxy service object that will sit between your browser and a backend
Apache HTTP server. When you make a request for the “labs.xml” document, the request will be
forwarded to the HTTP server, which will return labs.xml to the XSL proxy. The XSL proxy will then
transform labs.xml against pagelayout.xsl. The resultant HTML page will be returned to your browser.
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id. If you forget to select the correct domain, you can
select from the dropdown list after you log in.
__2.
If the control panel is not visible, click the Control Panel link at the top of the navigation pane.
__3.
From the list of Service icons (on the top row), click on the XSL Accelerator icon. The Configure
XSL Proxy page will be displayed.
__4.
Click the Add Wizard button.
XSL Acceleration
Page 25
IBM
The XSL proxy can function in two modes. The XSL Proxy service mode performs all transformations
inline with the request. It can transform the inbound request or the outbound response. It sits between
the client and the server. This scenario is the preferred and most widely used.
When an XSL proxy is configured in co-processor mode, it acts as a call-out from a process, such as a
Java program. Instead of using XML/XSL specific jars, a DataPower jar is used and will make calls to the
DataPower hardware for XSL transformation.
For this lab, you’ll be configuring the XSL Proxy as a “service”.
__5.
Select the XSL Proxy Service radio button, then click Next.
All objects that you create on the DataPower device have names. These names are used primarily for
identifying objects or referring to them from other objects. They are not visible from outside of the
DataPower environment.
DataPower XML services have two modes when performing XSL transformations: streaming and
buffered. The default is buffered, where an inbound (or outbound) XML document is completely parsed
prior to beginning an XSL transformation against it. This is similar to the DOM parser model. In some
circumstances, it may be advantageous to begin the transformation process as the XML document is
being streaming through the device. Streaming mode is similar to the SAX parser model. This is
particularly advantageous when the inbound XML document is excessively large (i.e. half gigabyte per
file). The DataPower device will automatically switch to streaming mode in the event that it determines
that a received file is too large. It can also be configured to always attempt to use streaming mode. Of
course, streaming mode comes with a price – the some XSL functions, such as sorting, or look-ahead
searching, obviously cannot be used in streaming mode. The onboard XSL compiler marks compiled
stylesheets as capable or incapable of being used in streaming mode.
For this lab, leave “Attempt to use streaming mode” off.
__6.
For the XSL Proxy Name, type MyXslProxy, then click Next.
__7.
Leave proxy type as “static-backend”; click Next.
Now you’ll define the properties of the backend server. The instructor will provide you with the host name
of the backend server. The question about SSL is referring to the channel between the DataPower
device and the backend server.
__8.
For the Server Address, type: demoserver
__9.
For the port number, type: 80
__10.
Click the Next button.
This page helps you to define the front side (client side) of the service. There are four physical Ethernet
interfaces on the appliance. Each can be assigned not only a physical IP address, but virtual IP
addresses as well. When you define service listeners, you can specify a specific IP address to listen for
inbound traffic, or you can specify 0.0.0.0 which instructs the service to listen for requests on all IP
defined IP addresses.
__11.
Page 26
In the Front End (client) information page, leave the Device Address with 0.0.0.0, but change the
port to your 80nn where nn is your student number. For example, if your student number is 01,
use “8001”; if your student number is 20, use “8020”.
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__12.
The SSL prompt in this case is referring to the channel between the client and the DataPower
device. Leave it off, and click the Next button.
Now you’ll define which stylesheet to use, and where to obtain it from. The “Use Document’s Processing
Instructions” is selected; the proxy will look into the XML message and honor the stylesheet processing
instruction. It will attempt to fetch the stylesheet from the indicated URL in the processing instruction.
The stylesheet can also be explicitly specified by providing a location URL where it can be found. The
URL can specify that the stylesheet should be obtained from an HTTP server, or an FTP server, or even
from DataPower’s onboard file system.
For this lab, you’ll instruct the proxy service to fetch the stylesheet from a remote HTTP server (located
on the instructor’s machine).
__13.
In the Select from Store dropdown, select: http://
__14.
In the field to the right of “http://”, type the following exactly: demoserver/pagelayout.xsl
__15.
Click the Next button.
The final confirmation page is displayed to show you the choices you’ve made. When you click the
Commit button, the proxy will be created and become active.
__16.
Click the Commit button.
__17.
Click the Done button.
Before you test the proxy, let’s attempt to view both the XML file and the associated XSL stylesheet.
__18.
Open a browser and navigate to the actual HTTP server, not the DataPower device. The
instructor will provide you with the actual host name.
http://demoserver/labs.xml
The browser should display some XML that looks similar to the following image.
XSL Acceleration
Page 27
IBM
__19.
Now enter the URL of the stylesheet.
http://demoserver/pagelayout.xsl
The browser should display the XSL that will be used to transform the labs.xml document.
__20.
Finally, request the labs.xml document through the newly created proxy service. The URL should
look as follows:
http://datapower:80nn/labs.xml (nn is your student number)
You should see a page similar to the following:
Page 28
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
As mentioned earlier, DataPower compiles and then caches stylesheets to make subsequent requests
faster. Let’s take a look at one of the status pages that shows how many stylesheets have been cached.
__21.
In the left hand navigation pane, click on the top link labeled Status.
__22.
Scroll down and locate the section labeled XML Processing. Within that section, locate and click
on the link labeled Stylesheet Cache.
You should see a page similar to the following:
On this page, you can see that the default manager has one cached stylesheet. The “XML Manager” is a
special object that allows you to configure settings associated with XML processing, such as size limits,
caching, etc. If you were trying to debug a troublesome stylesheet and wanted to make sure that the
proxy was not caching it, you could disable caching from within the XML manager.
2.1
Saving Your Changes
To persist all of your changes to the flash-based file system, you should save the configuration now.
__23.
Click the Save Config button found in the upper right corner of the page.
2.2
Summary
In this lab exercise, you learned how to create an XSL Proxy service object that receives GET requests
from a client, forwards the request to a backend server, then transforms the server’s response against a
predefined stylesheet, resulting in HTML being returned to the browser.
You learned that DataPower services can process XML messages in two ways: buffered and streaming.
By default, DataPower attempts to buffer all XML messages, but when the message is too big, it will
automatically switch to streaming mode. You can also explicitly set a listener to act in streaming mode.
Streaming mode allows extremely large XML documents to be transformed before they are completely
parsed, but there are some limitations as to what XSL elements can be used (the limitations are detailed
in the product documentation).
Finally, you saw how DataPower caches compiled stylesheets, and how the XML manager allows finegrained control over how a service object handles XML processing.
XSL Acceleration
Page 29
IBM
Page 30
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 3
Working with XML Messages and Schemas
In this lab, we examine how to create an XML firewall service that consumes an XML message (via an
HTTP Post) and validates it against an XML schema. In addition, we will want the service to check the
message for malformed XML content or any other XML threats.
In this lab, you’ll learn about:

XML Firewalls and how they are configured

XML threat protection

Loopback services

Schema validation
3.1
Creating an XML Firewall Service
In this section, you’ll be creating your first service. We’ll start small with an XML Firewall that simply
validates the inbound message against a schema while simultaneously checking for XML threats and
malformed content.
In general, DataPower acts as a full service proxy between a client and a server. When a request arrives,
DataPower processes the request (checking for threats, transforming, etc), then forwards the request out
the back to the original destination (or it can be routed to a new destination). The same process is
repeated for the response from the server.
Since this exercise doesn’t require a backend Web server, you will configure a loopback service. It works
the same as just described, except instead of forwarding the message to the backend server, it will return
the processed request to the client.
Loopback services are very useful when configuring policies and troubleshooting as you’ll see throughout
this exercise. Once a loopback service is completed, it can easily be changed to forward the outbound
request to a real server.
If you logged out of the WebGUI after completing the last lab exercise, you’ll need to log back in now.
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id. If you forget to select the correct domain, you can
select from the dropdown list after you log in.
__2.
If the control panel is not visible, click the Control Panel link at the top of the navigation pane.
__3.
From the list of Service icons (on the top row), click on the XML Firewall icon. The Configure
XML Firewall page will be displayed.
__4.
In the Configure XML Firewall form, Click on the Add Wizard button. You will be provided with a
list of scenarios that the wizard can help you create.
__5.
Select the Schema-Validate / Filter radio button; click the Next button.
Working with XML Messages and Schemas
Page 31
IBM
__6.
In the field provided, type a name for the new XML Firewall. Since a single DataPower appliance
can have many different types of services, its best to give it a meaningful name that will help
identify its function. For this exercise, you can give it a simple name such as MyXmlFW. When
finished, click the Next button.
__7.
On the Select Service Type page, use the drop-down list to select loopback-proxy; click the
Next button.
__8.
On the Front End (Client) Information page, you will define what IP address and port this service
will listen on. The DataPower appliances have four Ethernet ports, each with an associated IP
address. In addition, virtual IP addresses can be defined. The wizard chose a default value of
0.0.0.0, which specifies that the service should listen on ALL IP addresses configured on the
appliance. Leave the IP Address as 0.0.0.0.
__9.
Specify the port number as 4nn01, where nn is your student number. For example, if your
student number is 03, use port 40301. If your student number is 14, use port 41401.
__10.
Leave the SSL usage selection to off and then click the Next button.
__11.
On the Filter Information page, leave the default to off and click the Next button.
The “Validation Information” page allows you to select how the inbound XML document is schema
validated. You will need to indicate where the DataPower appliance will find the schema to use when
validating the message.
The first option instructs the appliance to use the schema reference (if any) that is specified within the
inbound XML message. If the inbound message has a schema reference, the appliance will go and fetch
the schema from the specified location. If no schema reference is specified, the inbound message will be
considered valid by default.
The second option allows us to specify exactly what schema to use when validating the inbound
message. This will allow us to upload a schema into the file system and use it when validating the
inbound message.
__12.
On the Validation Information page, select the second option, Validate Document via Schema
URL.
You may have noticed that when you clicked the validate option from the previous step, additional fields
were displayed, asking for the Schema URL. You will now need to upload the schema from your PC.
__13.
Ensure that the Schema URL dropdown box has local: selected, and then click on the Upload
button.
__14.
In the File Management pop-up window, click the Browse button.
__15.
Use the file dialog to locate the file named simpleSchema.xsd in the
student/artifacts directory. Click the Open button.
__16.
In the File Management window, click the Upload button. You should receive a confirmation
message that indicates the file was successfully uploaded. Click the Continue button to dismiss
the window.
Page 32
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
When you return to the “Validation Information” page, notice under the Schema URL that the two
dropdown boxes now identify a fully qualified URL to the uploaded schema file. The first dropdown
specifies that the schema file is located in the local:/// directory in the virtual file system and the second
dropdown box shows the file name. In other words, the fully qualified URL is local:///simpleSchema.xsd.
The page should resemble the following:
__17.
If your form looks like the one above, click the Next button.
The last page of the wizard is displayed to provide confirmation of the choices you’ve made. The XML
Firewall provides built-in protection against a variety of XML specific attacks.
__18.
You’re now ready to accept the choices and create the XML Firewall service. Click the Commit
button to create the service.
__19.
At this point, the wizard will create the underlying configuration objects for the choices you’ve
made, and provide a final confirmation that the service was successfully created. Click the Done
button to continue.
Working with XML Messages and Schemas
Page 33
IBM
You’re now ready to test the service you just created. Test scripts have been provided for your
convenience to make testing easier; however you’re free to manually enter the individual commands into
a command window.
First, let’s take a look at the message you’ll be posting to the newly created service. Some text has been
omitted for formatting purposes (indicated by {omitted}).
Listing of file: student/artifacts/soapMsg.xml
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsse="http://...{omitted}...1-wss-wssecurity-secext-1.0.xsd"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<soap:Header>
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>david</wsse:Username>
<wsse:Password>foobar</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<product-info>
<product-id>XI50</product-id>
<brand>WebSphere DataPower</brand>
<encoded-description>SUJNIFdlYlNw {omitted}</encoded-description>
<benefits>Security;Integration;Performance</benefits>
</product-info>
</soap:Body>
</soap:Envelope>
This message matches the uploaded schema (shown below).
Listing of file: student/artifacts/simpleSchema.xsd
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="product-info">
<xs:complexType>
<xs:sequence>
<xs:element name="product-id">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="XA35"/>
<xs:enumeration value="XS40"/>
<xs:enumeration value="XI50"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="brand" type="xs:string"/>
<xs:element name="encoded-description" type="xs:string"/>
<xs:element name="benefits" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Page 34
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
If you’re familiar with XML schemas, you can see that the body of the SOAP message correctly conforms
to the schema. Notice that the product-id element restricts its values to XA35, XS40, or XI50. We’ll test
this later by sending a message that contains an invalid product-id value.
__20.
Open a command window. One way to accomplish this is to click the Windows Start button,
select Run, and type cmd in the open field.
__21.
Using the cd command, navigate to the student/artifacts directory.
__22.
Type the following command, and replace the N with your student number (the host name may
be different – consult with the instructor if necessary).
post soapMsg.xml http://datapower:4nn01
If you’re student number is 14, then you should type:
post soapMsg.xml http://datapower:41401
If everything worked as expected, you should see the contents of the XML file echoed back to the
console window.
Now try the same command, but post the soapBadProduct.xml file instead. If you inspect the XML before
sending it, you will see that it has an invalid product-id value in it. The schema restricts the values of
product-id to XA35, XS40, and XI50, but the file has “1234” as the product-id.
Working with XML Messages and Schemas
Page 35
IBM
__23.
Post the soapBadProduct.xml file to the service as you did in the previous step. You will
receive a SOAP fault instead of the original XML document.
__24.
If the control panel is not displayed, click on the Control Panel link at the top of the navigation
pane.
__25.
Click on the View Logs icon.
Below is an excerpt of what you will probably see:
Here you can see more detail of why the transaction failed. Notice in the first log entry (at the bottom), it
provides a detailed description, including the offending value, of why the schema failed validation.
3.2
Saving Your Changes
At this point, you have created an XML Firewall that does schema validation against inbound SOAP
messages. To persist all of your changes on the device, you should save the configuration.
__26.
Click the Save Config button found in the upper right corner of the page.
3.3
Summary
In this lab exercise, you created an XML Firewall service that validates the body of inbound SOAP
messages against a schema. In addition, the service provides some basic XML threat protection against
a variety of known XML threats. You tested the service by sending a valid message and an invalid
message. You also learned how to use the View Logs icon on the control panel to assist in
troubleshooting rejected messages.
Page 36
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 4
XML Threat Protection
In this lab, we examine how the DataPower appliance can help protect against a variety of XML threats.
You’ll use the XML Firewall service that you created in the previous exercise and modify it so that it will
protect against SQL Injection threats.
4.1
What is an SQL Injection Threat?
If you’re not familiar with what an SQL injection threat is, consider the case where a Web service
receives a SOAP message that, within the SOAP body, contains a field called <last-name>, and the
SOAP response will return to the caller a list of names that match the last-name criteria. In other words,
perhaps the underlying service may issue an SQL statement such as:
SELECT * FROM EMPLOYEE WHERE LASTNAME = ?
The question mark will be replaced with the contents of the <last-name> element. For example, here is a
SOAP body that contains the <last-name> element.
<soap:Body>
<customer-lookup>
<last-name>KAPLAN</last-name>
</customer-lookup>
</soap:Body>
When the ? is replaced with the contents of the <last-name> element, the resultant SQL statement would
be:
SELECT * FROM EMPLOYEE WHERE LASTNAME = ‘KAPLAN’
However, if the value submitted in the <last-name> element was malicious and looked like this:
<soap:Body>
<customer-lookup>
<last-name>KAPLAN’ OR ‘1’=’1</last-name>
</customer-lookup>
</soap:Body>
The SQL statement would become:
SELECT * FROM EMPLOYEE WHERE LASTNAME = ‘KAPLAN’ OR ‘1’ = ‘1’
The service will return the details about all employees, as the WHERE clause will evaluate to true for
every record in the EMPLOYEE table.
4.2
How does DataPower protect against SQL threats?
Since every database environment is different, with different naming standards, table names, etc, it
would be impossible to provide a single solution that would protect against every potential threat.
However, the DataPower appliance approaches this problem with a flexible customizable solution. Out of
the box, it will protect against basic SQL injection threats such as the one demonstrated above, but if
your environment requires additional “patterns”, they can easily be added to the underlying detection
mechanism.
At the heart of the SQL injection threat protection mechanism is an XSL stylesheet that contains logic to
scan the entire inbound XML message. First it strips all of the XML tags out of the document, leaving
only the remaining attribute and element values, then it steps through each value and compares them
against a list of patterns that represent potential injection threats. If one matches, the entire document is
XML Threat Protection
Page 37
IBM
rejected. The patterns are represented as regular expressions. You can easily add additional regular
expressions to the pattern matching criteria.
If you’re curious about what the XSL stylesheet looks like, you can view them from within the DataPower
file manager. They are located in the store: directory and are named:
SQL-Injection-Filter.xsl
SQL-Injection-Patterns.xml
The stylesheet that scans the input document
Contains all of the injection threat patterns
In the Appendix of this document is a reproduction of an article from IBM’s Website regarding XML
Threats which you may find interesting. Feel free to read through it if you have spare time.
4.3
Adding SQL Injection Threat Protection
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Click on the XML Firewall icon.
In the list of XML Firewalls, you should see the one you created in the previous lab.
__4.
Page 38
Click on the name of the firewall you created (i.e. MyXmlFW).
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__5.
In the Configure XML Firewall page, under the General Configuration section, locate the
dropdown box entitled Firewall Policy and click the ellipsis
button next to it.
After you click the ellipses button, you will see the firewall policy editor as shown below:
XML Threat Protection
Page 39
IBM
A policy defines how a service will handle each request (and response) that arrives. In the middle portion
of the policy editor is a processing rule, often referred to as a processing pipeline. The rule is read from
left to right, and each action (represented by various icons) will execute against the inbound message.
Matching rule. When you move the mouse pointer over this icon, you should
see a small pop-up window that tells you more details about what the matching
criteria are. This action will inspect the inbound message and make a decision
whether it matches or not. For this exercise, the match rule was created for you
by the wizard and will match any URL that arrives into the service. This
matching rule is a URL matching rule, and the URL pattern that it matches is
specified as * which means, match any URL.
Schema Validation action. It will inspect the inbound message and validate it
against a specified schema. When you hover the mouse pointer over this icon,
you can see the name of the schema that will be used for validation.
Results action. This action is used to specify details regarding the outbound
message, and where it should be forwarded to.
At the top of the policy editor window is a row of icons that represent the most commonly used actions
(see below)
__6.
To add the SQL Injection Threat filter to the pipeline, click and drag the filter action
and
drop it right between the schema validation action
and the results action
. The resulting
pipeline should look as follows. (If you accidentally drop the action in the wrong place, just click
and drag it where it belongs)
__7.
The yellow outline around the filter action indicates that the action has not yet been configured.
Double click on the filter action
Page 40
to open its configuration page.
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__8.
In the first dropdown list next to the Processing Control File, select the store:/// directory. The
page will refresh and populate the second dropdown list with all of the stylesheets in the store:
directory.
__9.
In the second dropdown list, select the file named SQL-Injection-Filter.xsl. The
completed form will look as follows:
__10.
Click the Done button to close the window. You will notice that the yellow outline has been
removed from the Filter action.
__11.
Click the Apply Policy button. The changes to the rule won’t take effect until you click this
button.
__12.
Click on the Close Window link located in the top row of links.
The XML Firewall service has now been configured to search for SQL Injection Threats. Let’s post a
malicious message to the service and see what happens.
__13.
Open a command window. One way to accomplish this is to click the Windows Start button,
select Run, and type cmd in the open field.
__14.
Using the cd command, navigate to the student/artifacts directory.
__15.
View (using the type command) the soapSqlThreat.xml file and notice the value of the <brand>
element. It contains suspicious text that, if put into an SQL statement, would cause the SQL
statement to produce unexpected results.
XML Threat Protection
Page 41
IBM
__16.
Test the firewall. Type the following command, and replace the N with your student number, and
the url with the URL provided by the instructor.
post soapSqlThreat.xml http://datapower:4nn01
Notice that a SOAP fault was returned specifying that the message contains restricted content. The SQL
filter action was able to detect the malicious text in the <brand> field of the SOAP message.
4.4
Malformed Content
The XML Firewall was setup to expect inbound messages to be in XML. As such, it will automatically
protect against malformed content (XML that is not valid). Let’s send a message that appears valid, but
has malformed XML. If you inspect the file named soapMalformed.xml, you can see that the closing
tag of the <product-info> group is malformed and specified as <product-infoX>.
__17.
Post the soapMalformed.xml file to the listener as you did in the previous steps.
post soapMalformed.xml http://datapower:4nn01
Notice that a SOAP fault was returned specifying that the message contains malformed content.
__18.
Click the Apply Changes button to save your changes to the XML Firewall.
__19.
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
4.5
Additional XML Threat Protection
It’s beyond the scope of this lab to delve into the various types of XML threat protection provided by the
DataPower appliance, however if you have extra time (while others complete this exercise), you can
browse through the XML Threats page of the XML Firewall configuration, or check out the detailed article
in the Appendix of this document for a more in-depth discussion of XML threats.
To view the XML threat protection configuration page (time permitting):
Page 42
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__20.
If your browser is not showing the Configure XML Firewall page, you will need to open it as you
did in the beginning of this exercise.
__21.
At the top is a row of tabs labeled General, Advanced, etc. Click on the tab labeled XML Threat
Protection. If you cannot see the tab, you may have to use the small tab scroll buttons at each
end of the tab bar (you don’t have to actually click them, just move the mouse over the circled
arrow).
__22.
After clicking the XML Threat Protection tab, read through some of the various types of threats
that the device can protect against. Please don’t make any changes, however, since we will be
re-using your XML Firewall service in subsequent steps.
__23.
When you’re finished viewing the XML threat configuration screen, click the Cancel button to exit
the page (if you get a warning message, just ignore it).
4.6
Summary
In this lab exercise, you learned about SQL Injection threats and how the DataPower appliance can
defend against them. You also learned how SQL threats are detected by using a collection of regular
expressions that define the various threat patterns. The collection of regular expressions can be
extended for your specific database and organizational requirements.
You saw that the processing policy contains rules (or pipelines) that define what actions will occur when
a message is received. The first part of every rule is a matching rule which defines what messages the
rule will apply to. Actions in the rule are added using a drag-and-drop paradigm. Double clicking on an
action opens its configuration page. In later lab exercises, you’ll learn more about processing policies
and rules.
Finally, you saw how the XML Firewall service that you created can prevent malformed XML content
from passing through to the backend server.
XML Threat Protection
Page 43
IBM
Page 44
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 5
Transforming with XSL
In this lab exercise, you’ll be modifying the previously defined XML Firewall to transform the inbound
message against a simple XSL template.
Although it is beyond the scope of this PoT to dive into the benefits and advantages of XSLT, this lab
exercise will introduce you to how custom XSL templates are used within a processing rule. In addition,
you’ll receive a brief exposure to one of DataPower’s powerful XSL extension functions.
DataPower’s XSL extension functions expand the power of standard XSL by adding a library of functions
that perform tasks such as encoding or decoding base-64 encoded data, setting HTTP response headers,
or even making SOAP calls to an external Web service and incorporating the response in the active
transformation.
In this lab, you’ll be exposed to:

The Transform Action

The dp:decode() extension function
5.1
Adding a Transform Action
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Click on the XML Firewall icon.
In the list of XML Firewalls, you should see the one you previously created. The page should look similar
to this:
__4.
Click on the name of the firewall (i.e. MyXmlFW).
Transforming with XSL
Page 45
IBM
__5.
In the Configure XML Firewall page, under the General Configuration section, locate the
dropdown box entitled Firewall Policy and click the ellipsis
policy editor will appear.
button next to it (see below). The
__6.
Click and Drag the Transform action
action
(see below).
and drop it between the filter action
and the results
__7.
Notice that the newly added transform action is outlined in yellow, indicating that it has not been
configured yet. Double click the newly added transform action to reveal its configuration page.
The field labeled Processing Control File is where you would put the URL to the XSL template to be used
for this transformation. The URL does not have to be local to the DataPower device; in fact, it could be
the URL of an HTTP server that serves up XSL templates as they are needed. For this lab, we’ll upload
the XSL template and put it in the local: directory.
__8.
Page 46
Click on the Upload button associated with the Processing Control File URL.
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__9.
Click the Browse button to browse your local file system.
__10.
Navigate to the student/artifacts directory; select and open the template named
productTransform.xsl.
__11.
Click the Upload button to upload the file into the device; then click Continue in the confirmation
window. Your window should resemble the following image:
__12.
Leave the remaining fields as they are; click Done (towards the bottom of the page).
If you hover the mouse over each of the action icons in the processing rule, you can see more detailed
information about that action. For example, hovering over the transform action icon will pop up a small
window showing that the input context is INPUT and the output context is PIPE. The special PIPE
indicates that the output from this action will flow into the next action.
__13.
Click the Apply Policy button to save your changes to the processing rule.
__14.
Click the Close Window link to close the policy editor.
__15.
Click the Apply button at the top of the Configure XML Firewall page to save all changes.
__16.
Click Save Config to save your configuration to the device’s flash memory.
Transforming with XSL
Page 47
IBM
You’re now ready to run another transaction through the XML Firewall service. Before you do that, let’s
take a look at what the XSL template will do to the inbound message.
Here’s the SOAP body of the inbound message:
Listing of file: student/artifacts/soapMsg.xml
<soap:Body>
<product-info>
<product-id>XI50</product-id>
<brand>WebSphere DataPower</brand>
<encoded-description>SUJNIFdlYlNw {omitted}</encoded-description>
<benefits>Security;Integration;Performance</benefits>
</product-info>
</soap:Body>
The productTransform.xsl template looks specifically for two different patterns:

When an <encoded-description> tag is encountered, it will change it into a <description> tag and
then decode the original tag’s value. The dp:decode() function is a DataPower extension function,
and is within the dp: namespace.

When a <benefits> tag is encountered, it will use the str:tokenize() function to tokenize the list of
benefits (delimited by semicolons) into a small XML tree.
Partial Listing of file: student/artifacts/productTransform.xsl
<xsl:template match="encoded-description">
<description>
<xsl:value-of select="dp:decode(.,'base-64')"/>
</description>
</xsl:template>
<xsl:template match="benefits">
<xsl:variable name="benefits" select="str:tokenize(.,';')"/>
<benefits>
<xsl:for-each select="$benefits">
<benefit><xsl:value-of select="."/></benefit>
</xsl:for-each>
</benefits>
</xsl:template>
An identity transform is found at the end of the template, which will match anything else that hasn’t
explicitly been matched, and copy it to the output document.
__17.
Open a command window (if one is not already open).
__18.
Navigate to the student/artifacts directory.
__19.
Type the following command, and replace the N with your student number, and the url with the
URL provided by the instructor:
post soapMsg.xml http://datapower:4nn01
Page 48
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Notice that the <encoded-description> tag was replaced with a <description> tag, and that its contents
are no longer base-64 encoded. Also, the benefits list was properly expanded into a multi-element
<benefits> group.
5.2
Summary
XSLT is a powerful transformation language that can massage request and response messages
according to business requirements. The DataPower appliances extend standard XSL with a rich and
powerful set of extension functions including date manipulation, encryption, and calls to external URLs to
name just a few. A complete list of the extension functions can be found in the Extensions-Common.pdf
file found in the PoT materials.
Transforming with XSL
Page 49
IBM
Page 50
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 6
WS-Security: Digital Signatures
In this exercise, you’ll be modifying the previously defined XML Firewall to add a digital signature to the
message. Along the way, you’ll be working with the drag-and-drop policy editor as you did previously.
This time, you’ll be adding a signing action to the processing rule.
In this lab, you’ll be exposed to:

Uploading keys and certificates into the device.

Adding a signing action to a processing pipeline.

Adding a verify signature action to a processing pipeline.

Working with private keys and public certificates.

Cryptographic Validation Credential objects.

Matching rule concepts.
6.1
What is a Digital Signature?
The term “digital signature” refers to something created using public key technology. Two keys are
involved: a private key, which only you know, and a corresponding public key, which you can freely give
to anyone. What makes this key pair interesting is that anything encrypted using one key can only be
decrypted with the other one.
The primary usage of digital signatures is to verify the integrity of a transmitted message. When a
message travels over public networks, it can be intercepted, modified, and then forwarded on without
detection. Adding a digital signature to a message enables the recipient of the message to determine
whether the message has been altered along the way.
Let’s say I want to send you a digitally signed message. I first compute a special checksum, called a
message digest, on the message I want to send. I then encrypt this digest with my private key. The
result is a digital signature for the message. I then send this digital signature, along with the original
message to you.
When you receive the message, you’ll first compute a message digest on the received message. You’ll
then use my public key (which I previously gave to you) to decrypt the message digest that I sent along
with the message. If the two message digests (the one you calculated and the one I sent) are identical,
then you can be certain both that the data wasn’t changed in transit (integrity) and that the data was
signed by me (authentication).
Since digital signature creation and verification involves a considerable amount of mathematical
computations, the process is generally processor intensive. In addition to making the process very simple
to implement, DataPower appliances enable you to off-load this task from the application server, freeing
up costly processor cycles for business related tasks.
6.2
Adding a Digital Signature to a Message
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
WS Security Digital Signatures
Page 51
IBM
__3.
Click on the XML Firewall icon.
In the list of XML Firewalls, you should see the one you previously created.
__4.
Click on the name of your firewall (MyXmlFW).
__5.
In the Configure XML Firewall page, under the General Configuration section, locate the Firewall
Policy dropdown box and click the ellipsis
appear.
Page 52
button next to it (see below). The policy editor will
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__6.
Click and drag the Sign action
action
(see below).
__7.
Double click the sign action
__8.
In the Configure Sign Action window, click on the plus button
__9.
In the Configure Crypto Key window, type a name for the private key. For example, type the
name MyPrivateKey.
__10.
On the File Name line, click on the upload button.
__11.
In the File Management window, click on the browse button, and navigate the file browser to the
student/keysAndCerts directory. Select the file named
datapower.ibm.com-privkey.pem, then click Open.
__12.
In the File Management window, click Upload to upload the key.
__13.
Click Continue to close the dialog box.
WS Security Digital Signatures
and drop it between the transform action
and the results
to open its configuration page.
next to the Key dropdown list.
Page 53
IBM
The completed “Configure Crypto Key” window should look like this:
__14.
Click on the Apply button to create the Crypto Key.
Now you will need to upload your public certificate. The process is identical to uploading the private key,
except you will start the process by clicking on the plus button
next to the Certificate prompt.
__15.
Click on the plus button
next to the Certificate prompt.
__16.
In the Configure Crypto Certificate window, type a name for the certificate. For example, type the
name MyPublicCert.
__17.
On the File Name line, click on the Upload button.
__18.
In the File Management window, click on the Browse button, and navigate the file browser to the
student/keysAndCerts directory. Select the file named
datapower.ibm.com-sscert.pem, then click Open.
__19.
In the File Management window, click the Upload button.
__20.
Click Continue to close the dialog box.
You can leave the remaining fields of the “Configure Sign Action” page with their default values.
Page 54
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
The completed Configure Crypto Certificate window should look like this:
__21.
Click on the Apply button to create the Crypto Certificate.
__22.
Click the Done button to save the sign action configuration.
WS Security Digital Signatures
Page 55
IBM
__23.
The modifications that you’ve made to the processing rule won’t take effect until you click on the
Apply Policy button. Click on the Apply Policy button now (see below).
__24.
Click on the Close Window link at the top of the policy window to close the policy editor.
__25.
Click the Apply button in the XML Firewall Configuration page.
The processing rule is now complete. To summarize, when a message arrives, the service will:

Make sure the inbound XML message is valid and there are no XML threats.

Validate the XML against the schema that you uploaded in a previous lab exercise.

Inspect the message for potential SQL Injection threats.

Transform the message using productTransform.xsl.

Sign the message using WS-Security standards. It will use the private key and public certificate
that you uploaded when it creates the signature.
__26.
Type the following command, and replace the N with your student number, and the url with the
URL provided by the instructor.
post soapMsg.xml http://datapower:4nn01
Page 56
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
6.3
Verifying a Digital Signature
Now you’ll modify the signing firewall you just created so that it will also verify a digital signature. At
present, the current policy has no way of knowing whether the request should be signed or verified, so
you’ll be adding a matching rule to the policy to help distinguish requests. The matching rule will look for
/verify in the URI. If /verify is found, the verify rule will be run, otherwise, the default rule (the one that
signs the message) will be run.
button next to the Firewall Policy dropdown list.
__27.
Click on the ellipses
__28.
In the Rule section, click the New Rule button.
__29.
Double click the match action
__30.
In the Configure a Match Action window, click the plus button
The Configure Matching Rule window will be displayed.
to open its configuration page.
to create a new matching rule.
The name of the matching rule should relay an idea of what type of messages will result in a positive
match. The rule you’ll create will match any URL, so an appropriate name for this rule would be Verify.
__31.
In the Name field, type: Verify
__32.
Click on the Matching Rule tab at the top of the form.
A matching rule is actually composed of one or more matching expressions (or patterns). When a
message arrives, a matching rule will be executed to determine either a positive or negative match. In
the process of this determination, each expression within the matching rule will be checked, and if any
one of the expressions results in a positive match, the entire matching rule returns a positive matching
result.
Matching expressions can test the message in several ways. For instance, in this lab, you’ll be specifying
a matching expression that inspects the inbound requested URI. Matching rules support the following
types of matching expressions:

HTTP Header – the matching expression specifies what HTTP header to inspect; if the header is
found and it matches the specified pattern, a positive match occurs.

Fully qualified URL – attempts to match the entire URL, including host, port, and URI.

URL match – attempts to match just the URI portion of the request.
WS Security Digital Signatures
Page 57
IBM

XPath match – executes the provided XPath expression against the received message; if the
XPath expression results in a non-empty nodeset, a positive match occurs.

Error conditions – this special type of match is used in error rules, and acts in a similar way to
Java’s catch statement. If the specified error occurred during processing, a positive match is
returned.
__33.
Click on the Add button to add a new matching expression.
__34.
If it’s not already selected, in the Matching Type dropdown box, select: URL
__35.
In the URL Match field, type: /verify
__36.
Click the Save button.
__37.
Click Apply in the Configure Matching Rule window to save the changes to this matching rule.
__38.
In the Configure a Match Action window, click Done.
__39.
Click, drag, and drop a Verify
__40.
Double click the yellow outlined verify action to open its configuration page.
action after the match
action.
DataPower uses the concept of a cryptographic validation credential object (aka ValCred) to bundle one
or more related public certificates. Validation credentials are reusable objects and can be used both
when verify digital signatures, as well as when establishing bidirectional SSL. When a digital signature is
being verified, its related certificate will be looked-up in the validation credential and verified for
authenticity. If the certificate is not found, signature verification will fail. If it is found, it is considered
authentic, and used during the verification process.
__41.
In the Validation Credential section, click the plus button
new validation credential.
__42.
For the Name, type: MyValCred
__43.
In the Certificates section, select MyPublicCert from the dropdown list located in front of the
Add button. Make sure that MyPublicCert is selected in the dropdown list.
__44.
Click the Add button to add the cert to the list of certificates in the valcred. This step is
necessary because validation credentials can contain multiple certificates.
__45.
Click the Apply button to save the validation credential object.
__46.
Click the Done button to save the Verify action configuration.
__47.
Click the Apply Policy button to save changes to this new processing pipeline.
next to the dropdown list to create a
Matching rules are executed in order of their priority. At the bottom of the policy editor window is a
section called Configured Rules. Notice that each rule has been assigned a priority. The first rule is the
Page 58
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
one created when the original firewall was created. The second rule (priority = 2) is the one you just
created.
If you hover the mouse over each of the matching rules in the list, you’ll see that the first rule is
configured to match any url (indicated by the asterisk *), and the second one will match when a request
contains /verify as the URI. As the rules are now, the verify rule will never get executed because the first
rule will always match. Therefore, we need to change the ordering of the rules.
On the left side of the list of rules are some up and down arrow buttons. You need to either move the top
rule down, or move the bottom rule up (both accomplish the same thing).
__48.
Click on the down arrow from the first rule to move it to the second position. It should move to
the bottom of the list. (see below for final ordering)
Notice now that the verify match is first; if it fails, the next rule will be checked. Since the next rule will
match any URI, it will always match.
__49.
Click the Apply Policy button to save the changes to this policy.
__50.
Click the Close Window link to close the policy editor.
__51.
Click the Apply button to apply all changes to the firewall.
__52.
Click the Save config button to save your changes to the flash memory.
To test the verify firewall, you’ll first need to have a signed message. You’ll create a signed message by
calling the firewall as you did earlier, but this time you’ll capture the output to a file, then repost it to verify
the signature.
__53.
In the command window, type the following command:
post soapMsg.xml http://datapower:4nn01 > signed.xml
This command will save the output from curl into the file named signed.xml. Now you can send the
signed.xml file through and see that it verifies. Make sure to add /verify to the end of the URI.
post signed.xml http://datapower:4nn01/verify
If you’ve configured everything properly, you should receive the same message back again, otherwise if
the matching rule wasn’t configured properly, it will be double signed!
Now test the negative. Edit the signed.xml file and change some of the product name from XI50 to XI51
(or anything, it doesn’t really matter, just change it). You can use Notepad or the edit command in the
command window.
WS Security Digital Signatures
Page 59
IBM
Send the modified file back through the firewall exactly as you did in the last step (making sure to have
/verify at the end of the URL. You should get a SOAP fault indicating the hash values do not match.
post signed.xml http://datapower:4nn01/verify
6.4
Summary
In this lab, you worked with the policy editor to add a digital signature action to the existing processing
rule. During the configuration of the signing action, you uploaded both a private key and a public
certificate, resulting in the creation of a Crypto Key object and a Crypto Certificate object. When you
posted a SOAP message to the firewall, it performed all of the previously configured actions (validate xml,
filter sql injection, etc.), and then digitally signed the message before returning the response to the client.
You then configured an additional matching rule to look for /verify in the URI. When this pattern was
found, the inbound message will be verified instead of signed.
You tested the verification phase by first signing and saving a message. Once the message was saved,
you reposted it back to the firewall with the /verify URI, causing the device to execute the verify
processing rule instead of the default one. To verify that the verification action would detect if the
message was modified, you edited the signed message and reposted it back for verification; a soap fault
was generated indicating the hash value was wrong.
Page 60
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 7
WS-Security: Encryption & Decryption
In this lab exercise, you’ll be modifying your XML Firewall to encrypt the inbound message. Along the
way, you’ll be working with the drag-and-drop policy editor as you did previously, but this time, you’ll be
adding an encryption action instead of a signing action.
Additionally, we’ll investigate using a transaction probe, a powerful debugging tool that allows you to look
at the input and results of each action within the processing rule.
In this lab, you’ll be exposed to:

Encryption of the entire SOAP body.

Field-level encryption of just one element within the SOAP message.

Decryption

Working with a transaction probe.
7.1
Encryption Basics
In a similar fashion to digital signatures, encryption employs the use of a public certificate and a private
key. When encrypting a message, the public key is used to encrypt the message, however the public
key cannot be used to decrypt the message. Only the private key has the ability to decrypt anything that
was encrypted with the public key. The private key is never used to encrypt the message.
7.2
Encrypting the body of the SOAP message
In this first task, you’ll modify the processing rule (as you did in the digital signing exercise) to encrypt the
entire SOAP body.
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Click on the XML Firewall icon.
In the list of XML Firewalls, you should see the one you created in the previous labs. It will look similar to
this image:
__4.
Click on the name of the firewall (MyXmlFW).
WS Security: Encryption & Decryption
Page 61
IBM
__5.
Under the General Configuration section, locate the Firewall Policy dropdown box and click the
ellipsis
button to open the policy editor.
When the policy editor opens this time, the first rule in the list of rules is displayed. You’ll need to give
focus to the 2nd rule in order to add the encrypt action.
__6.
Click on the 2nd rule in the list to make it the active rule in the editor (see below).
__7.
Click and Drag the Encrypt action
action
(see below).
__8.
Double click the encrypt action to open its configuration page.
__9.
In the Configure Encrypt Action page, locate the Recipient Certificate dropdown list. For this lab
exercise, we’ll be re-using the certificate we uploaded in the digital signature lab. Select
MyPublicCert from the list.
__10.
Click the Done button to save the configuration changes.
__11.
Since you’ve made changes to the processing rule, you’ll need to click the Apply Policy button
to make these changes active (see below).
__12.
Click on the Close Window link at the top of the policy window to close the policy editor.
Page 62
and drop it between the sign action
and the results
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__13.
Click the Apply button in the XML Firewall Configuration page to save all changes you’ve made
to the service.
You’re now ready to test the firewall and see how it encrypts the body of the SOAP message.
__14.
In a command window, navigate to the student/artifacts directory.
__15.
Type the following command, and replace the N with your student number, and the url with the
URL provided by the instructor.
post soapMsg.xml http://datapower:4nn01
Look at the output of the command closely. You should notice that the tags from the SOAP body are no
longer in clear text. The entire body of the SOAP message has been encrypted.
7.3
Decrypting the message
Decrypting a message is as simple as encrypting; the only difference is you’ll be specifying the private
key instead of the public certificate. As you did in the digital signature verification lab, you’ll use matching
rules to determine when to invoke the decryption processing rule. You’ll create a matching rule that
matches /decrypt in the URI.
__16.
Re-open the policy editor by clicking the ellipses
__17.
In the Rule section, click the New Rule button to create a new processing rule.
__18.
Double click the yellow outlined matching action to open the configuration page.
WS Security: Encryption & Decryption
button.
Page 63
IBM
__19.
Click the plus
button to create a new matching rule. The Configure Matching Rule window
will be displayed.
__20.
In the Name field, type: Decrypt
__21.
At the top of the form, click on the Matching Rule tab.
__22.
Click the Add button to create a new matching expression.
__23.
In the URL Match field, type: /decrypt
__24.
Click the Save button to save this match expression.
__25.
Click the Apply button to save the matching rule configuration.
__26.
Click the Done button to save the matching action.
__27.
Click, drag and drop the decrypt
action.
__28.
Double click the yellow outlined decrypt action to open its configuration page.
__29.
In the Decrypt Key dropdown list, select: MyPrivateKey
__30.
Click the Done button to save the decrypt action configuration.
action onto the processing rule to the right of the match
The new processing rule was added to the bottom of the list of configured rules. Since the processing
rule at priority 2 will match all URLs, the decrypt rule will never get executed. To resolve this problem,
you’ll have to move it up one notch in front of the rule named MyXmlFW (at position 2).
__31.
Click the up arrow on the Decrypt rule to move it up to position 2. The final list of configured rules
should look similar to this (the names may be slightly different).
__32.
Click the Apply Policy button to save the new processing rule.
__33.
Click the Close Window link to close the policy editor.
__34.
Click Apply to save all the changes to your firewall service.
To test the decryption, you’ll first need to have an encrypted message. You’ll create an encrypted
message by calling the firewall as you did earlier, but this time you’ll capture the output to a file, then
repost for decryption.
Page 64
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__35.
Back in the command window, type the following command:
post soapMsg.xml http://datapower:4nn01 > encrypted.xml
This command will save the output from curl into the file named encrypted.xml. Now you can send the
encrypted.xml file through and see that it decrypts properly. Make sure to add /decrypt to the end of the
URI.
post encrypted.xml http://datapower:4nn01/decrypt
If you’ve configured everything properly, you should be able to read the body of the message again.
7.4
Field Level Encryption
Now we’ll modify the encrypt action so that only a specific XML tag will be encrypted. Specifically, we’ll
configure the action to encrypt the contents of the <brand> tag.
__36.
Re-open the policy editor by clicking on the ellipses
button.
__37.
In the Configured Rules section, click on the last rule (the one with the most action icons) in the
list to bring up the default processing rule (it may be named MyXmlFW_request).
__38.
Double click on the encrypt action
__39.
In the Message Type section, choose Selected Elements. Notice that after you make this
choice, a new field, Document Crypto Map will appear.
in the policy rule.
The Document Crypto Map is used to tell the encryption action how to find the element(s) that are to be
encrypted. Since the document will be in XML, the most natural way of selecting the target elements
would be with an XPath expression. The Document Crypto Map represents a collection of XPath
expressions which will be executed in order to find the target elements to encrypt.
Since we want to encrypt the <brand> element, we’ll create a Document Crypto Map that contains this
XPath expression: //brand
__40.
Click on the plus button
__41.
Type a name for the Document Crypto Map. For this example, you can type: MyCryptoMap.
WS Security: Encryption & Decryption
next to the Document Crypto Map dropdown.
Page 65
IBM
__42.
In the XPath expression field, type //brand, then click the Add button to add this XPath to the
list of expressions. The window should look like the following image:
__43.
Click the Apply button to save the document crypto map.
__44.
Click the Done button to save the changes to the encrypt action.
__45.
Click the Apply Policy button in the policy editor to save these changes.
__46.
Click the Close Window link to close the policy editor.
Before trying this out, let’s learn about a powerful debugging tool called the probe.
7.5
Working with the Transaction Probe
So far, the processing rules that we’ve created have been relatively simple, but even with simple rules,
sometimes you don’t get the results you expect. The probe provides a very powerful way to determine
which action may be at fault. The probe provides an execution trace and snapshot of each action in the
processing rule.
We’ll start by enabling the probe, then running a transaction through the service. Once we’ve done that,
we’ll refresh the probe and take a look at the transaction under the microscope.
__47.
In the Configure XML Firewall page, click on the Show Probe link (see below).
__48.
In the pop-up probe window, click the Enable Probe button to start the probe.
__49.
Click on the Close button in the confirmation window.
Page 66
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Now run a transaction through the service.
__50.
Type the following command, and replace the N with your student number, and the url with the
URL provided by the instructor.
post soapMsg.xml http://datapower:4nn01
If you look closely at the output, you will notice that the SOAP body is NOT encrypted; however the
<brand> element has been encrypted.
__51.
Click the mouse back in the probe window, and then click on the Refresh button.
__52.
You should be able to see a transaction with a magnifying glass in the left margin.
__53.
Click on the magnifying glass to inspect this transaction. You should see the contents of the
transaction similar to the following image.
WS Security: Encryption & Decryption
Page 67
IBM
In the top section of the window, there is an icon representing each of the actions in the processing rule
you created: schema validate, filter SQL injection threats, transform, sign, encrypt, and results. In front
of each action icon is a magnifying glass. Clicking on the magnifying glass will reveal what the input to
the action was. When the first magnifying glass is highlighted, the original inbound XML document is
shown.
__54.
Click on the magnifying glass in front of the sign action
is fed into the action as input.
__55.
Click on the magnifying glass in front of the encrypt action (this may show as either
or
depending on firmware version). Notice that the XML document now contains a digital signature.
This document represents the input to the encrypt action.
__56.
. Notice that the document still
Click on the magnifying glass in front of the results action
contains all the WS-Security Digital Signature information in the SOAP header, but also has the
<brand> element obfuscated by the field-level encryption.
__57.
Click on the last magnifying glass (farthest right). The document displayed represents what is
forwarded on to the server (or back to the client in the case of a loopback).
__58.
Close the transaction window.
__59.
Close the probe window.
__60.
Click the Save Config button in the top right part of the page to save all of your configuration
changes into the device’s flash memory.
7.6
Summary
. The XML document displayed is what
In this lab exercise, you learned how to configure a processing rule to encrypt all or part of an inbound
message. Selecting field level encryption involved providing a collection of XPath expressions (the
Document Crypto Map) that identify which elements to encrypt. You configured another processing rule
that decrypts the inbound message.
You also got a chance to work with the probe. The probe provides extensive details about the lifetime of
a transaction’s request and response (since we’re working with a loopback, you only got to see the
request half). An audit trail of each action exists, with input and output, along with any relevant protocol
details. The probe is used for development and troubleshooting.
Page 68
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 8
Authentication and Authorization with LDAP
Up until now, you’ve seen how DataPower can protect your Web services against malformed XML, XML
Threats, and SQL Injection threats. In this lab exercise, you’ll see how DataPower can also provide
authentication, authorization and audit services. Collectively, these three parts are referred to as AAA.
In this lab exercise, you’ll modify your XML Firewall service you created earlier to provide authentication
and authorization for the inbound message. The goals of this lab are to:

Extract a user name and password from the WS-Security UserNameToken.

Authenticate the user against a remote LDAP.

Authorize the user using a remote LDAP.

Create a SAML assertion and insert it into the SOAP header.
8.1
AAA Policy Overview
An AAA (Authentication, Authorization, Audit) Policy, sometimes referred to as an Access Control Policy,
identifies a set of resources and procedures used to determine whether or not a requesting client is
granted access to a specific service, file, or document. AAA policies are thus filters in that they accept or
deny a specific client request. Basic Access Control Policy processing is depicted in the figure below.
XS40 AAA Framework
Extract
Resource
SOAP/
XML
Message
Map
Resource
Web Service URI
SOAP op name
Transfer amount
Extract
Identity
SAML assertion
Non-repudiation
Monitoring
Authorize
Authenticate
Audit &
Accounting
SOAP/
XML
Message
Map
Credentials
SAML
WS-Security
SSL client cert
HTTP Basic-Auth
External Access Control Server or
On-Board Policy
Initial processing (common to all policies) consists of extracting the claimed identity of the service
requester and the requested resource from an incoming message and its protocol envelope. As you
define an AAA policy, extraction methods are specified by a series of check boxes that enable one or
more identity and resource extraction methods. A wide range of identity and resource extraction methods
are supported. For example, identity can be based on IP address, account name/password, SAML
assertion, or other criteria; while the requested resource can be specified by (among others) an HTTP
URL, a namespace, or a WSDL method.
Authentication and Authorization
Page 69
IBM
After extracting the service requester identity and resource, the policy authenticates the claimed identity.
Authentication is most commonly accomplished via an external service (for example, a Tivoli Access
Manager or LDAP server), but other custom processing methods, such as site-specific XML- or XPathbased solutions, are readily supported. During policy definition, you select a single authentication method
from a menu of supported methods, and (depending upon the selected method) provide a few items of
additional required information, such as a server address or the URL of a custom processing resource.
Successful server-based authentication generates a set of credentials attesting to the service requester’s
identity. These credentials can then be mapped into another set more appropriate for the authorization
method selected. This optional mapping can be accomplished by an XPath expression, an XML mapping
file or a custom method.
As with identity credentials, the extracted resource name can also be mapped to something more
appropriate for the authorization method selected. The methods for achieving this optional mapping are
the same as those for credential mapping.
The resulting credentials, along with the resulting resource name, form the basis for client authorization,
which determines if the now identified client has access to the requested resource.
Like authentication, authorization is most commonly accomplished via an external service (for example,
an LDAP server or Tivoli Access Manager), but other custom processing methods, such as site-specific
XML- or XPath-based solutions are also supported. Authorization definition mirrors that of authentication.
During policy definition, you select a single authorization method, and provide a minimum of methodspecific data.
If either authentication or authorization denies access, the system generates an error, which is returned
to the calling entity (which may be the client submitting the request). This error may be handled, as with
any other errors within multi-step processing, by an on-error action or an Error rule. Either method allows
for the creation of custom error messages.
8.2
LDAP Authentication & Authorization
In this lab, you’ll be configuring an access policy to contact an LDAP server for both authentication and
authorization. DataPower performs authentication by attempting to bind to the LDAP server with the
extracted identity and password. A successful bind indicates positive authentication.
Authorization on the other hand, is not a standard feature of an LDAP, requiring organizations to define
customized schemas based on local policy. The closest authorization functionality that an LDAP can
provide without customization is “group membership”. DataPower supports this concept of LDAP group
membership.
The LDAP for this lab exercise is configured with a Group entry that contains a member attribute for each
user that is “authorized” to the group. When a request arrives, the identity is extracted and authenticated
against the LDAP. For the authorization step, we’ll check the LDAP for membership to a predefined
LDAP group.
8.3
Adding AAA to your Firewall
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
Page 70
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__3.
Click on the XML Firewall icon.
__4.
Click on the name of your firewall; you will then see the “Configure XML Firewall” page.
__5.
Under the General Configuration section, locate the Firewall Policy dropdown box and click the
ellipsis
button next to it. The policy editor will appear.
__6.
In the Configured Rules section, click on the last rule in the list to bring up the default processing
rule (it may be named MyXmlFW_request).
__7.
Click and Drag the AAA action
below).
__8.
The yellow outline indicates that the AAA action has not been configured yet. Double click the
AAA action to reveal its configuration page.
__9.
Since you haven’t created any AAA policies yet, you’ll need to create one for this action. Click on
the plus button
Wizard.
and drop it right before the schema validate action
(see
next to the AAA Policy dropdown box. This will start the AAA Creation
Authentication and Authorization
Page 71
IBM
__10.
In the first wizard page, provide a name for the policy you’re creating. For this example, use the
name MyAaaPolicy, then click the Create button.
The next page helps you to specify how to extract the user’s identity (and optionally password) from the
inbound message. The SOAP message that we’ve been experimenting with contains the user name and
password in a UsernameToken element in a WS-Security header.
__11.
Select the checkbox next to “Password-carrying UsernameToken Element from WS-Security
Header” and then click the Next button (see below).
__12.
Now you must establish how to authenticate the user. From the list of options, select Bind to
Specified LDAP Server. You’ll notice that additional configuration parameters are displayed
when you selected the LDAP option. You’ll need to provide these details before continuing.
Page 72
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__13.
Leave the LDAP Prefix with its default value of cn=.
__14.
In the LDAP Suffix field, type: ou=members,ou=datapower,dc=ibmdemo,dc=com
__15.
In the Host field, type: demoserver.
__16.
Change the LDAP version to v3.
The completed page should resemble this:
__17.
Leave the remaining fields on the display with their default values; click Next.
__18.
Now you will need to define what is being protected. Since the inbound message is a SOAP
message, we can expect that the first element in the SOAP body contains the operation being
requested. In the Define how to extract the resource page, select Local Name of Request
Element, then click Next.
__19.
In the Configure an Access Control Policy window, change the selection to Check for
Membership in an LDAP Group. After you change the selection, additional options specific to
LDAP will be displayed.
__20.
The Host should be: demoserver
__21.
The Port should be: 389
Here is where we specify the DN of the group that contains all of the members that are “authorized” to
use this service. Note that the extracted resource is not used in this scenario. There is no way to tie the
user, the group, and the resource to the LDAP without LDAP customization.
Authentication and Authorization
Page 73
IBM
__22.
For the Group DN, type: cn=MathUsers,ou=datapower,dc=ibmdemo,dc=com
__23.
Click the Next button.
8.4
AAA Post Processing
The last page of the AAA policy configuration wizard gives you the options of performing various post
processing tasks.
For this exercise, we want the post processing phase to add a SAML assertion to the message’s SOAP
header. The system will automatically insert details from both the authentication and authorization
phases into the SAML assertion.
__24.
Click the on radio button next to Generate a SAML Assertion.
__25.
In the SAML Version dropdown, select: 2.0
__26.
Leave the remaining fields with their default values, and click the Commit button to create the
AAA policy.
__27.
Click the Done button in the creation confirmation window. You should be returned to the original
Configure AAA Action window. Notice that it has chosen the MyAaaPolicy for you.
__28.
Click the Done button to create the AAA Action.
__29.
Click the Apply Policy button to make all the changes active.
__30.
Click the Close Window link to close the policy editor.
__31.
Click the Apply button in the XML Firewall Configuration page to save all the changes to your
firewall service.
__32.
Click on the Show Probe link.
__33.
Click Enable Probe; then dismiss the confirmation dialog.
You’re now ready to try the service with the AAA policy.
__34.
Open a command window and navigate to the student/artifacts directory.
__35.
Type the following command, and replace the N with your student number, and the url with the
URL provided by the instructor.
post soapMsg.xml http://datapower:4nn01
The first thing to notice is that the request was successful, which means that the user and password in
the SOAP message successfully authenticated, and that the user was authorized to the action being
performed.
Page 74
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Now scroll the command window back to the beginning of the output. Notice that a SAML assertion has
been inserted into the SOAP header.
Now would be a good time to take another look at the probe and see the details associated with the
execution of the AAA policy.
__36.
In the “XML Firewall Configuration” page, click on the Show Probe link to view the transaction
list.
__37.
Click on the AAA icon to view the probe details for that action (see below).
Authentication and Authorization
Page 75
IBM
The Extension Trace shows all of the actions that occurred during the AAA policy execution.

Sequence # 1 is the LDAP authentication. If you click on the (show nodeset) link under the
request column, you can see the details that were sent to the LDAP server. The (show nodeset)
link under the response column shows what was returned from the LDAP.

Sequence # 2 is the LDAP authorization.
Now let’s send a message that will be rejected. The file soapNotAuthorized.xml is the exact same
SOAP message as the one you’ve been sending, except that the user is joshua instead of david, and
joshua is not permitted to access this SOAP action (as defined in the XACML policy file).
__38.
Close the probe details window, and then close the probe transaction list.
__39.
Type the following command, and replace the N with your student number, and the url with the
URL provided by the instructor.
post soapNotAuthorized.xml http://datapower:4nn01
The request should be rejected by the policy (see below).
__40.
Click the Apply button in the Configure XML Firewall page.
__41.
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
8.5
Summary
In this lab exercise, you added an access policy (AAA) to your XML Firewall service. You configured it to
extract the user’s identity and password from a WS Security UsernameToken, and then authenticate and
authorize it against an LDAP. Finally, in the post processing actions, you requested that a SAML 2.0
assertion be generated and inserted into the SOAP header.
You verified that the policy was working correctly by submitting a transaction with an authorized user,
and then a subsequent one that specified an unauthorized user.
Finally, you used the probe to investigate the execution details of a specific action.
Page 76
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 9
Customizing AAA with XSLT
Previously you saw how to define an access policy that contacts an LDAP server to authenticate a user,
and then check the user for group membership within the LDAP. Although checking for group
membership is a simple and effective way of authorizing a user, the inability to dynamically tie a resource
to an LDAP limit its usefulness in more complicated authorization scenarios. Additionally, there are times
when an organization may have a home-built authentication or authorization system that DataPower has
no knowledge of. In these cases, it becomes necessary to extend (or customize) the built-in AAA flow.
In this lab, you’ll learn how an access policy can be customized for nearly any set of unique
circumstances. The goals of this lab are to learn about:

Customizing an AAA policy to match a specific LDAP schema for authorization

DataPower’s XSL Extension Function for searching an LDAP
To refresh your memory, the following diagram shows the basic flow of an AAA policy:
XS40 AAA Framework
Extract
Resource
SOAP/
XML
Message
Map
Resource
Web Service URI
SOAP op name
Transfer amount
Extract
Identity
SAML assertion
Non-repudiation
Monitoring
Authorize
Authenticate
Audit &
Accounting
SOAP/
XML
Message
Map
Credentials
SAML
WS-Security
SSL client cert
HTTP Basic-Auth
External Access Control Server or
On-Board Policy

Extract Identity (EI): establishes an asserted identity from the contents of the message or protocol
envelope.

Extract Resource (ER): identifies the requested resource (commonly a URI, or SOAP action).

Authenticate (AU): authenticates the asserted identity. The identity is either approved or
disapproved.

Map Credentials (MC): transform or replace the extracted identity with another value, which may
or may not be based in whole or in part on the extracted identity. This step is optional.

Map Resource (MR): transform or replace the extracted resource with another value, which may
or may not be based in whole or in part on the extracted resource. This step is optional.

Authorize (AZ): permit or deny the use of the mapped resource. This step is optional.

Post Processing (PP): perform additional transformations, processing, or security mediation on
the results of the previous steps.
In this lab, you’ll see how any of the seven steps can easily be customized. Specifically, you’ll be
customizing the authorize step.
Customizing AAA with XSLT
Page 77
IBM
XS40 AAA Framework
Extract
Resource
SOAP/
XML
Message
Map
Resource
Web Service URI
SOAP op name
Transfer amount
Extract
Identity
SAML assertion
Non-repudiation
Monitoring
Authorize
Authenticate
Audit &
Accounting
SOAP/
XML
Message
Map
Credentials
SAML
WS-Security
SSL client cert
HTTP Basic-Auth
External Access Control Server or
On-Board Policy
9.1
The Scenario
Acme Math Services (AMS) has created a Web service to provide basic arithmetic functions to other
local organizations. Foo-Bar, LLC, has recently entered into a service agreement with AMS to provide
math services to its growing employee base. As a result of a growing customer base and increased
demand for standardized math services, AMS has decided to employ DataPower technology to guard
their coveted Math Service. To manage their user base, AMS setup an LDAP server with the following
hierarchy:
The ou MathFunctions has child leaves for each of the four math operations. Each of the leaves contain
member attributes for each user that is permitted to use that particular function. For “add” and “subtract”,
only David and Sarah are authorized. For multiplication and division, only Ariel and Joshua are
authorized.
Page 78
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
The math operations correspond directly to the request element of inbound SOAP messages (see below)
<soapenv:Body>
<math:add>
<augend>308</augend>
<addend>20</addend>
</math:add>
</soapenv:Body>
9.2
The Customized Solution
To accomplish this form of authorization, we’ll extend DataPower’s AAA engine by creating a single
stylesheet that replaces just the authorization step of an AAA policy. When the AAA policy is executed, it
will extract the identity from the WS-Security UsernameToken element, it will then bind that user to the
configured LDAP. The resource will be extracted from the local name of the request element, and then
the DataPower AAA engine will execute your custom authorization stylesheet.
When creating the stylesheet, you need to know what the input will be, and what the expected output
should be. The documentation states that the input XML document will contain the mapped credentials,
the mapped resource, the identity, and some additional ancillary information. Here’s an example of the
input document to a custom authorization stylesheet:
<?xml version="1.0" encoding="UTF-8"?>
<Request
xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os
access_control-xacml-2.0-context-schema-os.xsd">
<Subject>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>david</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>product-info</AttributeValue>
</Attribute>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>execute</AttributeValue>
</Attribute>
</Action>
<Environment/>
</Request>
The documentation specifies that the output for the stylesheet should be a single root node that is either
<approved/> or <declined/>. Anything other than <approved/> will be interpreted as an authorization
failure.
Your stylesheet will thus receive a document similar to the one above; then it must:
1. Query the LDAP for all members of the requested operation (i.e. add, subtract, etc.)
Customizing AAA with XSLT
Page 79
IBM
2. If the credentials are then found within the returned members, the request is “approved”.
At this point, you may be wondering how it is possible to query the LDAP server from within an XSL
stylesheet. This is accomplished using one of DataPower’s XSL extension functions – the ldap-search
function.
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:dp="http://www.datapower.com/extensions" extension-element-prefixes="dp"
exclude-result-prefixes="dp" version="1.1">

<xsl:variable
<xsl:variable
<xsl:variable
<xsl:variable
<xsl:variable
name="ldapDnPrefix" select="'cn='"/>
name="ldapDnSuffix" select="'ou=MathFunctions,ou=datapower,dc=ibmdemo,dc=com'"/>
name="ldapAttribute" select="'member'"/>
name="ldapHost" select="'demoserver'"/>
name="ldapPort" select="'389'"/>
<!--+
| The following variables should not need modification.
+-->
<xsl:variable name="opName"
select="/container/mapped-resource/resource/item[@type='request-opname']"/>
<xsl:variable name="targetDN" select="concat($ldapDnPrefix,$opName,',',$ldapDnSuffix)"/>


<xsl:variable name="members"
select="dp:ldap-search($ldapHost,$ldapPort,'','',$targetDN,$ldapAttribute,'','base','','')"/>
<xsl:variable name="subjectDN" select="/container/mapped-credentials/entry[@type='ldap']"/>
<xsl:template match="/">
<xsl:choose>
<xsl:when test=
"$members/LDAP-search-results/result/attribute-value[@name=$ldapAttribute]=$subjectDN">
<approved/>
</xsl:when>
<xsl:otherwise>
<decline/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>
Here’s what’s going on in the stylesheet:
1. Variables are defined that make the stylesheet more flexible as well as simplifying later string
functions. ldapDnPrefix and ldapDnSuffix are combined with the extracted resource to form the
DN of the group element in the LDAP. If the extracted resource is “add”, then the target DN will
be:
cn=add,ou=MathFunctions,ou=datapower,dc=ibmdemo,dc=com
2. The ldap-search extension function is used to search for all “member” attributes for the provided
DN. The $ldapAttribute variable contains the value “member”. The results of the search are
placed in the $members XSL variable.
3. Finally, an XPath statement is used to see if the extracted credential (userId) is found in the
returned list of members for the add function. If it is, the stylesheet writes <approved/> to the
output context, otherwise it writes <declined/>
9.3
Using a Custom Stylesheet for Authorization
For this lab, you’ll create a new XML Firewall.
__1.
Page 80
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Click on the XML Firewall icon.
__4.
Click the Add Wizard button.
__5.
Select the Access Control (AAA) radio button, then click the Next button.
__6.
For the Firewall Name, type: MyCustomAaaFW.
__7.
Click Next.
__8.
For the Firewall Type, select: loopback-proxy.
__9.
Click Next.
__10.
Leave the Device Address with the default value of 0.0.0.0, and specify the port number as
4nn06, where nn is your student number. For example, if your student number is 3, use port
4306. If your student number is 14, use port 41406. Leave the SSL prompt as “off”.
__11.
Click Next.
The wizard will now help you create a new AAA policy for this firewall. You may notice that the AAA
policy you created in the previous lab shows up in the AAA Policy dropdown list. For this exercise, we’ll
be creating a brand new AAA policy that will use our custom stylesheet for authorization instead of LDAP.
The policy will extract the subject from a password-carrying username token, and the resource from the
SOAP action (local name of request element).
__12.
Click the plus button next to the AAA policy dropdown box. The AAA Wizard will open.
__13.
For the AAA Policy Name, type: MyCustomAaaPolicy
__14.
Click the Create button.
The first step in creating the AAA policy is to specify how the subject (user id) and password is extracted
from the inbound message. The inbound message will contain the username and password in a
WS-Security header with a UsernameToken element.
__15.
Select the checkbox for Password-carrying UsernameToken Element from WS-Security
Header.
__16.
Click the Next button.
The next page defines how to authenticate the user. For this lab, we’ll authenticate the user against an
LDAP.
__17.
Select the Bind to Specified LDAP Server radio button.
__18.
Leave the LDAP prefix as: cn=
Customizing AAA with XSLT
Page 81
IBM
__19.
For the LDAP Suffix, type: ou=members,ou=datapower,dc=ibmdemo,dc=com
__20.
For the Host, type: demoserver
__21.
Towards the end of the list, change the LDAP version to: v3
__22.
Leave the remaining fields on the display with their default values; Click the Next button.
Now you’ll define what resource is to be protected. Traditionally, the first element in the SOAP body is
referred to as the request element. It represents the SOAP action being requested. You’ll use this as the
resource to be protected.
__23.
Select the checkbox for: Local name of Request Element
__24.
Click the Next button.
The next page displayed allows you to configure how to authorize the request. It is here that you’ll upload
and then specify a custom stylesheet.
__25.
Select the radio button for Custom Template.
__26.
At the bottom of the window, you’ll see an area to specify the URL for the custom stylesheet.
You’ll need to upload the stylesheet from your student/artifacts directory. Make sure that the left
dropdown list contains local:///, then click the Upload button, browse, select, and upload the file:
customLdapAz.xsl
__27.
Click the Next button.
__28.
Click the Commit button to save the new AAA policy.
__29.
Click the Done button to save the new AAA action.
__30.
Click the Next button to continue the XML Firewall wizard.
__31.
Click the Commit button to save the new XML Firewall.
__32.
Click the Done button to close the status window.
Assuming everything was done right, the custom stylesheet will now perform the authorization step of
your AAA policy. Let’s test it out and see what happens in the probe.
Before you start testing, let’s make sure the debug probe is enabled.
__33.
Click on the Troubleshooting icon.
__34.
Click on the Debug Probe tab at the top of the page.
__35.
In the XML Firewall Service section, make sure the MyCustomAaaFW has the probe enabled. If
it’s not enabled, click on the Add Probe button, then dismiss any confirmation windows that
open.
Page 82
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Now let’s run a transaction through your firewall service.
__36.
Type the following command, and replace the N with your student number, and the url with the
URL provided by the instructor.
post soapAdd.xml http://datapower:4nn06
If the transaction was successful, it should be echoed back to you in the command window as in earlier
labs.
Now let’s look at the probe and see what happened under the covers.
__37.
Back in the browser window, in the previously opened troubleshooting page, on the
“Debug Probe” tab, click on the magnifying glass for the probe next to MyCustomAaaFW (see
below).
Customizing AAA with XSLT
Page 83
IBM
__38.
In the transaction window, click on the magnifying glass to reveal the transaction details. If there
is more than one transaction, click on the one with the highest transaction number.
The details of the transaction will be opened up as in the following image.
The contents of the inbound message are shown first (this is referred to as the INPUT context).
Page 84
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__39.
Click on the AAA action icon
to reveal the execution details of the AAA action.
In the Extension Trace tab, you can see the three steps that occurred during the AAA policy execution.
The first step represents the authentication phase. The policy was configured to bind to an LDAP server
with the credentials extracted from the inbound message. Click on the (show nodeset) links for both the
request and response. The request shows the details that were used to bind to the LDAP server, and the
response shows what was returned from the LDAP. If the response is empty, then the bind failed.
The third step in the list shows the details pertaining to the execution of the custom stylesheet that
performs the authorization. Remember that one of the actions within the stylesheet was an LDAP search.
The details of the LDAP search are shown in sequence # 2. Here are the results of the ldap-search:
Let’s try a negative test now. We’ll post the same SOAP message, but that specifies an unauthorized
user.
Customizing AAA with XSLT
Page 85
IBM
__40.
Type the following command, and replace the N with your student number, and the url with the
URL provided by the instructor.
post soapAddNotAuth.xml http://datapower:4nn06
The request should be rejected by the policy.
__41.
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
9.4
Summary
In this lab, you learned that any one of the seven steps in an AAA policy can be replaced with a custom
written stylesheet. You created a customized AAA policy that performs standard LDAP authentication,
but customized LDAP authorization. In order to perform the customized LDAP authorization, an XSL
stylesheet was created that utilized the ldap-search DataPower extension function to search the LDAP
for members of a dynamically selected group. XPath was then used in the stylesheet to determine if the
extracted user’s DN is within the list of members returned from the LDAP. If it was found, the
authorization succeeded, otherwise it was rejected.
Page 86
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 10
AAA with XACML (Optional Lab)
In the previous lab, you created and configured an AAA policy that communicated with an LDAP to
authenticate and authorize the request. In this lab, you’ll create another AAA policy that authenticates the
user against an LDAP (exactly as in the previous lab) but will perform authorization using XACML.
The goals of this lab exercise are to:

Gain exposure to DataPower’s onboard support for XACML

Understand the basic fundamentals of XACML based authorization.
10.1 XACML Overview
XACML, which is short for Extensible Access Control Markup Language, is a W3 specification that
defines a way to use XML to describe security policies. Most existing policy servers are proprietary and
not interoperable with each other, making it difficult, if not impossible, to integrate various systems or
migrate to a new one. XACML aims to define a standard way of not only describing in full detail, an
enterprise’s security policy, but to define a standard XML-based set of messages for communication
within the various components that comprise the overall security system. With XACML, the security
system essentially becomes plug-and-play.
As in most security setups, XACML employs two primary components to carry out authorization requests:
the Policy Enforcement Point (PEP), which acts as the gatekeeper, and the Policy Decision Point (PDP),
which acts as the decision maker. Of course there may be other components at play behind the scenes,
but these are the two parts that we’ll focus on in this lab.
As the gatekeeper, it’s the policy enforcement point’s responsibility to extract and consolidate the various
bits of information from the inbound request and create a XACML authorization request document. The
authorization request document contains the subject (user ID, etc.), the resource (requested URL, SOAP
action, etc.) and the action (execute, read, etc.). The authorization request document is then sent to a
policy decision point which makes the “permit” or “deny” decision. The decision is returned as a XACML
authorization response document to the PEP which then either permits or denies the request.
As the decision maker, the policy decision point contains the enterprise security policies that govern
access to the resource in question. When the XACML request document arrives, it extracts the subject,
resource, and action and determines whether the user has the necessary privileges.
The basic XACML structure is shown in the following diagram.
AAA with XACML
Page 87
IBM
10.2 The XACML Policy Document
The XACML Policy Document describes, in excruciating detail, a security policy. As you may expect, it is
well beyond the scope of this document to explain how to write a XACML security policy, but you’ll be
working with a fully functional simple one that we’ll look at in some detail.
Let’s assume for a moment, that you’re starting with a freshly installed ACME policy server. The ACME
server is fully XACML enabled. It has a great Web-based GUI, but you’re exceptionally bright and have
mastered writing XACML policy without the help of any tools. The ACME policy server has a XACML
import function that imports the XACML policy file, providing one-step configuration of your entire security
system. Consequently, it’s altogether possible that your previous policy server supported XACML and
you simply exported the policy file, but who are we to doubt you?
The XACML document you wrote is named xacml-pot-policy.xml and is found in the artifacts
directory. With whatever editor you have at hand, open this file up and take a look at its structure.
The policy is basically comprised of a collection of rules, which either result in a “permit” or “deny”
decision. Within each rule are targets that contain four sections: subjects, resources, actions, and
conditions. These sections match closely with the details found in a XACML authorization request. When
the authorization request arrives, the subject, resource, and action are extracted and then looked up
within the policy. If the subject is found within the subjects, and the resource is found within the resource,
and the action is found in the actions, and any additional conditions are met, then the rule will return
either permit or deny as specified in the rule’s effect attribute (it’s possible to say that if all these
conditions passed that the request should be denied).
10.3 The XACML Authorization Request Document
When a request arrives at the policy enforcement point, the PEP will create a XACML authorization
request document and send it to the PDP.
As we’ve already discussed, the XACML request contains the subject, resource, and action to be
evaluated by the PDP. The following XACML authorization request is for a subject named “david”, a
resource named “product-info”, and an action of “execute”.
<Request>
<Subject>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>david</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>product-info</AttributeValue>
</Attribute>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>execute</AttributeValue>
</Attribute>
</Action>
<Environment/>
</Request>
Page 88
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
10.4 DataPower’s Role in the XACML Story
Now that you understand the basic fundamentals of XACML, we can explore how DataPower appliances
fit into the XACML story.
It’s probably become obvious that DataPower can naturally act as the PEP, receiving inbound requests,
invoking an AAA action that creates a XACML authorization request and sends it to a PDP. But in fact, it
can also act as a PDP. IBM DataPower security appliances fully understand XACML policy file semantics.
The same XACML policy file that you would upload into the ACME policy server can be uploaded into a
DataPower PDP object, allowing the appliance to act as the PDP for other PEPs.
10.5 How it’s done
The process begins with an AAA policy. As you’ve seen in previous labs, the AAA policy allows you to
specify exactly how to extract the subject and resource from an inbound request. Once the subject and
resource have been identified, DataPower will pass them to stylesheet that results in a XACML
authorization request. That request will be sent to the designated PDP (that you’ll be creating).
In addition, you’ll create a PDP on the DataPower device. This is a simple process that only requires
uploading the XACML policy file.
First, let’s create the Policy Decision Point.
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Using the File Manager, upload the file xacml-pot-policy.xml into the local:/// directory. You’ll use
the same procedure that you used in lab 1, in section 1.4, “DataPower’s On-Board File System”.
__4.
In the left hand navigation pane, click on OBJECTS and then locate the Access section (you will
need to scroll down).
__5.
Within the Access section, click on XACML Policy Decision Point.
__6.
In the Configure XACML Policy Decision Point page, click the Add button.
__7.
In the Name field, type: MyXacmlPDP
__8.
In the General Policy File field, type: local:///xacml-pot-policy.xml (Make sure you type this
exactly as shown, with three slashes and all lowercase letters)
AAA with XACML
Page 89
IBM
The completed page should look similar to this:
__9.
Click the Apply button to create the XACML PDP.
Now you’ll create a new XML Firewall and an associated AAA Policy that uses the XACML PDP for
authorization.
__10.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__11.
Click on the XML Firewall icon.
__12.
Click the Add Wizard button.
__13.
Select the Access Control (AAA) radio button, then click the Next button.
__14.
For the Firewall Name, type: MyXacmlFW.
__15.
Click the Next button.
__16.
For the Firewall Type, select: loopback-proxy.
__17.
Click the Next button.
__18.
Leave the Device Address with the default value of 0.0.0.0, and specify the port number as
4nn07, where nn is your student number. For example, if your student number is 03, use port
40307. If your student number is 14, use port 41407. Leave the SSL prompt as “off”.
Page 90
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__19.
Click Next.
The wizard will now help you create a new AAA policy for this firewall. You may notice that the AAA
policy you created in the previous lab shows up in the AAA Policy dropdown list. For this exercise, we’ll
be creating a brand new AAA policy that will use XACML for authorization instead of LDAP. The policy
will extract the subject from a password-carrying username token, and the resource from the SOAP
action (local name of request element).
__20.
Click the plus button next to the AAA policy dropdown box. The AAA Wizard will open.
__21.
For the AAA Policy Name, type: MyXacmlPolicy
__22.
Click the Create button.
The first step in creating the AAA policy is to specify how the subject (user id) and password is extracted
from the inbound message. The inbound message will contain the username and password in a WSSecurity header with a UsernameToken element.
__23.
Select the checkbox for Password-carrying UsernameToken Element from WS-Security
Header.
__24.
Click the Next button.
This page defines how to authenticate the user. For this lab, we’ll authenticate the user against an LDAP.
__25.
Select the Bind to Specified LDAP Server radio button.
__26.
Leave the LDAP prefix as: cn=
__27.
For the LDAP Suffix, type: ou=members,ou=datapower,dc=ibmdemo,dc=com
__28.
For the Host, type: demoserver
__29.
Towards the end of the list, change the LDAP version to: v3
__30.
Leave the remaining fields on the display with their default values; Click the Next button.
Now you’ll define what resource is to be protected. Traditionally, the first element in the SOAP body is
referred to as the request element. It represents the SOAP action being requested. You’ll use this as the
resource to be protected.
__31.
Select the checkbox for: Local name of Request Element
__32.
Click the Next button.
With the information collected this far, you now have enough detail to authorize the request. In the
current wizard page, you will specify how the request is to be authorized. This is where you will direct the
AAA policy to contact a XACML Policy Decision Point.
__33.
Select the radio button for: Use XACML Authorization Decision
__34.
For the XACML PDP, select MyXacmlPDP from the dropdown list.
AAA with XACML
Page 91
IBM
__35.
In the Custom Stylesheet to Bind AAA and XACML, click the Upload button.
__36.
In the Upload File pop-up dialog, navigate to the student/artifacts directory and select the file
named: xacml-pot-request-binding.xsl. Once it’s selected, click the Upload button.
__37.
Click Continue in the upload confirmation window.
The stylesheet you just uploaded will generate the XACML Authorization Request document that will be
sent to the PDP. This stylesheet will take the subject and resource that were extracted in the previous
AAA steps, and insert them into the appropriate parts of the authorization request document.
The completed wizard page should look like this:
__38.
Click the Next button.
This AAA policy doesn’t require any post processing steps, so you can leave all of the fields at their
default values.
__39.
Click the Commit button to create the AAA policy.
__40.
Click the Done button.
__41.
Click the Next button to complete the XML Firewall wizard.
Page 92
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__42.
Click the Commit button to save the XML Firewall.
__43.
Click the Done button to dismiss the page showing the status of all created objects.
Now enable the probe so that you can see the various steps that get executed when a message arrives.
This time, you’ll enable the probe from the troubleshooting page.
__44.
From the control panel, click on the Troubleshooting icon.
__45.
Click on the Debug Probe tab.
__46.
Locate the group “XML Firewall Service”. In the dropdown list, select MyXacmlFW, then click the
Add Probe button to enable the probe for just that firewall. After the page refreshes, notice that
the MyXacmlFW is now listed with a small magnifying glass under the Probe column.
You’re now ready to send a SOAP message to this firewall.
__47.
From a command prompt, type the following command:
post soapAdd.xml http://datapower:4nn07
If everything was created correctly, you should receive the original message echoed back to the console
window. If not, you may need to double check your selections and typing to make sure you created the
firewall and AAA policy correctly. Also make sure to check the logs to see if there are any clues as to the
cause of the failure.
__48.
Back in the Troubleshooting Panel, click on the small magnifying glass you identified when you
enabled the probe. The transaction window will be displayed.
AAA with XACML
Page 93
IBM
__49.
Click on the small magnifying glass to show the details of the transaction you just sent through
the firewall (your screen may be slightly different)..
The contents of the inbound message are shown first (this is referred to as the INPUT context). Now click
on the AAA action icon
to reveal the execution details of the AAA action.
Page 94
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
In the preceding screen image, you can see some of the details relating to the various steps of the AAA
policy. In sequence 1, you can see the details relating to the LDAP authentication. Click on the show
nodeset link under the request to see the details of the request made to the LDAP, then close that
window and click on the show nodeset link for the response which came back from the LDAP.
The second sequence is the transform that took the AAA details and merged them into the XACML
authorization request. If you click on the show nodeset link under the request column, you can see that
the input document to the transform is the original inbound request that you sent. This gives the
stylesheet the ability to extract any details it may need that weren’t extracted during the standard AAA
policy steps. Click the show nodeset link under the response column to see the resultant XML
document (the authorization request). This document is the results of the transform using the xacml-potrequest-binding.xsl stylesheet.
The final sequence (#3) shows the details related to contacting the PDP. Clicking the show nodeset link
under the request column will show you the XACML Authorization Request document that will be sent to
the PDP, and clicking the show nodeset link under the response will show what response was returned
from the PDP.
__50.
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
10.6 Summary
In this lab exercise, you learned that XACML itself is not a policy server; rather it’s a standard way of
describing security policies using XML. You learned that a policy enforcement point acts as the
gatekeeper for inbound requests, and that the policy decision point acts as the decision maker as to
whether the request is authorized or not. The PEP will contact the PDP using a predefined XML
message that is described in the XACML specification.
Components that understand XACML are theoretically plug-and-play with each other. A policy
enforcement point is indifferent as to the vendor of the PDP (and visa versa). If a policy server has the
ability to export its policy as XACML, it can be imported into a DataPower PDP object, and DataPower
can act as a PDP without any additional configuration.
You saw that DataPower’s AAA policy acts as the PEP and creates the authorization request by
extracting the subject and resource from the inbound request, and passing them to a stylesheet that
creates the authorization request document.
Finally, using the probe, you saw how the various steps were executed.
AAA with XACML
Page 95
IBM
Page 96
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 11
Protocol Level Security: SSL/HTTPS
In this lab exercise, you’ll create the necessary objects to add protocol level security to the firewall
service you’ve been working on.
The goals of this lab exercise are to:

Change the XML Firewall to use SSL
11.1 Adding SSL
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Click on the XML Firewall icon.
In the list of XML Firewalls, you should see the one you created in the previous labs. It will look similar to
this image:
__4.
Click on the name of your firewall (MyXmlFW); you will then see the Configure XML Firewall
page.
Protocol Level Security: SSL/HTTPS
Page 97
IBM
__5.
Locate the SSL Server Crypto Profile field on the right side towards the bottom of the window
(see below), and click the plus button
to create a new SSL Server Crypto Profile.
The Configure Server Side SSL form will be displayed.
__6.
In the Profile Name field, enter MySslProfile.
In the Server Credentials section:
__7.
In the Server Private Key dropdown, select datapower.ibm.com-privkey.pem.
__8.
In the Server Certificate dropdown, select datapower.ibm.com-sscert.pem.
In the Trusted Clients section:
__9.
Click the Upload button to upload the client certificate from your PC.
__10.
Click the Browse button to browse your PC for the client certificate.
__11.
From the student/keysAndCerts directory, select client-sscert.pem, then click Open.
__12.
Click the Upload to start the upload.
Page 98
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__13.
Click the Continue button to dismiss the confirmation dialog.
__14.
Click the Add button to add this certificate to the trusted certificate collection.
__15.
Click the Apply button at the top of the form to save the entire form and create the SSL Profile.
__16.
Click the Apply button at the top of the XML Firewall Configuration page to save the changes to
the firewall service.
At this point, your firewall service is now protected at the protocol level, requiring clients to adhere to SSL
handshaking protocol.
Let’s try posting a message to the service as we did earlier, without any SSL protocol.
__17.
Open a command window and navigate to the student/artifacts directory.
__18.
Test the firewall. Type the following command, and replace the N with your student number, and
the url with the URL provided by the instructor.
post soapMsg.xml http://datapower:4nn01
As expected, the service no longer responds to non-SSL requests.
Now let’s try it with an HTTPS connection instead of HTTP.
__19.
Type the following command. Notice that the post command is now sslpost and the URL begins
with HTTPS.
sslpost soapMsg.xml https://datapower:4nn01
The server should properly respond as it did before SSL was configured.
__20.
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
Protocol Level Security: SSL/HTTPS
Page 99
IBM
11.2 Summary
In this lab exercise, you created an SSL Proxy Profile that contained all of the necessary keys and
certificates that represent the server, as well as the certificates that represent the allowed clients. Once
the SSL Proxy Profile was created and assigned to the XML Firewall service, non-SSL traffic became
disallowed.
Page 100
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 12
Protecting Web Services
The Web Service Proxy, or WS-Proxy is a WSDL-based service that offers near automatic configuration,
and can:

Process SOAP requests

Filter, validate, transform, encrypt/decrypt, and validate XML documents

Perform dynamic routing

Sign documents and verify digital signatures

Implement document or service-level security

Provide fine-grained monitoring and logging, down to the WSDL operation level
In this lab exercise, you will:

Create a WS-Proxy service by uploading a WSDL.

Explore the WS-Proxy options

Use a back-end service to test the WS-Proxy service.
12.1 Create the WS-Proxy Service
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Click on the Web Service Proxy icon.
__4.
In the Configure Web Service Proxy page, click the Add button.
__5.
In the Web Service Proxy Name field, type MyWsProxy.
__6.
Click the Create Web Service Proxy button.
Protecting Web Services
Page 101
IBM
__7.
In the WSDL File URL section, click the Upload button.
__8.
Click the Browse button and open MathServer.wsdl in the student/artifacts directory.
__9.
Click the Upload button to begin the upload process.
__10.
Click the Continue button to dismiss the confirmation dialog.
__11.
Click the Next button.
__12.
In the Local Endpoint Handler field, click the plus button
Page 102
to create a new endpoint handler.
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__13.
In the pop-up menu, click on HTTP Front Side Handler.
In the Configure HTTP Front Side Handler form, use the following values:
__14.
For the Name, type MyHttpListener.
__15.
For the Port Number, use your student number as follows: 4nn02. For example, if your student
number is 14, select port 41402.
__16.
In the Allowed Methods and Versions, select the checkbox for GET (leave the others with their
default values).
__17.
Click the Apply button in the upper left corner.
Protecting Web Services
Page 103
IBM
__18.
Click the Add button.
__19.
Click the Next button. The new WS-Proxy service is now complete. You will then see that the
service is up and running.
Now that the WS Proxy service is up and running, we can run a few tests against it.
12.2 Testing the Web Service Proxy
The first test will be to obtain the WSDL from the WS Proxy (instead of the actual Web service).
__20.
Open a Web browser and type in the following URL:
http://datapower:4nn02/MathServer/services/MathServer?WSDL
The browser should display the WSDL for the MathServer Web service.
Now let’s post a transaction to the service.
__21.
Open a command window and navigate to the student/artifacts directory.
__22.
Type the following command, and replace the N with your student number.
post soapAdd.xml http://datapower:4nn02/MathServer/services/MathServer
Page 104
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
The body of the SOAP message:
<soapenv:Body>
<math:add>
<augend>308</augend>
<addend>20</addend>
</math:add>
</soapenv:Body>
Here are the results:
12.3 Adding AAA to the Web Service
The last exercise you’ll do in this lab demonstrates how objects are reusable within the DataPower
environment.
In the last lab, you created a AAA policy that required the requesting user to be authenticated against an
LDAP, and authorized against a XACML Policy Decision Point. You will now apply that same AAA policy
to the newly created Web Service Proxy.
__23.
In the Configure Web Service Proxy page, click on the tab labeled Policy.
__24.
In the Web Services Proxy Policy window, click on the link for the default request rule (see
below).
The policy editor will show the default rule for the Web service. You’ve already had experience working
with the policy editor. Now you’ll add the AAA policy you created earlier to this Web service.
Protecting Web Services
Page 105
IBM
__25.
Click and drag the AAA action
monitoring) action
and drop onto the policy rule after the SLM (service level
.
__26.
Notice that the AAA action has a yellow outline, indicating that it has not been configured yet.
Double click the AAA action to set its configuration.
__27.
In the AAA Policy dropdown list, select the previously created AAA policy,
MyCustomAaaPolicy.
__28.
For the Output field, type: AAAOutput.
__29.
Click the Done button to save the action.
__30.
At the top of the Configure Web Service Proxy page, click the Apply button to save all the
changes.
That’s it! You’ve just re-used the AAA policy that you created in an earlier lab and applied the same
policy to this new Web service.
Let’s post the message again to make sure it still works, then we’ll send one that will fail authorization.
__31.
Type the following command, and replace the N with your student number (make sure to type it
exactly including upper and lower case letters).
post soapAdd.xml http://datapower:4nn02/MathServer/services/MathServer
The service should continue to work as it did before.
__32.
Now try it with the same exact message but a different user name and password in the header.
post soapAddNotAuth.xml http://datapower:4nn02/MathServer/services/MathServer
Note that the reason for the failure is not displayed here but can be found in the DataPower logs.
__33.
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
Page 106
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
12.4 Summary
In this lab exercise, you had a brief introduction to the Web Service Proxy object. You saw how it can be
automatically configured simply by uploading a WSDL. You also saw that the process of modifying the
request policy is the same as in the XML Firewall from previous labs. Finally, you saw how DataPower
objects such as the AAA policy are reusable.
Protecting Web Services
Page 107
IBM
Page 108
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 13
WS-Policy Support
In the previous lab, you saw how the WS Proxy object can protect a Web service, and that by simply
uploading the WSDL, the WS Proxy object becomes intimately familiar with all of the available exposed
services.
In this lab, you’ll be exposed to WS-Policy and how it can be used to govern security policies for inbound
and outbound message that run through the WS Proxy.
The goals of this lab exercise are to:

Gain exposure to DataPower’s onboard support for WS-Policy.
13.1 WS-Policy Overview
WS-Policy defines a framework for allowing Web services to express their constraints and requirements.
For example, consider a Web service that requires all inbound requests to contain a WS-Security header
that contains a UsernameToken element. Typically, this information cannot be described in the WSDL. If
a Web service client were to inspect the WSDL, they would have no way of knowing the security
requirements imposed on the Web service. This information would have to be conveyed either in
embedded comments, or in person-to-person correspondence (documentation, phone, e-mail, etc.).
WS-Policy provides a way of expressing these requirements within the WSDL (or in a separate
document) that leaves no question as to what the service is expecting.
WS-Policy is not constrained to inbound messages. It can also describe constraints and requirements on
outbound responses. As you’ll see later in this lab, WS-Policy can dictate that all responses are digitally
signed or encrypted.
As you can imagine, it’s well beyond the scope of this lab to dive deeply into the WS-Policy specification,
however you will see two working examples of WS-Policy in action.
Embedded vs. Attached Policy
There are two ways of enforcing WS-Policy on a Web service. The first and most obvious way would be
to modify the WSDL to contain the WS-Policy elements. In this way, the policy becomes one and the
same with the WSDL. You’ll see an example of this in the 2nd half of this lab.
There may also be times when the WSDL cannot be modified, or a single policy should be applied to
many WSDLs. In this situation, a separate WS-Policy document can be added to an existing WSDL as a
separate “attachment”. In the first half of this lab, you’ll be adding a WS-Policy attachment to the
WS Proxy object you created in the previous lab (MathServer). The WS-Policy will require that all
inbound messages contain a version 1.0 or version 1.1 UsernameToken.
Enforce vs. Filter – DataPower helps where it can
Since DataPower is sitting between the client and the server, it can either act in a “filter” mode, or an
“enforce” mode. The difference between the two modes occurs only during response processing, not on
inbound requests.
Both filter and enforce will require that inbound messages meet all constraints and requirements. Those
that don’t meet these requirements will be rejected.
When a WS-Policy is set as a “filter”, the response from the server must meet the “output” requirements,
otherwise the request will fail. In other words, assume that the WS-Policy requirement states that all
WS-Policy Support
Page 109
IBM
outbound responses must be digitally signed. If the server returns a response that is not signed, the
entire transaction will fail.
When a WS-Policy is set to “enforce”, it will provide as much help as possible on the response. For
example, if the WS-Policy dictates that server responses are digitally signed and a response comes back
from the server that is not signed, DataPower will automatically add the digital signature to the outbound
message, thus making it conform to policy. Obviously in this case, the signing key and certificate must be
provided so that DataPower can sign the message. You’ll see an example of this in the 2nd half of this
lab.
13.2 Example 1 – Attaching a Policy
In this exercise, you’ll see how to attach a WS-Policy to the WS Proxy object you created in the previous
lab. The WS-Policy document that you’ll attach requires that all inbound messages contain either a
version 1.0 or version 1.1 UsernameToken element in the WS-Security header. Here’s what the policy
looks like:
<wsp:ExactlyOne>
<!-- UsernameToken 10 -->
<wsp:All>
<sp:SupportingTokens>
<sp:UsernameToken sp:IncludeToken="...ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</sp:SupportingTokens>
</wsp:All>
<!-- UsernameToken 1.1 -->
<wsp:All>
<sp:SupportingTokens>
<sp:UsernameToken sp:IncludeToken=".../ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken11/>
</wsp:Policy>
</sp:UsernameToken>
</sp:SupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
In the snippet above, the WS-Policy states that the inbound message must contain a combination of
wsp:All and wsp:ExactlyOne elements that, when studied, reveal that inbound messages must contain
either a version 1.0 or 1.1 UsernameToken (but not both).
Now let’s attach the policy to your WS Proxy object.
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Click on the Web Service Proxy icon.
__4.
In the list of Web Service Proxies, select: MyWsProxy
Page 110
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__5.
In the Configure Web Service Proxy page, click on the Policy tab.
__6.
Locate the WS-Policy button located in the service: section. Click the WS-Policy button.
__7.
In the pop-up WS-Policy dialog box, click on the Sources tab.
__8.
Click on the Upload button to upload a WS-Policy definition file from your student/artifact
directory.
__9.
In the Upload File dialog box, click the Browse button to locate and open the file:
wspolicy.xml
__10.
Click the Upload button.
__11.
Click the Continue button to dismiss the upload confirmation dialog box.
__12.
Click the Attach Source button to attach this WS-Policy file to the service.
WS-Policy Support
Page 111
IBM
The completed WS-Policy dialog should look as follows:
__13.
Click the Done button to close the dialog box.
Notice now that the service indicates that there is “1 external attachment”, which indicates that the
wspolicy.xml file that you just uploaded is now in effect.
__14.
Click the Apply button to save these changes to the WS-Proxy object.
To verify that the WS-Policy specifications have been integrated into the WS-Proxy object, let’s request
the WSDL again and see if the WS-Policy requirements are included.
Page 112
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__15.
Open a Web browser and type in the following URL:
http://datapower:4nn02/MathServer/services/MathServer?WSDL
__16.
Scroll the browser window all the way towards the end of the WSDL listing. You should see the
<wsp:Policy> elements that have been integrated into the original WSDL (see below).
Now that you know the WS-Policy is in effect, let’s try a positive and negative test on the WS-Proxy.
__17.
Type the following command, and replace the N with your student number, and the url with the
URL provided by the instructor (make sure to type it exactly including upper and lower case
letters).
post soapAdd.xml http://datapower:4nn02/MathServer/services/MathServer
You should receive the same results you did in the previous lab (see below).
__18.
Now try it with a SOAP request that does not contain a UsernameToken element. Type the
following command:
post soapAddNoUser.xml http://datapower:4nn02/MathServer/services/MathServer
WS-Policy Support
Page 113
IBM
Notice this time that the request was rejected since the UsernameToken element could not be located.
13.3 Example 2: WSDL Embedded WS-Policy
In this exercise, you’ll first go back and remove the WSDL that you previously loaded. You’ll be uploading
a new WSDL that will contain an embedded WS-Policy.
This time, the WS-Policy will be a little more sophisticated. It will require that all inbound messages
contain a UsernameToken element, and outbound “add” and “subtract” responses should be digitally
signed. Since the backend MathServer does not sign the responses, you’ll leave the mode as “enforce”
so that DataPower will automatically add the signature for you (if the backend was signing the message,
DataPower would not re-sign it).
First, let’s remove the previously used WSDL from the WS Proxy object.
__19.
Back in the browser window, click on the WSDLs tab.
__20.
Locate and click on the Remove link to the far right of the WSDL Source location.
__21.
Click on the Upload button to upload a new WSDL. This new WSDL will contain an embedded
WS-Policy.
__22.
In the Upload dialog, click the Browse button, locate and upload:
MathServerWithPolicy.wsdl
The embedded policy requires all outbound messages (responses from the MathServer) to be signed.
The policy itself doesn’t have any information regarding the key and certificate used to sign the outbound
message, therefore there must be some mechanism to provide the key and certificate to the WS-Policy
enforcement engine. This is accomplished with a WS-Policy Parameter Set.
Page 114
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__23.
Click on the plus sign next to the WS-Policy Parameter dropdown list. This will initiate the
process of creating a new WS-Policy Parameter Set.
__24.
For the name, type: MyPolicySet
__25.
In the Policy Domain dropdown, select the domain ending with …/200512.
__26.
In the Parameter Name dropdown, select: Signing Certificate
__27.
In the Parameter Value, type the name of the Crypto Cert that you created in earlier labs. If
you’ve been using the names recommended in this workbook, the name should be:
MyPublicCert
__28.
Click the Add icon
__29.
In the Policy Domain dropdown, select the domain ending with …/200512 (it’s probably already
selected).
__30.
In the Parameter Name dropdown, select: Signing Key
__31.
In the Parameter Value, type the name of the Crypto Key that you created in earlier labs. If
you’ve been using the names recommended in this workbook, the name should be:
MyPrivateKey
__32.
Click the Add icon
on the far right side to add this policy parameter to the list.
on the far right side to add this policy parameter to the list.
The completed form should look like this:
__33.
Click the Submit button if everything looks correct. You’ll be returned back to the Configure Web
Service Proxy page.
__34.
Click the Next button.
WS-Policy Support
Page 115
IBM
__35.
With the previously created HTTP Front Side Handler selected in the dropdown box, click the
add button
to add the HTTP Front Side Handler to the WS Proxy service (see below).
The completed form should appear similar to this:
__36.
Click the Next button.
That’s it! The Web Service Proxy service is now configured and enforcing the WS-Policy directives that
are embedded in the WSDL. Let’s try a few tests to see it working.
To review, the embedded WS-Policy dictates that all inbound requests must contain a WS-Security
Header that contains a UsernameToken, and only “add” and “multiply” responses must be digitally
signed. Subtract and divide requests only require the UsernameToken but do not need to be signed.
Remember, the WS-Policy requirements don’t actually do the authentication or authorization, they merely
are a way to enforce that the inbound message meets the requirements of having the UsernameToken,
and that outbound messages are signed. Within the processing policy, the AAA action that you
previously added will take care of the authentication and authorization.
Page 116
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Test 1: “Add” request with UsernameToken. Response message should be digitally signed by WS-Policy.
post soapAdd.xml http://datapower:4nn02/MathServer/services/MathServer
In the above window, you can clearly see that WS-Policy added a digital signature to the response.
WS-Policy Support
Page 117
IBM
Test 2: “Add” request that does not contain a UsernameToken. Request should fail from WS-Policy.
post soapAddNoUser.xml http://datapower:4nn02/MathServer/services/MathServer
In the above window, you can see how WS-Policy executed an XPath expression to find the
UsernameToken, but was unable to find it; therefore the WS-Policy requirement was not met.
Test 3: “Add” request with UsernameToken but unauthorized UserID. Request should fail from AAA.
post soapAddNotAuth.xml http://datapower:4nn02/MathServer/services/MathServer
In the above window, you can see that the AAA policy rejected the request, not the WS-Policy.
Test 3: “Subtract” request with UsernameToken. Response should NOT be digitally signed.
post soapSubtract.xml http://datapower:4nn02/MathServer/services/MathServer
Notice that the response is not signed.
__37.
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
Page 118
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
13.4 Summary
In this lab, you had a brief introduction to WS-Policy and how DataPower understands and enforces a
WS-Policy. You saw that WS-Policy can be either embedded in a WSDL or alternatively attached to an
existing WSDL.
WS-Policy provides a way to describe complex requirements and constraints on both inbound and
outbound messages. In this lab, you saw how WS-Policy was used to require a UsernameToken element
on inbound messages, and require that responses be digitally signed. By either specifying filter or
enforce, DataPower can either reject non-conformant responses (filter mode) or augment the response
so that it conforms to the required policy (enforce mode).
WS-Policy Support
Page 119
IBM
Page 120
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 14
WebSphere Services Registry and Repository Integration
So far, you’ve seen how you can configure a WS Proxy object by uploading a WSDL into the onboard file
system. The URL contained the local: prefix which designates the local directory in the onboard file
system. You could have also provided an http:// URL that would have caused DataPower to go and fetch
the WSDL from an HTTP server. With these scenarios, DataPower has no knowledge of whether the
WSDL has changed or not. Each time the WSDL is updated or a new version comes up, the WSDL must
be manually refreshed.
DataPower provides support for both UDDI and WebSphere Services Registry and Repository. This
means that DataPower will communicate with the UDDI or WebSphere Services Registry and Repository
server to ensure that it has the most recently published WSDL documents.
In this lab, you’ll see how DataPower can collaborate with WebSphere Service Registry and Repository
(WSRR) to subscribe to a WSDL and automatically update itself at given intervals.
The WebSphere Services Registry and Repository server is running within the instructor’s VM and not on
your workstation. Since this PoT focuses on the DataPower aspects, you won’t be uploading the WSDL
into WebSphere Services Registry and Repository, rather you’ll focus on configuring a WS Proxy object
to subscribe to the WSDL through WebSphere Services Registry and Repository.
WebSphere Services Registry and Repository has been preconfigured with the following:
DataPower_PoT (http://pot.ibm.com)
MathServer
MathServer.wsdl
(Concept)
(Relationship)
(WSDL document)
14.1 Updating the WS-Proxy for WebSphere Services Registry and
Repository
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Click on the Web Service Proxy icon.
__4.
In the list of Web Service Proxies, select: MyWsProxy
__5.
The WSDL tab should be displayed (if not, click it to display it). Locate and click on the Remove
link to the far right of the WSDL source location.
WSRR Support
Page 121
IBM
__6.
Now click the radio button for: Add WSRR Subscription
__7.
Fill in the WSRR Subscription Parameters as follows:
__a.
Subscription name (New):
MyWsrrSubscription
__b.
Namespace:
http://pot.ibm.com
__c.
Subscription Object:
Concept
__d.
Object name:
DataPower_PoT
(this is case sensitive)
The synchronization method specifies how DataPower will attempt to keep the WSDL up-to-date.
Selecting a synchronization method of “Poll” will cause DataPower to poll the WebSphere Services
Registry and Repository server at the designated refresh interval (defaults to 86400 seconds = 24 hours).
__8.
Now you’ll need to create the WSRR Server connection object. Click on the plus sign to create a
new WSRR Server connection.
__9.
In the Configure WSRR Server page, type the name as: MyWsrrServer
Page 122
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__10.
In the SOAP URL field, modify the protocol, host, and port as follows:
Change https to: http
Change host to: demoserver
Change port to: 9080
http://demoserver:9080/WSRRCoreSDO/services/WSRRCoreSDOPort
__11.
Click the Apply button.
__12.
Click the Next button. The Web Service Proxy WSDLs page will be displayed.
__13.
Make sure that MyHttpListener is selected in the Local Endpoint Handler column (you created
this HTTP listener in a previous lab), then click the Add button at the far right side to add this
listener to the service (see next image).
__14.
Click Next.
The WS-Proxy is now complete and ready to be tested.
__15.
Type the following command, and replace the N with your student number, and the url with the
URL provided by the instructor (make sure to type it exactly including upper and lower case
letters).
post soapAdd.xml http://datapower:4nn02/MathServer/services/MathServer
It should return the same response as in the previous labs.
WSRR Support
Page 123
IBM
__16.
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
14.2 Summary
In this lab, you saw how DataPower can subscribe to an external registry to obtain a WSDL. The
subscription can be configured to automatically poll at a specified interval for new updates to the WSDL.
Page 124
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 15
Protocol Bridging: HTTP to WebSphere MQ
In this lab, you’ll configure the DataPower appliance to mediate between HTTP and WebSphere MQ.
DataPower’s Multi-Protocol Gateway service provides out-of-the-box capabilities allowing you to create
processing policies that support inbound and outbound transactions over a multitude of disparate
protocols, including HTTP(S), WebSphere MQ, WebSphere Java Message Service JMS, and FTP to
name a few. The inbound and outbound protocol need not be the same. A request can arrive over HTTP
and depart over WebSphere MQ. This is especially useful when exposing legacy applications or offloading expensive XML processing (parsing, schema validation, cryptography, etc.) from a mainframe.
As a WebSphere MQ client, the DataPower appliance connects to an MQ Queue Manager and listens for
messages to arrive on a designated queue. When the message arrives, the message body is then
extracted from the message and processed through a policy in exactly the same manner as if it had
arrived over HTTP. Internally, MQ specific details, such as headers, are available for inspection or
modification within a processing policy.
Multi-Protocol Gateways can listen for inbound messages on more than one connection simultaneously.
For example, it is possible to configure a multi-protocol gateway to listen for requests on HTTP, HTTPS,
and WebSphere MQ. The MPG is indifferent as to which protocol a message arrives on; once a
message arrives on one of the protocols, it is then processed by a single policy.
Processing policies associated with Multi-Protocol Gateways are identical in nearly every aspect to those
found in XML Firewalls and Web Service Proxies. In fact, a policy that was created for inbound
messages in an XML Firewall can be re-used in a Multi-Protocol Gateway (and visa versa).
Outbound messages can be forwarded either synchronously (round-trip) or asynchronously (one-way). In
a synchronous scenario, a message might arrive over HTTP and then be put on a WebSphere MQ
queue. DataPower will then listen on another queue for a response. Once a response arrives, it is pulled
back into DataPower, processed through the policy, and then converted back to an HTTP response.
In an asynchronous scenario, a message may arrive over HTTP, be processed by the policy, and then
dropped into a WebSphere MQ queue. Rather than waiting for a response on another queue, DataPower
simply returns an empty HTTP success response.
In this lab, you will learn about the following key topics:

Multi-Protocol Gateway services

WebSphere MQ Queue Manager connection objects

HTTP Front Side Handlers

DataPower’s MQ specific URLs

Matching rules

Basic processing policy editing.
15.1 Creating the Queue Manager Object
A DataPower queue manager object acts as a reusable proxy between the DataPower appliance and an
MQ Queue Manager which resides on a remote WebSphere MQ Server. The queue manager object is
responsible for coordinating all communications between the DataPower appliance and WebSphere MQ.
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
Protocol Bridging: HTTP to MQ
Page 125
IBM
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Click on the Objects Menu link in the navigation pane to expose the Objects Menu.
__4.
In the Network section, locate and click MQ Queue Manager.
__5.
In the Configure MQ Queue Manager page, click the Add button to create a new MQ Queue
Manager object.
__6.
In the Name field, type a name for this object, such as MyMqManager.
__7.
For Host Name, specify: demoserver(1414)
__8.
For Queue Manager Name, specify: QM_DataPower
This field is case sensitive
__9.
For User Name, specify: Guest
This field is case sensitive
__10.
At the top of the form, click the Apply button to create the queue manager connection object.
15.2 Create the Multi-Protocol Gateway Service
Now that the queue manager connection object has been created, it’s time to create the Multi-Protocol
Gateway service.
__11.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__12.
Click on the Multi-Protocol Gateway icon.
__13.
Click on the Add button to create a new Multi-Protocol Gateway service. The Configure MultiProtocol Gateway form is displayed.
__14.
In the Multi-Protocol Gateway Name field, type: MyMqEchoService
Creating a Front Side Handler
Now you’ll specify the protocols that this MPG service will listen for requests on, and what URL to
forward requests to. Create the front side protocol listener first.
__15.
In the middle of the page towards the right is a section labeled Front side settings. Locate and
click the Create New button to create a new front side listener object.
__16.
From the drop-down list, select HTTP Front Side Handler. The Configure HTTP Front Side
Handler window will be displayed.
The options provided in the window allow you to precisely configure the various settings related to HTTP
connections. In addition to the obvious settings such as IP address and port, you can also specify which
version of HTTP that the listener will accept, or whether to use persistent connections. For this lab, you’ll
only be specifying the name and port number.
Page 126
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__17.
In the Name field, type a name for this listener: MyHttpListener4nn08.
__18.
Leave the Local IP Address field as 0.0.0.0
__19.
In the Port Number field, replace the default port 80 with 4nn08 where nn is your student
number.
__20.
Click the Apply button in the upper left corner of the form.
Now that the HTTP listener is created, you have to add it to the service.
__21.
Click the Add button (see below).
After you add the listener to the service, you’ll notice that the operational state will remind you to click the
Apply button (the red message). The reason for this message is because you’ve assigned the listener to
the service, but you haven’t actually created the service yet (see below).
At this point, you’ve defined how the clients will communicate with MPG service, but you still need to
define how the MPG service will communicate with the back side server.
Configuring the MQ Backside Connection
If the back side service were a HTTP server, you would specify the backend URL as usual, but the
backend in this case will be an MQ queue. The WebGUI has a button that can help you create a special
MQ URL.
__22.
In the Back side settings section, click the MQHelper button to open the MQ URL Builder.
__23.
From the Queue Manager dropdown list, select the queue manager you defined earlier in this lab
(MyMqManager).
__24.
For the RequestQueue field, type: Requests
This field is case sensitive
__25.
For the ReplyQueue field, type: Replies
This field is case sensitive
Protocol Bridging: HTTP to MQ
Page 127
IBM
The form should look as follows:
__26.
Click the Build URL button to save the formatted MQ URL.
The Backend URL will be inserted for you as follows:
dpmq://MyMqManager/?RequestQueue=Requests;ReplyQueue=Replies
Creating the Processing Policy
Next you’ll need to create the processing policy for this service. As you’ve seen in previous labs, the
policy contains the matching rules and processing pipelines that define what actions should be applied to
the request and reply messages.
__27.
In the General Configuration section of the form, click the plus button
Gateway Policy section.
__28.
In the Policy Name field, type a name for this new policy, such as MyEchoPolicy.
in the Multi-Protocol
Creating a matching rule to match any inbound URL
The first step in creating a policy from scratch is to define a matching rule that will determine which
requests this policy will apply to. Depending on which labs you’ve already done, you may have already
learned how to create a matching rule. For this lab, you’ll need to create a matching rule that matches all
requests. A matching rule is required for every processing pipeline, so the editor has already added one
for you. It’s outlined in yellow, indicating that it still needs to be configured.
__29.
In the policy editor window, click the New Rule button.
__30.
Double click the yellow outlined match action
then be displayed.
__31.
In the Configure a Matching Action window, click the plus button
rule. The Configure Matching Rule window will be displayed.
. The Configure a Matching Action window will
to add a new matching
The name of the matching rule should relay an idea of what type of messages will result in a positive
match. The rule you’ll create will match any URL, so an appropriate name for the rule would be AnyUrl.
__32.
In the Name field, type the name: AnyUrl
Page 128
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__33.
At the top of the form is a tab labeled Matching Rule. Click on the Matching Rule tab link to
display the matching rule details.
Matching rules were discussed in detail in the WS-Security: Digital Signatures lab. For a full description
of the various types of matching expression, refer to that lab, in the section entitled “Verifying a Digital
Signature”.
__34.
Click the Add button to add a new matching expression.
__35.
From the Matching Type dropdown list, select: URL
The URL Match field is where you would specify a Perl compatible expression to match against the URL.
Since we will be matching any URL, we will specify an asterisk which indicates any URL.
__36.
In the URL Match field, type an asterisk: *
__37.
Click the Save button.
The matching rule you just created should appear in the list of matching expressions (see below).
__38.
Click the Apply button to save this matching rule.
__39.
In the Configure a Match Action window, the newly created Matching Rule should be visible in
the dropdown list. Make sure AnyUrl is selected in the dropdown, then click the Done button.
When a request arrives over HTTP, it will pass through the service without being altered, and then be put
onto the specified MQ queue. When the associated response is found on the specified reply queue, the
service will GET the message, pass the response through unaltered, and convert it back to HTTP before
returning it to the requestor. Therefore, the only action that is required in the processing policy is a Result
action.
__40.
Click and drag a result action
action
__41.
from the action palette and drop it to the right of the matching
.
Click the Apply Policy button to save all changes to this policy.
Notice that Both Directions is selected in the drop down list box. This indicates that this processing rule
will be applied to inbound requests from the client, and returned responses from the server.
Protocol Bridging: HTTP to MQ
Page 129
IBM
The completed policy should look as follows:
__42.
Click the Close Window link in the upper part of the window to close the policy editor.
The Multi-Protocol Gateway service is now fully configured.
__43.
In the Configure Multi-Protocol Gateway form, click the Apply button in the upper left part of the
form.
You’re now ready to test this service.
__44.
Open a command window (if one is not already open).
__45.
Navigate to the student/artifacts directory.
__46.
Type the following command, and replace the nn with your student number:
post soapMsg.xml http://datapower:4nn08
If you didn’t get a response back from the server, you should go back and verify that you typed all of the
names related to queues exactly as they are in this document. If everything looks right, feel free to ask
the instructor for help.
__47.
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
Page 130
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
15.3 Summary
In this lab exercise, you saw how the Multi-Protocol Gateway can easily be configured to mediate
between dissimilar protocols such as HTTP and WebSphere MQ. Regardless of which protocol a
message arrives on, it can be processed by a single processing policy.
You first configured an MQ Connection Manager object which manages all of the connection details
between DataPower and a remote WebSphere MQ server. You then configured a Multi Protocol
Gateway to receive requests over HTTP, but process them out the back over MQ. You created an HTTP
Front Side Listener on a specific port to receive the requests. You specified a backend URL that
contained a special dpmq: protocol which results in DataPower redirecting the request to the designated
MQ Queue Manager.
You also learned about the various types of matching rules and how to create them. You saw that a
matching rule contains a collection of one or more matching expressions that get executed to determine
whether the overall match is positive or not. Matching expressions can be checked against any of URL,
qualified URL, error, XPath, or HTTP headers.
15.4 Do you still have more time?
If there’s still some time remaining before moving on to the next lab, perhaps you might want to try some
of these exercises:

Enable the probe and post another transaction. In the probe, open up the response and look at
the various headers returned from WebSphere MQ.

Modify the processing policy to include a transform step. Use the stylesheet named
productTransform.xsl. Remember, the processing rule that you created in this lab will get
executed for both the request and the response, but you probably only want to transform the
response. Can you figure out how to modify the rule that you created to be only for the response
(server to client)?

Encrypt or digitally sign the response back to the HTTP client.
Protocol Bridging: HTTP to MQ
Page 131
IBM
Page 132
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 16
Multi-Protocol Content-Based Routing
In this lab, you’ll examine how the DataPower appliance can make content-based routing decisions
based on some criteria about the inbound message. For example, the name of the backend WebSphere
MQ queue could be determined based on some element in the inbound XML message. The various
backend destinations need not all be the same protocol either. It could be that certain conditions would
route the message to an MQ queue, while other conditions would route the message to an HTTP server.
There are several ways to accomplish content-based routing:

Matching rules could be used to select a specific processing policy, and within that policy a
backend server is hard-coded in a routing action.

From within a processing policy, an XPath Routing Table can be created which uses a series of
XPath expressions to determine the outbound URL.

An XSL stylesheet can be used to generate the outbound URL.
To demonstrate content-based routing, you’ll be creating another multi-protocol gateway that will listen
for HTTP requests, and route them to one of two backend servers based on the inbound URL.
The service you’re about to create will listen on a single HTTP port for requests. The requests are math
requests, however they will be arriving in two different formats, either SOAP, or flat record (COBOL
copybook). The service will distinguish between the two request types by the inbound URL. If the
inbound URL is in the form of /MathServer/services/MathServer, then the request will be routed to a
SOAP-based Web service over HTTP. If the inbound URL is just “/”, then the request will be sent to a
legacy COBOL math server by placing the request on an MQ queue; the response from the legacy
server will be read from another queue and returned to the requesting client over HTTP.
16.1 Creating the Multi-Protocol Gateway
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Click on the Multi-Protocol Gateway icon.
__4.
Click on the Add button to create a new Multi-Protocol Gateway service. The Configure MultiProtocol Gateway form is displayed.
__5.
In the Multi-Protocol Gateway Name field, type: MyDynamicRouter
__6.
Below the Name field, in the Type field, select: dynamic-backend
Changing how the listener handles the messages
Unlike the other services you’ve created thus far, this service will receive both XML (SOAP) and nonXML text data. By default, the service configures itself to expect SOAP traffic and thus checks that the
XML is well-formed; it also validates inbound XML against a SOAP schema to assure that the SOAP
message is proper.
Multi-Protocol Content-Based Routing
Page 133
IBM
Since this listener is expecting non-XML traffic, you will need to specify that the inbound requests and
returned responses should not be XML and SOAP validated.
__7.
Towards the middle of the form on the left side, locate the radio button group labeled Response
Type. From the group, select: Non-XML
__8.
To the right of this group is a similar group labeled Request Type. From the group, select: NonXML
16.2 Creating the Front Side Handler
First, you’ll need to create a front side handler to receive messages. For this lab, you’ll create an HTTP
front side handler.
__9.
In the middle of the page towards the right is a section labeled Front side settings. Locate and
click the Create new button to create a new front side listener object.
__10.
From the drop-down list, select HTTP Front Side Handler. The Configure HTTP Front Side
Handler window will be displayed.
__11.
In the Name field, type a name for this listener: MyHttpListener4nn09.
__12.
Leave the Local IP Address field as 0.0.0.0
__13.
In the Port Number field, enter 4nn09 where nn is your student number.
__14.
Click the Apply button in the upper left corner of the form.
__15.
Make sure that the newly created 4nn09 listener is selected in the dropdown list, then click the
Add button.
After you click the Add button, the listener will be added to the service. You’ll notice that the operational
state will remind you to click the Apply button (the red message). The reason for this message is
because you’ve assigned the listener to the service, but you haven’t actually created the service yet.
16.3 Creating the Policy
Now you’re ready to create the processing policy. This policy will contain two matching rules, one to
match on the Web Service URL, and another that will match anything else (a default match).
__16.
In the Multi-Protocol Gateway Policy section (top right of the form), click the plus button
create a new policy for this service.
__17.
In the Policy Name field, type: MyDynamicPolicy
__18.
Click the New Rule button.
to
Now you’ll create the matching action to check for a Web service (SOAP) request.
__19.
The yellow outline indicates that the matching action needs to be configured. Double click the
match action
Page 134
to open its configuration page.
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__20.
In the Match Rule field, click the plus button
Matching Rule window is displayed.
to create a new matching rule. The Configure
__21.
In the Name field, type: WebServiceMatch
__22.
Click on the Matching Rule tab at the top of the window.
__23.
Click the Add button to create a new matching expression.
__24.
In the Matching Type dropdown list, select: URL
__25.
The URL Match field is case sensitive; in the URL Match field, type the following URL exactly as
shown: /MathServer/services/MathServer
__26.
Click the Save button to save this matching expression. The final Matching Rule should look as
follows:
__27.
Click the Apply button towards the top of the window.
__28.
Click the Done button to assign this newly created matching rule to the matching action.
Now you’ll add a routing action to the processing pipeline.
onto the pipeline to the right of the matching action
__29.
Click and drag a Route action
__30.
Double click the yellow outlined route action to open its configuration page.
.
The Route action is used to select the desired backend URL. There are three ways to select the backend
URL.

Use Stylesheet to Select Destination – when this option is selected, the output from a designated
stylesheet will be the destination URL. This allows you to create an XSL stylesheet that includes
logic to determine and create the destination URL.

Use XPath to Select Destination – when this option is selected, a table (referred to as an XPath
Routing Map) of XPath/URL mappings is used to determine the backend URL. For each row in
the table, the XPath is evaluated; if it returns a non-empty nodeset, the associated URL is
selected as the destination.

Use Variable to Select Destination – Allows you to specify a URL which can be either the
destination URL, or the name of a DataPower variable that contains the URL.
For this lab, you’ll be using a variable to select destination.
__31.
In the Configure Route Action window, click the radio button for Use Variable to Select
Destination.
Multi-Protocol Content-Based Routing
Page 135
IBM
__32.
In the Destination field, type exactly:
http://MathServer:9080/MathServer/services/MathServer
__33.
Click the Done button to save the route action.
__34.
Since this policy is applicable only to inbound client requests, select Client to Server from the
Rule Direction dropdown list in the policy editor.
__35.
Click the Apply Policy button to save the changes you’ve made.
Now you can create a processing policy that will act as the default policy to handle any other traffic. This
time, we will reuse the matching rule creating in the prior lab exercise.
__36.
In the Rule Actions section, click the New button to create a new processing pipeline (see
below).
__37.
Double click the yellow outlined matching rule action to open the matching rule configuration
page.
__38.
From the Matching Rule dropdown list, select the previously created matching rule named:
AnyUrl.
__39.
Click the Done button to save the changes to the match action.
__40.
From the Rule Direction dropdown list, select: Client to Server requests.
__41.
Click and drag a route action
onto the processing pipeline to the right of the matching action
.
__42.
Double click the yellow outlined route action to open its configuration page.
__43.
In the Selection Method radio button group, click the radio button for Use Variable to Select
Destination.
__44.
In the Destination field, exactly type the following URL:
dpmq://MyMqManager/?RequestQueue=MathRequests;ReplyQueue=MathReplies
__45.
Click the Done button to save the route action configuration.
__46.
Click the Apply Policy button to save the changes to this new processing pipeline.
Page 136
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
The policy editor should appear as follows:
__47.
Click the Close Window link to close the policy editor.
__48.
Finally, click the Apply button to save the entire configuration for the new multi-protocol
gateway.
You can now test your new service to see if it acts as expected. First, you’ll send a SOAP message
containing an Add request. The service should match the URL and properly route the request to the
MathServer Web service. Then, you’ll post a flat record to the new service. The record should be put
onto an MQ queue named MathRequests. The record will be picked up by a COBOL simulator, process
the request, and put a response on a queue named MathReplies. Your new service will take that reply off
the queue and return it back to the original client over HTTP.
Testing the Web Service
__49.
Open a command window (if one is not already open).
__50.
Navigate to the student/artifacts directory.
Multi-Protocol Content-Based Routing
Page 137
IBM
__51.
Type the following command, and replace the N with your student number (command is case
sensitive):
post soapAdd.xml http://datapower:4nn09/MathServer/services/MathServer
You should receive a SOAP response from the Web service.
Now you’ll do the same thing but with the COBOL request. The file coboladd.dat contains a single line
that has the following COBOL format:
.......A...B..........................................................
01 MATH-REQUEST.
03 OPERATION
PIC X(10).
88 OP-ADD
VALUE 'ADD'.
88 OP-SUBTRACT
VALUE 'SUBTRACT'.
88 OP-MULTIPLY
VALUE 'MULTIPLY'.
88 OP-DIVIDE
VALUE 'DIVIDE'.
03 OPERAND OCCURS 2 TIMES PIC 9(5).
Example: ADD
0020800120 is an add request of 208 + 120.
The response that will be returned from the server will have this COBOL format:
.......A...B..........................................................
01 MATH-RESPONSE.
03 OP-CODE
PIC X(10).
03 RESULT
PIC 9(7)V99.
Response should be: ADD
__52.
000032800 (response has 2 implied decimal places)
Now test the COBOL requests to the same listener. Type the following command, replacing the
N with your student number, and the url with the URL provided by the instructor.
post coboladd.dat http://datapower:4nn09
You should receive a response that looks something like this:
ADD
__53.
00032800
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
16.4 Summary
In this lab, you were exposed to how DataPower services can achieve dynamic backend routing. You
first created a Multi-Protocol Gateway service that listened on a specific port for requests. Depending on
the inbound URL, the gateway service either routed the request to a Web service over HTTP, or to a
legacy application via WebSphere MQ. In either case, DataPower associated the response to the original
request and returned it properly to the client.
Page 138
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 17
Protocol Bridging: FTP to MQ
In this lab, you’ll see how DataPower can allow FTP clients to post transactions using standard file
transfer protocol (FTP). You’ll be building on the multi-protocol gateway you created in the previous lab,
by adding an FTP Server Front Side Handler.
DataPower supports two different types of FTP front side handlers: server and client. As a server, clients
can connect and access it exactly as if it were an actual FTP server. A virtual directory structure can be
configured so that clients can actually navigate and put files in specific places. On the other hand, a
client front side handler acts just like an FTP client and will attempt to connect to an FTP server to get a
file. Essentially, it polls an FTP server until the desired file arrives, then gets it and processes it through
the policy. The desired file name can be specified either explicitly or as a matching pattern.
FTP functionality can be configured to be either synchronous or asynchronous. If the backend call results
in a response, the front side handler can, in the case of a server, provide a copy of the response file in
the virtual directory, or in the case of a client front side handler, PUT the new file back to the originating
FTP server.
In this lab, you’ll be focusing on the more commonly used FTP Server Front Side Handler. You’ll learn
about:

Virtual ephemeral, virtual persistent, and transparent file modes

FTP URLs

How to create an FTP Server Front Side Handler
17.1 FTP Server Front Side Handler
(XI50 only)
An FTP Server front side handler simulates an FTP server. From the client’s perspective, the actions to
navigate directories are the same as those for a real FTP server. An FTP Server front side handler (FSH)
has three modes of operation: transparent, virtual-ephemeral, and virtual-persistent.
Virtual Ephemeral
The FTP server will have an ephemeral (short-lived) virtual file system with subdirectories created by
configuration. The contents of this file system are private to an individual FTP control connection to the
FTP server. The contents of this file system will not persist after this FTP control connection ends.
Virtual Persistent
The FTP server will have a persistent virtual file system with subdirectories created by configuration. The
contents of this file system are shared by all FTP control connections to this FTP server with the same
authenticated user identity. The user identity is determined by the FTP user name and, if used, by the
TLS/SSL certificate. The contents of this file system will persist after all FTP control connections end for
a duration defined in the configuration.
Transparent
The FTP server has a transparent file system. The files and directories shown are those on the back end
of the associated Multi-Protocol Gateway.
Protocol Bridging: FTP to MQ
Page 139
IBM
FTP URLs
When an FTP Server front side handler (FSH) is configured in one of the virtual modes, it provides a
simulated directory structure to the connected client. By default, a root directory is provided, however a
full directory tree can be configured such that the client can navigate as needed. When a file is finally
PUT, the full path to the file will become part of the URL sent to the backend server. This URL can then
be used for matching within a processing pipeline’s match action. For example, if the user connects to an
FTP server and issues the following commands:
CD /my/directory
PUT myfile.dat
the front side handler will receive myfile and pass it to the processing policy with an inbound url of:
/my/directory/myfile.dat
If the backend server returns a response, the response will be put into the virtual directory. You can
optionally specify a response suffix that will be added to the inbound filename to distinguish it from the
original posted file.
17.2 Creating the FTP Server Front Side Handler
There are two paths to creating any front side handler: from the objects menu, and from within the MultiProtocol Gateway configuration page. In the last lab, you created the HTTP front side handler from within
the gateway configuration page, so this time, you’ll use the objects menu.
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
Click on the Objects Menu link in the navigation pane to expose the Objects Menu.
__4.
In the Protocol Handlers section, locate and click FTP Server Front Side Handler.
__5.
In the Configure FTP Server Front Side Handler page, click the Add button.
__6.
In the Name field, type: MyFtp4nn21 where nn is your student number.
__7.
Change the port number to: 4nn21 where nn is your student number.
__8.
Towards the bottom of the form, change the Response Type dropdown to
Virtual Filesystem.
__9.
In the Response Suffix field, type: .txt
Page 140
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__10.
Click the Apply button to save this configuration.
You may have noticed that the Op-State column shows the FTP listener to be down. Since this listener is
not associated with any multi-protocol gateways yet, DataPower doesn’t enable it. After you add this
listener to a multi-protocol gateway, this status will become up.
Now you can add this listener to the dynamic routing multi-protocol gateway created in the previous lab
exercise.
__11.
Click on the Control Panel link in the navigation pane.
__12.
Click on the Multi-Protocol Gateway icon.
__13.
From the list of multi-protocol gateways, click on the one you created in the previous lab
exercise. If you used the recommended name, it should be: MyDynamicRouter
__14.
In the Front side settings section, use the dropdown list to select the FTP front side handler you
just created (MyFtp4nn21).
__15.
Click the Add button to add this listener to the multi-protocol gateway.
__16.
Click the Apply button to save your changes.
The FTP server FSH should now be active and ready to receive connections. To test it, you’ll connect to
it with a graphical FTP client and drag the coboladd.dat file from your workstation and drop it into the root
directory of the FTP server. Under the covers, the FTP server FSH will then read that file as a request
and pass it to the multi-protocol gateway just as if it had arrived over HTTP. It will ultimately get dropped
onto an MQ queue, processed by the backend server. The result from the server will be put on a result
queue, which will be taken by the multi-protocol gateway, and returned back in the form of an FTP file.
When you configured the FTP server FSH, you specified a response suffix of “.txt”, so you should expect
to see coboladd.dat.txt after the process executes.
You’ll test this using the FTP command line utility.
__17.
In a command window, make sure you are in your student/artifacts directory.
__18.
Type ftp, then press Enter.
__19.
Type open datapower 4nn21, then press Enter. Use the port you created in step 7.
__20.
You’ll be prompted for a User. Type any user, such as guest, then press Enter
__21.
You’ll be prompted for a password. Type any password, such as pwd, then press Enter
__22.
Type binary, then press Enter.
__23.
Type put coboladd.dat, then press Enter.
Protocol Bridging: FTP to MQ
Page 141
IBM
__24.
Type: dir then press Enter.
You should see a directory listing of the virtual file system on the DataPower device. Notice that the
listing contains both the request file that you posted (cobolAdd.dat) as well as the response
(cobolAdd.dat.txt). It should look similar to the following:
To see the contents of the response, you can issue the FTP “GET” command.
__25.
Type get coboladd.dat.txt, then press Enter.
__26.
Exit out of the FTP utility. Type quit, then press Enter.
__27.
Use the “type” command to view the file: type coboladd.dat.txt
You should see the contents of the response.
__28.
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
17.3 Summary
In this lab, you saw how DataPower makes a clear separation between the listeners that manage
inbound traffic, and the processing policies that manipulate the messages. You configured a FTP server
front side handler to receive incoming FTP requests and to buffer them in a virtual ephemeral file system.
Once the file arrived, the handler passed the file over to the processing policy, just as if it had arrived
over HTTP or MQ. You saw that by simply selecting the handler and clicking the Add to gateway button,
the handler became immediately active and was ready to handle inbound connections.
Page 142
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Lab 18
Transforming Non-XML Payloads
Up until now, you’ve seen how DataPower can manipulate XML documents in a variety of ways including
encrypting, decrypting, signing, and transforming. You’ve also seen how DataPower can mediate
between various types of protocols such as HTTP, FTP, and MQ. Quite often, it becomes necessary to
manipulate requests that are not XML. This is especially common in service oriented architectures
involving legacy systems that haven’t yet been enabled for XML.
The IBM WebSphere DataPower XI50 appliance, together with the IBM WebSphere Transformation
Extender (WTX) Design Studio, enable you to create transformations that convert between XML and
non-XML data (fixed width fields, comma separated fields, etc). This is often referred to as a binary
transform.
The process involves two steps. First, a mapping between XML and non-XML data must be created
using WTX Design Studio. The WTX Design Studio will then generate several artifacts which will be
uploaded into the DataPower device. Once those artifacts have been uploaded, executing a non-XML
transform is accomplished in the same way as an XML transformation. It’s important to note that once
the artifacts have been exported from WTX and imported into DataPower, all processing will occur within
DataPower; WTX is only used for creating the mapping artifacts.
This lab will introduce you to binary transformations. You’ll be creating a multi-protocol gateway that will
receive SOAP messages for a math Web service, and convert the SOAP message into a COBOL
copybook flat record. The record will then be placed on an MQ queue and processed by a backend
simulated COBOL program. The results from the COBOL program will be put on the reply queue, and
then subsequently taken as the response in the multi-protocol gateway. The response processing
pipeline will then convert the COBOL flat record response back into a valid SOAP response, and pass it
back to the requesting client. Essentially, this lab will demonstrate service virtualization to a legacy
backend server.
The process of designing the mappings between the SOAP request/response and COBOL layouts will be
demonstrated by the instructor, as it is beyond the scope of this PoT to provide a hands-on WebSphere
TX experience.
In this lab, you’ll learn about:

Creating a map between a COBOL copybook and XML (instructor demonstration)

Creating a binary transform action using WTX mapping artifacts.

Using both a request and response processing pipeline.
18.1 Uploading the WebSphere Transformation Extender Artifacts
To prepare for this lab, you’ll need to upload the WTX artifacts into your local directory.
__1.
Log into the DataPower WebGUI with your assigned user id and password. Make sure to select
the matching domain for your user id.
__2.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__3.
In the bottom section of the control panel, click on the icon for File Management.
Transforming Non-XML Payloads with WebSphere TX
Page 143
IBM
__4.
To the right of the local: directory name, click the Actions… link.
__5.
From the dropdown message, click on Upload Files.
__6.
Click on the Browse button, locate the file Request.xml.
__7.
Click on the Add button to attach this file and continue adding more files.
__8.
Repeat this process for the following files:
RequestCobolDef.mts
RequestXmlDef.mts
Response.xml
ResponseCobolDef.mts
ResponseXmlDef.mts
AddSoapEnvelope.xsl
__9.
When all files have been attached, click the Upload button.
__10.
Click Continue in the confirmation window.
18.2 Create a new Multi-Protocol Gateway
__11.
If the control panel is not visible, click on the Control Panel link at the top of the navigation pane.
__12.
Click on the Multi-Protocol Gateway icon.
Page 144
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__13.
Click on the Add button to create a new Multi-Protocol Gateway service. The Configure MultiProtocol Gateway form is displayed.
__14.
In the Multi-Protocol Gateway Name field, type: MySoap2CobolSvc
Create the Processing Policy
__15.
In the General Configuration section, locate the Multi-Protocol Gateway Policy dropdown box
and click the plus
button to create a new policy.
__16.
In the Policy Name field, type: MyWtxPolicy
__17.
Click the New Rule button.
__18.
From the Rule Direction dropdown list, select: Client to Server
Now you’ll need to create two processing rules. The first will manage requests arriving from the client
(transforming from SOAP to binary), and the second will manage responses from the server
(transforming binary back to SOAP).
__19.
Double click the yellow outlined matching action
to open its configuration page.
__20.
From the dropdown list of matching rules, select the AnyUrl matching rule you created in one of
the previous labs. For details on creating this matching rule, refer to the “Protocol Bridging:
HTTP to MQ” lab in the section entitled “Creating a matching rule to match any inbound URL”.
__21.
Click the Done button to save the matching action configuration.
Transforming the SOAP message into a Flat Record (COBOL copybook)
There are two steps involved in transforming the SOAP message into a flat text record. Recall that the
WebSphere TX transform mapping only concentrated on the body of the SOAP message. The transform
is expecting the raw XML SOAP body, not the entire SOAP envelope. Therefore, the SOAP body must
be extracted before the TX transform occurs.
__22.
Click and drag the advanced action
action
onto the processing pipeline to the right of the matching
.
__23.
Double click the advanced action
to open its configuration page.
__24.
In the Configure Action window, click on the radio button labeled Extract Using XPath.
__25.
Click the Next button (you will probably have to scroll to the bottom of the page). The
configuration page for the Extract action will open.
The extract method will execute an XPath expression against the input context (in this case, the inbound
message), and the results of the XPath expression will be placed in the output context.
__26.
In the XPath field, exactly type: //*[local-name()=’Body’]/*[1]
__27.
Click the Done button to save the configuration for the extract action.
Transforming Non-XML Payloads with WebSphere TX
Page 145
IBM
Now you’ll add the transform action that will convert the results of the extract step (the SOAP body) into a
flat text record.
__28.
Click and drag a transform action
extract action
onto the processing pipeline to the right of the newly added
(see below).
__29.
Double click the yellow outlined transform action to open its configuration page.
__30.
In the Use Document Processing Instructions section, click the radio button that corresponds to
Use XSLT specified in this action on a non-XML message.
__31.
In the WTX Map file field, type: local:///Request.xml
__32.
Click the Done button to save the transform configuration.
__33.
Click the Apply Policy button in the policy editor to save your changes to this processing rule.
Transforming the Flat Record response (from COBOL) into XML
Now you’ll need to create the processing rule that will handle converting the response from the server (as
a flat record) back into SOAP.
The processing rule will do exactly the opposite as the previous one. The first step will be to convert the
flat record into an XML document. After that, the XML document will be wrapped in a SOAP response
envelope.
__34.
In the Rule Actions section, click the New Rule button to create a new processing rule (see
below).
__35.
From the Rule Direction dropdown list, select: Server to Client
Page 146
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__36.
Double click the matching rule action
to open its configuration window.
__37.
From the dropdown list of matching rules, select the AnyUrl matching rule you previously
created.
__38.
Click the Done button to save the matching action configuration.
Now you’ll add the transform action that will convert the transform the flat text record into an XML
document.
__39.
Click and drag a transform action
onto the processing pipeline to the right of the match action.
__40.
Double click the yellow outlined transform action to open its configuration page.
__41.
In the Use Document Processing Instructions section, click the radio button that corresponds to
Use XSLT specified in this action as a non-XML message.
__42.
In the WTX Map file field, exactly type: local:///Response.xml
__43.
Click the Done button to save the transform configuration.
The results of the binary transform will be the top element of the SOAP body, but there is still no
encasing SOAP envelope. You’ll now add a transformation that will wrap the XML with a SOAP envelope.
The XSL for the transform is shown below.
Listing of file: AddSoapEnvelope.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<xsl:template match="/">
<soap:Envelope>
<soap:Header/>
<soap:Body>
<xsl:copy-of select="."/>
</soap:Body>
</soap:Envelope>
</xsl:template>
</xsl:stylesheet>
__44.
Click, drag, and drop a transform
previous steps.
action to the right of the binary transform
__45.
Double click the yellow outlined transform action to open its configuration page.
__46.
In the Processing Control File section, in the file dropdown list (on the right), select the file
named: AddSoapEnvelope.xsl
__47.
Click the Done button to save the transform configuration.
Transforming Non-XML Payloads with WebSphere TX
action from the
Page 147
IBM
__48.
Click the Apply button to save your changes to the processing rule. The policy editor window
should look as follows:
__49.
Click the Close Window link to close the policy editor.
Configuring the MQ Backside Connection
__50.
In the Back side settings section, click the MQHelper button to open the MQ URL Builder.
__51.
From the Queue Manager dropdown list, select the queue manager you defined earlier in this lab
(MyMqManager).
__52.
For the RequestQueue field, type: MathRequests This field is case sensitive
__53.
For the ReplyQueue field, type: MathReplies This field is case sensitive
Page 148
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
The completed form should look as follows:
__54.
Click the Build button to save the formatted MQ URL.
The Backend URL will be inserted for you as follows:
dpmq://MyMqManager/?RequestQueue=MathRequests;ReplyQueue=MathReplies
Creating a Front Side Handler
__55.
In the middle of the page towards the right is a section labeled Front side settings. Locate and
click the Create new button to create a new front side listener object.
__56.
From the drop-down list, select HTTP Front Side Handler. The Configure HTTP Front Side
Handler window will be displayed.
__57.
In the Name field, type a name for this listener: MyHttpListener4nn05.
__58.
Leave the Local IP Address field as 0.0.0.0
__59.
In the Port Number field, replace the default port 80 with: 4nn05.
__60.
Click the Apply button in the upper left corner of the form.
__61.
Click the Add button (see below).
After you click the Add to gateway button, the listener will be added to the service. You’ll notice that the
operational state will indicate that the listener is down (the red message). The reason for this message is
because you’ve assigned the listener to the service, but you haven’t actually created the service yet.
The last step is to specify that the response coming back from MQ will be non-XML.
Transforming Non-XML Payloads with WebSphere TX
Page 149
IBM
__62.
Towards the bottom of the form, locate the Response Type button group and select the NonXML radio button.
__63.
Make sure that the Request Type group has the SOAP radio button selected.
__64.
Click the Apply button at the top of the Configure Multi-Protocol Gateway form to save all
changes.
Enable the probe so you can inspect the transactions during testing.
__65.
Click the Show Probe link.
__66.
In the pop-up probe window, click the Enable Probe button to start the probe.
__67.
Click the Close button in the confirmation window.
You’re ready to run a test transaction through the gateway service.
__68.
Open a command window (if one is not already open).
__69.
Navigate to the student/artifacts directory.
__70.
Type the following command, and replace the N with your student number, and the url with the
URL provided by the instructor:
post soapAdd.xml http://datapower:4nn05
The response should resemble the following output:
__71.
Click the mouse back in the probe window, and then click on the Refresh button. The
transaction you just posted should appear in the probe now.
Page 150
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__72.
Click the magnifying glass to inspect the transaction.
In this window, the first magnifying glass is selected which shows the original posted message.
The second magnifying glass represents the input context into the binary transform rule. It will be the
results of the preceding extract action
.
Transforming Non-XML Payloads with WebSphere TX
Page 151
IBM
__73.
Click on the 2nd magnifying glass to view the input context to the binary transform action.
Notice that the previous extract action correctly pulled out the body of the SOAP message, leaving just
the operation.
__74.
Now click on the last magnifying glass which represents the OUTPUT context (the message that
will be forwarded to MQ).
In this window, you can see that the output has been translated into a flag record format.
__75.
Close the probe detail for this transaction.
__76.
In the probe transaction window, click on the small plus (+) to the left of the request transaction
to reveal the response.
Page 152
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
__77.
Click on the magnifying glass of the response.
Notice that the input this time is a flat record.
__78.
Click on the various contexts to investigate the different states of the transaction.
__79.
Click the Save Config button (upper right corner of the page) to save all of the changes you’ve
made during this lab exercise.
18.3 Summary
In this lab, you created a new multi-protocol gateway that exposed a backend legacy COBOL application
as a SOAP based Web service. You started by creating a multi-protocol gateway to receive requests
over HTTP and forward them to an MQ queue. The request was implicitly checked to be well-formed
XML, and then checked to be valid SOAP. The body of the SOAP message was then extracted (using
the extract action), and that XML fragment was then converted into a flat record using the binary
transform action. The response process was similar but in the opposite order. The response arrived and
was first converted to XML via a binary transform action, then wrapped in a SOAP envelope and returned
to the original client.
Transforming Non-XML Payloads with WebSphere TX
Page 153
IBM
Appendix A. The (XML) Threat is Out There…
Bill Hines, Senior Certified Consulting IT Specialist, IBM
New technologies, new temptations
Service-oriented systems are currently all the rage, and rightfully so. It seems like only yesterday that
service-oriented architecture (SOA) was the new buzzword, making us wonder whether this was just
more marketing hype or a technology that would actually become useful -- similar to the thoughts we
may have had about previous buzzword technologies, like Extensible Markup Language (XML) or, more
recently, Web services.
As with XML and Web services, SOA architectures are now bearing fruit across the corporate IT
landscape, thanks to useful enabling technologies, such as the Service Integration Bus in IBM
WebSphere Application Server V6, and its product-ized big brother, the IBM WebSphere Enterprise
Service Bus. As new technologies often do, however, these technologies have invited a whole new class
of attacks on systems that implement them. IT specialists who take security and systems hardening
seriously need to be constantly vigilant about the holes that new technologies can open into their
systems. Hackers have moved their attention past traditional targets, perhaps due to the inevitable
maturity of those platforms, or perhaps because they are now simply passé.
The new frontier for hackers is systems built on Web services and XML, seen as inviting due to their
popularity and immaturity. One class of such attacks is defined as XML threats, where an XML document
that has been structured to do harm is sent to your system. If a system can be accessed by outsiders
(such as through the Internet), someone could send messages to your system in order to damage it, or
even just to consume resources. It is possible that the offending client could even be authorized to use
your system, but is trying to exploit that authorization in some inappropriate way. When XML and SOAP
were described as the new IT "miracle drug," due to their ability to "pass through the firewall," some
savvy computer specialists immediately saw the implications of this from a security perspective. Those
firewalls were put there for a reason, no? Hackers view this "feature" as a free ride on the XMLmobile,
waving at the firewall sentries as they happily pass by.
Often, programmers will leave the door open to attacks by using poor technique, like not strictly defining
the types of data they expect as input to Web services. One example of this would be the use of the
xml:any data type, as opposed to restricting input to an integer or string. This lets attackers send harmful
XML for this attribute -- and as a perfectly legitimate input!
There are four broad classifications of XML threats:

XML Denial of Service (xDoS) -- Slowing down or disabling a Web service so that valid service
requests are hampered or denied.

Unauthorized access -- Gaining unauthorized access to a Web service or its data.

Data integrity/Confidentiality -- Attacks that strike at the data integrity of Web service
responses, requests, or underlying databases.

System compromise -- Corrupting the Web service itself or the servers that host it.
There are several types of attacks within these four broad classifications, which we will look at in a
minute. Also, be aware that these can be single-message or multiple-message attacks.
Software-based application servers used to host Web services are generally quite vulnerable to these
attacks; they are often run with XML validation off for performance reasons, and may not be looking out
for most XML attack types. As we will see, once the XML hits the parser, it is too late. Worse, if your
Appendices
Page 155
IBM
system accepts native XML documents without the complexity of Web services or SOAP, it is even
easier to attack.
Specific types of XML threats
Specific types of attacks within the four broad categories are listed below. Several of these attack types
are familiar; these same types of attack occur with any remotely accessible service (for example,
message tampering). Other attacks, though not really unique to XML-based services, are much more
likely to occur with such services given the nature of XML.
(a) Single message xDoS

Jumbo payloads -- Sending a very large XML message to exhaust memory and CPU on the
target system.

Recursive elements -- XML messages that can be used to force recursive entity expansion (or
other repeated processing) to exhaust server resources. An example of this type of attack would
be the billion laughs attack that is widely available through the Internet.

MegaTags -- Otherwise valid XML messages containing excessively long element names, or an
excessive number of tags. This attack may also lead to buffer overruns.

Coercive parsing -- XML messages specially constructed to be difficult to parse to consume the
resources of the machine.

Public key DoS -- Utilizing the asymmetric nature of public key operations to force resource
exhaustion on the recipient by transmitting a message with a large number of long-key-length,
computationally expensive digital signatures.
(b) Multiple message XDoS

XML flood -- Sending thousands of otherwise benign messages per second to tie up a Web
service. This attack can be combined with Replay attack to bypass authentication, and with
Single message XDoS to increase its impact.

Resource hijack -- Sending messages that lock or reserve resources on the target server as part
of a never-completed transaction.
(c) Unauthorized access

Dictionary attack -- Guessing the password of a valid user using a brute force search through
dictionary words.

Falsified message -- Faking that a message is from a valid user, such as by using Man in the
Middle to gain a valid message, and then modifying it to send a different message.

Replay attack -- Re-sending a previously valid message for malicious effect, possibly where only
parts of the message (such as the security token) are replayed.
(d) Data integrity/Confidentiality

Message tampering -- Modifying parts of a request or response in-flight; most dangerous when
undetected (less commonly known as Message alteration).

Data tampering -- Exploiting weakness in the access control mechanism that permits the
attacker to make unauthorized calls to the Web service to alter data.
Page 156
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM

Message snooping -- A direct attack on data privacy by examining all or part of the content of a
message. This can happen to messages being transmitted in the clear, transmitted encrypted but
stored in the clear, or decryption of messages due to stolen key or cryptanalysis.

XPath/XSLT injection -- Injection of expressions into the application logic. Newer modifications
include Blind XPath injection, which reduces the knowledge required to mount the attack.

SQL injection -- Inserting SQL in XML to obtain additional data than what the service was
designed to return.

WSDL enumeration -- Examining the services listed in WSDL to guess and gain access to
unlisted services.

Message snooping -- Using SOAP routing header for access to internal Web services.
(e) Systems compromise

Malicious include -- Causing a Web service to include invalid external data in output or return
privileged files from the server file system. For example, using embedded file: URLs to return
UNIX® password files or other privileged data to the attacker.

Memory space breach -- Accomplished via stack overflow, buffer overrun, or heap error,
enables execution of arbitrary code supplied by the attacker with the permissions of the host
process.

XML encapsulation -- Embedding system command in the XML payload, such as through the
CDATA tag.

XML virus (X-Virus) -- Using SOAP with attachments or other attachment mechanisms to
transmit malicious executables, such as viruses or worms.
http://www.ibm.com/developerworks/websphere/techjournal/0603_col_hines/0603_col_hines.html
Appendices
Page 157
IBM
Appendix B. IBM TechWorks
TechWorks is a worldwide team serving IBM software sales, technical, and development professionals
and through these organizations our customers and partners. The TechWorks organization works to:
 Provide implementation, execution, and expertise for brand and general technical sales
strategies and objectives
 Provide deep technical and product knowledge directly to customers and partners
 Create material to teach our field teams, our partners, and our customers about what IBM
products can do
 Operate world-class, high-quality facilities that support and enhance the interactions between
our field technical sales team and our clients and partners
For more information about IBM TechWorks, talk with your IBM sales representative.
Appendices
Page 159
IBM
Appendix C. 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 Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property
Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106-0032, Japan
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.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in
any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part
of the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Any performance data contained herein was determined in a controlled environment. Therefore, the
results obtained in other operating environments may vary significantly. Some measurements may have
been made on development-level systems and there is no guarantee that these measurements will be
the same on generally available systems. Furthermore, some measurements may have been estimated
through extrapolation. Actual results may vary. Users of this document should verify the applicable data
for their specific environment.
Appendices
Page 161
IBM
Information concerning non-IBM products was obtained from the suppliers of those products, their
published announcements or other publicly available sources. IBM has not tested those products and
cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of
those products.
All statements regarding IBM's future direction and intent are subject to change or withdrawal without
notice, and represent goals and objectives only.
This information contains examples of data and reports used in daily business operations. To illustrate
them as completely as possible, the examples include the names of individuals, companies, brands, and
products. All of these names are fictitious and any similarity to the names and addresses used by an
actual business enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs
in any form without payment to IBM, for the purposes of developing, using, marketing or distributing
application programs conforming to the application programming interface for the operating platform for
which the sample programs are written. These examples have not been thoroughly tested under all
conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these
programs.
Page 162
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM
Appendix D. Trademarks and copyrights
The following terms are trademarks of International Business Machines Corporation in the United States,
other countries, or both:
IBM
Tivoli
IBM logo
DataPower
DataPower device
DB2
WebSphere
Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United
States, other countries, or both. See Java Guidelines.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product and service names may be trademarks or service marks of others.
Appendices
Page 163
NOTES
NOTES
IBM Software Group
© 2008 IBM Corporation