PoT - Websphere.08.4.060.09 Workbook

IBM Software Group
An IBM Proof of Technology Discovering the Value of IBM WebSphere DataPower SOA Appliances
Lab Exercises
2009 IBM Corporation
PoT.WebSphere.08.4.060.09
Authors: Gerry Kaplan, WebSphere DataPower SME Christopher Khoury, WebSphere DataPower SME Contributors: Charlie Sumner, WebSphere Transformation Extender SME Andrew Grohman, WebSphere DataPower SME Andrew Das, WebSphere DataPower SME Andrew White, WSRR and Middleware SME Shiu-Fun Poon, DataPower Software Engineer Lou Rivas, WebSphere IT Professional Applicable Firmware: 3.7.3.3 and greater
Copyright International Business Machines Corporation, 2008, 2009. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
IBM Software
Contents
OVERVIEW....................................................................................................................................................................3 INTRODUCTION .......................................................................................................................................3 REQUIREMENTS .....................................................................................................................................3 ICONS ....................................................................................................................................................3 LAB 1 INTRODUCTION TO DATAPOWER SOA APPLIANCES .................................................................5 1.1 DATAPOWER SOA APPLIANCES FAMILY .....................................................................................5 1.2 DATAPOWER ACCESS CONTROL ................................................................................................7 1.3 DATAPOWER APPLICATION DOMAINS .........................................................................................8 1.4 THE DATAPOWER WEBGUI.......................................................................................................8 1.5 DATAPOWER CONFIGURATION PROCEDURES ...........................................................................11 1.6 DATAPOWER SERVICES ..........................................................................................................12 1.7 DATAPOWER FLASH-BASED FILE SYSTEM ................................................................................15 1.8 TROUBLESHOOTING TOOLS .....................................................................................................18 1.9 LOGGING ................................................................................................................................19 1.10 DEVICE MANAGEMENT .............................................................................................................23 1.11 DATAPOWER SOA APPLIANCES FIRMWARE .............................................................................25 1.12 SUMMARY ...............................................................................................................................25 LAB 2 WORKING WITH XML ......................................................................................................................27 2.1 PROOF OF TECHNOLOGY NETWORK TOPOLOGY .......................................................................27 2.2 SERVICE PROCESSING PHASES ...............................................................................................28 2.3 CREATING THE MULTI-PROTOCOL GATEWAY SERVICE...............................................................30 2.4 SCHEMA VALIDATION ...............................................................................................................36 2.5 SOAP ENVELOPE SCHEMA VALIDATION ...................................................................................41 2.6 IMPLICIT XML THREAT PROTECTION ........................................................................................42 2.7 CONTENT-BASED FILTERING ....................................................................................................44 2.8 TRANSFORMING WITH XSL AND XPATH ....................................................................................49 2.9 STYLESHEET CACHING ............................................................................................................52 2.10 SUMMARY ...............................................................................................................................52 LAB 3 SECURING XML MESSAGE CONTENT..........................................................................................55 3.1 PUBLIC KEY INFRASTRUCTURE (PKI) .......................................................................................55 3.2 WS-SECURITY DIGITAL SIGNATURES .......................................................................................57 3.3 WS-SECURITY ENCRYPTION & DECRYPTION ............................................................................63 3.4 DATAPOWER ACCESS CONTROL FRAMEWORK .........................................................................68 3.5 LDAP AUTHENTICATION ..........................................................................................................69 3.6 SECURING WITH SSL ..............................................................................................................71 3.7 SUMMARY ...............................................................................................................................75 LAB 4 PROTECTING WEB SERVICES.......................................................................................................77 4.1 WEB SERVICES AND WSDLS ...................................................................................................77 4.2 ABOUT THE WEB SERVICE .......................................................................................................78 4.3 SETTING UP YOUR WORKSTATION ............................................................................................78 4.4 VERIFY THE SERVICE IS AVAILABLE ..........................................................................................79 4.5 DEFINING THE WEBSPHERE SERVICE REGISTRY AND REPOSITORY SERVER ..............................81 4.6 CREATING THE WEB SERVICE PROXY ......................................................................................81 4.7 WS-POLICY SUPPORT .............................................................................................................85 4.8 SERVICE LEVEL MONITORING (SLM)........................................................................................91 4.9 FEDERATION USING SAML ......................................................................................................92 4.10 SUMMARY ...............................................................................................................................99 LAB 5 WEBSPHERE MQ AND TRANSFORMATION EXTENDER INTEGRATION ................................101 5.1 PROTOCOL BRIDGING: HTTP TO WEBSPHERE MQ ................................................................101 5.2 MQ LAB ENVIRONMENT .........................................................................................................102 5.3 CONNECTING TO AN MQ QUEUE MANAGER ............................................................................102 5.4 TRANSFORMING NON-XML PAYLOADS ...................................................................................105
Contents
Page 1
IBM Software
APPENDIX A. APPENDIX B.
APPENDIX C. APPENDIX D.
APPENDIX E. APPENDIX F.
5.5 EXECUTING THE MAP ON DATAPOWER ...................................................................................108 5.6 SUMMARY .............................................................................................................................110 COMMON DEPLOYMENT SCENARIOS........................................................................................111 XACML SUPPORT..........................................................................................................................113 THE XACML POLICY DOCUMENT ........................................................................................................114 THE XACML AUTHORIZATION REQUEST DOCUMENT ...........................................................................114 XACML AND DATAPOWER .................................................................................................................115 MULTI-BOX MANAGEMENT WITH WEBSPHERE APPLICATION SERVER NETWORK DEPLOYMENT V7.0........................................................................................................................117 THE (XML) THREAT IS OUT THERE .........................................................................................119 NEW TECHNOLOGIES, NEW TEMPTATIONS ............................................................................................119 SPECIFIC TYPES OF XML THREATS......................................................................................................120 NOTICES .........................................................................................................................................123 TRADEMARKS AND COPYRIGHTS..............................................................................................125
Page 2
Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM Software
Overview
This IBM WebSphere DataPower SOA Appliances Proof of Technology (PoT) provides a hands-on experience for those needing to understand how DataPower SOA Appliances can help ease and accelerate the deployment of enterprise SOA implementations. Participants gain an appreciation for the ability of DataPower to meet the demand for fast, secure, and reliable XML processing by creating various configurations that demonstrate a rich array of built-in functionality.
Introduction
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.
Requirements
To complete the labs in this workbook, youll need the following:

A network attached workstation A supported Internet browser (this list is subject to change)

Internet Explorer, version 6 or 7 Firefox 2
Network access to the server virtual machine (VM). Network access to a WebSphere DataPower XI50 Integration Appliance XI50.
Icons
The following symbols appear in this document at places where additional guidance is available. Icon Purpose Important! Explanation This symbol calls attention to a particular step or command. For example, it might alert you to type a command carefully because it is case sensitive. This symbol indicates information that might not be necessary to complete a step, but is helpful or good to know. This symbol indicates that you can fix a specific problem by completing the associated troubleshooting information.
Information
Troubleshooting
Overview
Page 3
IBM Software
Lab 1
Introduction to DataPower SOA Appliances
In this lab, youll gain a high level understanding of the architecture, features, and development concepts related to the family of DataPower SOA Appliances. Throughout the lab, youll get a chance to use DataPowers intuitive Web-based user interface (WebGUI) to explore the various aspects associated with appliance configuration and operation. Upon completing this lab, youll have a better understanding of:

The DataPower SOA Appliances family. DataPower Access Control. DataPower Application Domains. DataPower Web-based User Interface (WebGUI). Configuration Procedures. The various DataPower services. Local file management. DataPower logging capabilities. DataPower device management options. DataPower SOA Appliances Firmware management.
1.1
DataPower SOA Appliances Family
WebSphere DataPower SOA Appliances are a key element in IBM's holistic approach to Service Oriented Architecture (SOA). These appliances are purpose-built, easy-to-deploy network devices to simplify, help secure, and accelerate your XML and Web services deployments.
1.1.1
WebSphere DataPower XML Accelerator XA35
Capable of offloading overtaxed Web and application servers by processing XML, XSD, XPath and XSLT at wirespeed, the XA35 accelerates XML/XSLT processing, increasing throughput and decreasing latency. It combines the XML processing power of multiple servers in a single network device, off-loading heavy lifting from general purpose servers.
1.1.2
WebSphere DataPower XML Security Gateway XS40
The XS40 supports all of the features of the XA35 while adding a host of security functionality. The XS40 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. It acts as a security-enforcement point for XML and Web services transactions. It also offers robust service level management, policy management, and Web services management support, as well as detailed logging and auditing. Features and benefits include:
Incorporates authentication and authorization steps that are fully modular and can be based on either on-board or off-board repositories.
Introduction to DataPower Appliances
Page 5
IBM Software
Offers comprehensive Web services standard (WS-*) support, including full support for Security Assertion Markup Language (SAML), the standards-based solution for federated identity management and Web services access control. It consumes SAML assertions, produces SAML assertions, and makes SAML queries to SAML servers. Offers standards-based, centralized governance and security for your SOA, including support for a broad array of standards such as WS-Security and WS-SecurityPolicy.
1.1.3
WebSphere DataPower Integration Appliance XI50
The IBM WebSphere DataPower Integration Appliance XI50 is the IBM hardware Enterprise Service Bus (ESB), delivering common message transformation, integration, and routing functions in a network device, cutting operational costs and improving performance. It contains all of the features found in the DataPower XA35 and XS40 and adds support for a rich set of varied protocols. Features and benefits include:
Transforms between disparate message formats, including binary, legacy, and XML, and provides message routing and security, MQ/HTTP/FTP connectivity, and transport mediation. Provides transport-independent transformations between binary, flat-text, and other nonXML messages, including COBOL Copybook, ISO 8583, ASN.1, and EDI, to offer an innovative solution for security-rich XML enablement, enterprise message buses and mainframe connectivity. Enhances integration with existing infrastructures with support for WebSphere MQ, IBM IMS Connect, virtual local area network (VLAN) and NFSv4 protocol. Makes application integration a network function, providing transport-independent transformation, routing, and auditing. Provides wirespeed on-ramp to enterprise message buses, integrated message-level security, fine-grained access control, and more secure enterprise application integration.
1.1.4
WebSphere DataPower B2B Appliance XB60
The IBM WebSphere DataPower B2B Appliance XB60 delivers secure trading partner data integration tracking, routing and security functions in a network device, cutting operational costs and improving performance. The XB60 is a non-disruptive technology that allows organizations to extend their existing B2B implementations and internal integration infrastructure, thus delivering rapid return on investment and reduced total cost of ownership. Features and benefits include:
Trading Partner Management for B2B Governance; B2B protocol policy enforcement, access control, message filtering, and data security. Application Integration with standalone B2B Gateway capabilities supporting B2B patterns for AS2, AS3 and Web Services. Full featured User Interface for B2B configuration and transaction viewing; correlate documents and acknowledgments displaying all associated events. Full hardware ESB capabilities.
Page 6
IBM Software
1.1.5
WebSphere DataPower Low Latency Appliance XM70
The IBM WebSphere DataPower Low Latency Appliance XM70 is IBMs unique Low Latency Messaging offering, delivering pub/sub messaging and content-based routing at extreme levels of performance in a network device, cutting operational costs and improving security. The XM70 is a non-disruptive technology that allows organizations to extend their existing messaging infrastructures, thus delivering rapid return on investment and reduced total cost of ownership. Features and benefits include:

Drop-in messaging solution that plugs into existing network infrastructure. Simplified, configuration-driven approach to low-latency, publish/subscribe messaging and content-based routing. Low-latency unicast and multicast messaging, scaling to 1M messages / sec with microsecond latency.
Destination, property and content-based routing, including native XML and FIX parsers. Optimized to bridge between leading standard messaging protocols such as MQ, Tibco, WebSphere JMS and HTTP(S). Full hardware ESB capabilities.
1.2
DataPower Access Control

There are three administrative interfaces that can be used for configuring DataPower SOA Appliances: Command line interface Web-based graphical interface SOAP-based XML management interface.
Through the various administrative interfaces, it is possible to access the entire range of configuration and status data. Access to the various administrative interfaces is tightly controlled through a variety of access control methods.
Access control list. Only hosts with addresses in a listed range can access the DataPower appliance. Accounts, groups, and access policies. Local accounts can be created to gain access to the appliance. Groups facilitate an easy way of managing multiple accounts with similar access rights. Group access rights are defined using an access policy.
Page 7
IBM Software
Role-based Management. Extends local access control to use remote authentication and authorization servers, such as LDAP or RADIUS.
1.3
DataPower Application Domains
Application domains allow administrators to separate a DataPower appliance into multiple logical configurations. For example, in a production environment, a domain may represent a business area like shipping or accounting. In a development environment, each developer may have their own domain for testing. Configurations that are created in one domain are secure from other domains and are not visible. By default, a newly initialized DataPower appliance will have a single domain named default. The default domain should only be used for managing the network configuration and the appliance itself. Application domains allow for easier porting of development domain configurations among appliances without affecting the core network for the appliance. A domain can easily be exported from one appliance and imported into another.
1.4
The DataPower WebGUI
The PoT leader will assign a unique student number to you. Your user ID and application domain is based on your assigned number.
Your User Name is studentNN where NN is your student number. If your student number is 2, then your user name would be student02. Your password is: password Your assigned application domain is the same as your user ID.
Youre now ready to start exploring DataPowers WebGUI. Sign into the WebGUI and change your password using the following steps: __1. __2. __3. Navigate your browser to the following secure URL: https://datapower:9090 Put your user name and password in the appropriate fields. Select your domain from the dropdown list of domains, and then click Login.
Page 8
IBM Software
Since this is the first time you are logging in, youll be requested to change your password. __4. __5. __6. __7. __8. __9. In the Old Password field, type your original password: password In the remaining two fields, type a new password that you will use for the remainder of this Proof of Technology. Click the Change User Password button. In the confirmation dialog box, click the Confirm button. In the success dialog box, click the Close button. Log back into the DataPower appliance with your user name, new password and domain.
Upon successful login, the DataPower Control Panel will be shown.
Page 9
IBM Software
There are several areas in the WebGUI worth noting:
The top banner section contains some basic status information, such as the current user and domain.
The Save Config link is used to save all of your changes into the devices 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 link. The Logout link will end the current session. Any changes you made will remain active.
The left side of the browser window is occupied by the navigation bar. At the top is a link (labeled Control Panel) for quick access to DataPowers control panel. The navigation bar is divided into several sections. Clicking on the section name will expose additional actions within that section.
Status: provides menu options to view the overall status of the device, network connections, configurations, and many other objects within the system. Services: provides options for configuring and managing all of the services available on the appliance. Network: provides menu options that help you work with network configuration and settings. Administration: provides options that help you administer the device, such as creating domains, users, exporting and importing configurations, etc. Objects: contains menu options to create and manage every type of object supported by DataPower.
The body of the page shows the DataPower Control Panel. Its divided into three sections, each that contain a concise set of icons for performing frequently used wizards and tasks.
Services, which provides access to wizards that step you through the creation of a variety of service objects such as a Web Service Proxy or a Multi-protocol Gateway. Monitoring and Troubleshooting, which provides easy access to system logs, troubleshooting tools, Web service monitors and device status pages. File and Administration, which provides easy access to the onboard flash-based file system, a control panel, import and export tools, and a key and certificates management tool.
Page 10
IBM Software
1.5
DataPower Configuration Procedures
There are three phases to the setup and configuration of a DataPower SOA appliance. Each of these phases involves a different set of objects, and often each phase is performed by different enterprise personnel.
1.5.1
Network services and user access configuration phase

This is the first phase of configuration. In this phase, the various objects that control the Ethernet interfaces, packet routing, time services and emergency failure notification are configured. The basic networking values, such as IP addresses, gateways, etc, are provided during installation. For the most part, these objects all reside in the default domain of the appliance and are accessible only to users with administrative privileges. Your student account is setup with developer privileges and therefore doesnt have access to the appliances network configuration details. The image at the left shows the various options that an administrator can access. During the configuration phase, administrators will also setup the various application domains, users, groups, and access policies. User access policies determine who can access the appliance to view or alter its configuration.
1.5.2
Application Development Phase
During this phase, architects and developers create the various services that implement the solutions needed to meet enterprise SOA requirements. This phase is often iterative, as more and more top level services are configured on the appliance. DataPower services can be created in a variety of ways depending on the developers experience level. Configuration wizards provide the fastest means of creating a new service and any related objects. More experienced developers may find it faster to create the configuration objects manually by using the Objects section of the navigation bar. In this PoT, youll have a chance to create objects both using wizards as well as directly through the objects menu.
1.5.3
Production Management Phase
This phase occurs when an appliance is moved into a runtime production environment. Administrators commonly require that the appliance provide the means to produce status updates on a regular and timely basis. It also must provide a quick, secure, and reliable means of upgrade, configuration deployment and backup, and that access to the configuration interface is limited. Objects such as Simple Network Management Protocol (SNMP) communities, statistical monitors, and audit logs are configured as the appliance goes into production.
Page 11
IBM Software
1.6
DataPower Services
DataPower SOA Appliances provide services to process traffic. This section discusses the various service objects and their typical use cases. The Services section of the DataPower control panel contains a group of icons that represent the most commonly used services. The following image shows the service icons available on an XI50:
1.6.1
XSL Accelerator
The XSL Accelerator validates and transforms incoming or outgoing XML documents. An XSL Accelerator service would proxy a backend service, applying all the necessary schema validation and transformations to the incoming document before forwarding the message to the backend service. For response processing (from the server), it can perform content rendering by transforming outbound XML to HTML (or any other markup language) using XSL.
HTTP(S) GET HTML
HTTP(S) GET XML
XML to HTML Transformation
One use case for this service object is XML to HTML rendering. A browser-based client makes a request to a web application. DataPower acts as a proxy between the client and the backend web application server. The GET (or POST) is received by DataPower, and then forwarded to the backend server. The backend server returns raw XML to DataPower, which then transforms the XML to HTML using an XSL template. The template may reside on the DataPower appliance, or be fetched (and cached) from a remote server.
1.6.2
Web Application Firewall

The Web Application Firewall service is designed to provide firewall and security services for standard HTML over HTTP Web application traffic. In addition to protecting against common threats, the Web Application Firewall can enforce specific policies against the data flowing
Page 12
IBM Software
between the browser and the server. For instance, it can enforce cookie existence and value policies, or require that specific form fields contain only certain values.
HTTP POST HTML
HTTP POST HTML
Authentication/Authorization Cookie encryption/decryption Cross-site scripting protection
Session timeout management Name-value input processing/filtering
1.6.3
XML Firewall
The XML Firewall is a general purpose HTTP(S) service that can process both XML and nonXML payloads. A wide array of actions can be applied to both inbound and outbound messages, such as encryption/decryption, digital signatures, XSL transformations, filtering, schema validation, and dynamic routing to name just a few. Checks for XML threats are provided automatically.
A LD
HTTP(S) POST: XML XML
HTTP(S) POST: XML XML
AuthN/AuthZ/Audit Encryption/Decryption Digital sign/verify
Schema validate XSL Transformation Service level monitoring
Any-to-Any Transform Message filtering Content-based routing
Processing policies have access to all HTTP related details (headers, form fields, payload, status, etc.) for both the request and the response and can therefore make decisions or process messages based on the headers existence or contents. A robust authentication and authorization engine, with built-in integration for a wide variety of policy servers (LDAP, IBM Tivoli Access Manager, Kerberos/SPNEGO, IBM RACF, etc.) can apply simple to complex security policies to both inbound and outbound messages. Security protocol mediation, such as HTTP Basic Authentication to SAML, or Kerberos/SPNEGO to IBM Lightweight Third-Party Authentication (LTPA), is easily configured through the WebGUI. Theres support for the latest security standards such as XACML, SAML, WS-Security, WS-Policy and WS-I Basic Profile. The XML Firewall also includes support for some of the latest WS-* standards, including WS-Reliable Messaging and WS-Addressing.
Page 13
IBM Software
1.6.4
Multi-Protocol Gateway
The Multi-Protocol Gateway service builds on the XML Firewalls XML and security functionality by adding support for multiple protocols. In addition to HTTP and HTTPS, the Multi-Protocol Gateway supports MQ, WebSphere JMS, TibcoEMS, FTP(S), SFTP, NFS and IMS. All of these protocols can be mixed and matched as necessary. Messages received over HTTPS can easily be routed to MQ or JMS.
HTT P
(S): X
M TA
ML
SF T
TP or F
( S) :
Tex t
1.6.5
Web Service Proxy
The Web Service Proxy provides all of the same services as a Multi-Protocol Gateway service, however it provides automatic configuration based on one or more Web Service Definition Language (WSDL) files. WSDL files may be obtained through subscriptions to a Universal Description, Discovery, and Integration (UDDI) or WebSphere Service Registry and Repository. A single Web Service Proxy service object can act as a single point of entry for multiple WSDLs, automatically routing (or redirecting) the requests to the appropriate backend service.
HTTP(S
): SOAP
AP
HTTP(S): SOAP
HTTP(S): S O
HTT P( S ): S
AP LD
WS R
OA P
Web Service Proxy
The Web Service Proxy will automatically apply schema validation to both inbound and outbound messages, further assuring message validity. Processing and security policies can be applied not only at the entire service level, but for individual operations within the service as well.
Page 14 Discovering the Value of IBM WebSphere DataPower SOA Appliances
IBM Software
1.6.6
DataPower SOA Appliances and Service Matrix
Not all services are available on all appliances. The following table summarizes which services are available on which appliances:
Service HTTP Service SSL Proxy TCP Proxy XSL Proxy Web Application Firewall XML Firewall Multi-Protocol Gateway Web Service Proxy B2B Gateway Low Latency Messaging XA35 Yes Yes Yes Yes No No No No No No XS40 Yes Yes Yes Yes Yes Yes Yes Yes No No XI50 Yes Yes Yes Yes Yes Yes Yes Yes No No XB60 Yes Yes Yes No Yes No Yes Yes Yes No XM70 Yes Yes Yes No No No Yes Yes No Yes
1.7
__10.
DataPower Flash-based File System

In the Control Panel, click on the File Management icon.
Page 15
IBM Software
You should see the file explorer similar to the one below (additional directories may appear depending on installed hardware options).
The DataPower Flash-based file system has a set of predefined directories. Some directories are shared across domains, such as the store: directory, while others are specific to a single domain such as the local: directory. The following is a list of only the most common directories and their contents: Directory cert: chkpoints: config: local: logstore: logtemp: pubcert: sharedcert: Usage
This encrypted directory contains private key and certificate files used by services within the domain. Each application domain contains one cert: directory. This directory contains the configuration checkpoint files for the appliance. This directory contains the configuration files for the appliance. Each application domain contains one config: directory. This directory contains miscellaneous files that are used by the services within the domain, such as XSL, XSD, and WSDL files. This directory contains log files that are stored for future reference. This directory is the default location of log files, such as the appliance-wide default log. This directory can hold only 13 MB. This encrypted directory contains the security certificates that are used commonly by Web browsers. This directory is shared across domains This encrypted directory contains security certificates that are shared with partners. Each appliance contains only one sharedcert: directory. This directory is shared across domains. This directory contains example style sheets, default style sheets, and schemas that are used by the appliance. Do not modify the files in this directory. Each appliance contains only one store: directory. By default, this directory is visible to all domains. This directory is used by processing rules as temporary disk space. Each application domain contains one temporary: directory. This directory is not shared across domains.
store: temporary:
The Flash-based file system is used for storing DataPower firmware and configuration data as well as service-related artifacts such as XSL stylesheets, keys, certificates, and schema definitions.
Page 16
IBM Software
As you might imagine, the flash memory is limited to about 512 megabytes. Since DataPower isnt used as a file repository, 512 MB is more than sufficient for most enterprise needs. For best practices, static files such as schemas, WSDLs and XSL stylesheets are generally hosted off the box and fetched (and cached) as required. Storing static documents off-box not only reduces the amount of flash storage required, but greatly simplifies the deployment process when multiple DataPower appliances are clustered and share the same configuration. For this Proof of Technology, youll need to upload a few files into your local: directory. The following steps will guide you through that process. __11. Click on the Actions link associated with the local: directory to reveal the actions pop-up menu (see below).
__12. __13. __14. __15. __16.
Click the Upload Files link. Click on the Browse button, and from the c:\labs\lab1 directory select the file named simpleSchema.xsd. Click Open to select the file. Click the Upload button to upload the file into the local: directory. Click the Continue button to dismiss the upload confirmation window.
Page 17
IBM Software
__17.
Click on the small plus sign to the left of the local: directory name to reveal the contents of the local: directory.
1.8
Troubleshooting Tools
During the development phase, there are often times when a service configuration produces unexpected results. DataPower has a number of built-in troubleshooting tools that can help pinpoint the cause of problems. __18. In the Navigation pane (on the left side), click the Control Panel link to redisplay the control panel.
__19.
In the Monitoring and Troubleshooting section, click on the Troubleshooting icon to reveal the troubleshooting tools page.
Page 18
IBM Software
The Troubleshooting page has several tools used for troubleshooting both configuration and network problems.
Ping Remote and TCP Connection Test are used primarily for network connectivity troubleshooting when DataPower reports that it is unable to connect to a remote host. Set Log Level is used to change the DataPower logging verbosity. This is a domain-wide setting which increases or decreases the granularity of messages that DataPower writes to the log. The default log level is error which causes DataPower to only write entries to the log when an error occurs (such as an authentication error, or an XSL compilation error). Generate Log Event is used to write a specific message to the logs. This is often used for testing log targets (discussed in the next section). Generate Error Report and Send Error Report are used when it becomes necessary to engage IBM Support to troubleshoot a problem. Generating an error report will create a special file containing detailed system and trace information used by support engineers. View Running Config allows you to see what parameters are currently in effect for the domain.
1.9
Logging
DataPowers built-in publish-subscribe logging mechanism is robust and flexible. As transactions flow through the appliance, many events occur. Some of these events occur as a result of normal processing, while others occur as a result of an exception such as a transaction being rejected due to an authentication or authorization failure.
1.9.1
Setting the Logging Level to Debug
By default, the logging level is set so that only messages with a maximum priority of Error are written to the system log. In this section, youll change the default log level to debug, resulting in a much more granular level of logging. This not only is helpful is seeing what steps are executing, but helps in troubleshooting when things arent going as expected. __20. __21. __22. __23. In the Logging section, change the Log Level dropdown to: debug Click the Set Log Level button to activate the change. In the Confirmation window, click the Confirm button. Click the Close button to dismiss the window.
Throughout the various DataPower configuration forms, there are links that enable you to view the logs. For example, right above the Log Level is a magnifying glass icon that, when clicked, will open a window showing the system log. You can also view the log from the main control panel. __24. Click on the Control Panel link in the upper left corner of the browser window.
Page 19
IBM Software
__25.
In the Monitoring and Troubleshooting section, click on the View Logs.
Clicking on the View Logs icon will take you to the system log page, which by default shows the last 50 entries in the default log. The interface enables you to filter the entries by category and/or priority, in order to limit the number of lines.
Since there has been minimal activity in your student domain, your log will likely contain only one or two messages. The following image shows a more active log.
For additional filtering, you can click a transaction number, client IP address, or even code. Each of these opens a new window with messages related to the selected value; for example, clicking a transaction ID displays only messages from that transaction.
1.9.2
Log targets
The logging subsystem on DataPower SOA Appliances is based on a publish-subscribe paradigm that enables distribution of selected messages to various protocols and destinations; message selection is a user-configurable process that can select broad message categories and priorities but can also be very granular if necessary. Event messages can be generated by anything on the appliance, including a hardware-level device monitor, a service processing an application transaction, or a stylesheet logging a custom error message.
Page 20
IBM Software
Directing a subset of all log messages to a particular destination/protocol is accomplished through the use of log targets. A log target describes both the endpoint to which the logs will be sent and the events that should be selected for sending. Essentially, a log target is the subscriber in the pub/sub pattern. Log targets capture messages that are posted by the various objects and services running on the appliance. Target types enable additional capabilities that include rotating files, encrypting and signing files or messages, and sending files to remote servers. Messages in log targets can be restricted (filtered) by priority, event code, event category, object type, and IP address. By default, a log target cannot accept messages until it is subscribed to one or more events. __26. In the left side navigation menu, expand the Administration menu.
__27.
Scroll down and locate the Miscellaneous section. Click Manage Log Targets.
__28.
Click the Add button to create a new Log Target.
Page 21
IBM Software
__29.
Locate the Target Type field and click the dropdown to reveal the list of available log target types that you can create. You should see a list similar to the following image.
The dropdown list shows the various log target types supported by the DataPower logging subsystem.
Console: Writes log entries to the screen when using Telnet, Secure Shell (SSH), or command line access through the serial port. Cache: Writes log entries to system memory (this is how the default log is setup). syslog: Forwards log entries using User Datagram Protocol (UDP) to a remote syslog daemon. syslog-ng: Forwards log entries using Transmission Control Protocol (TCP) to a remote syslog daemon. SMTP: Forwards log entries as email to the configured remote SMTP servers and email addresses. Before sending, the contents of the log can be encrypted or signed. File: Writes log entries to a file on the appliance. SOAP: Forwards log entries as SOAP messages. SNMP: Forwards log entries as SNMP traps to configured recipients. NFS: Writes log entries to a file on a remote Network File System (NFS) server.
1.9.3
Log Categories
Log targets filter captured messages by event category. The use of categories allows log targets to subscribe to highly targeted messages, such as appliance messages, network messages, or particular service messages. In addition to the predefined log categories specific to DataPower objects and operations, you can create your own custom log categories which are more specific to your applications. __30. Back in the Administration section of the left navigation pane, locate and click on the Configure Log Categories link. A list of all predefined log categories will be displayed.
Page 22
IBM Software
1.10 Device management

There are a number of methods that administrators can use to manage DataPower SOA Appliances. These methods include:
1.10.1 Backup and Restore

Administrators can use the Export Configuration utility to export a complete appliance back-up or export selected portions of the appliance configuration. The Import Configuration utility is used to restore a complete appliance back-up or selected portions of an exported configuration. __31. __32. __33. __34. __35. At the top of the left navigation pane, click the Control Panel link. In the bottom row of icons, click the Export Configuration icon. Leave the default selection of Export configuration and files from the current domain and click the Next button. Change the Export File Name field to: MyExport Under the heading Select configuration objects to export, make sure All Objects is selected; then click the right pointing button to move the selected objects into the Selected Objects box.
When you click the right pointing arrow, the right side box will become populated with all of the objects in your domain. The objects in the right box will be the objects that are exported. __36. Click the Next button.
The export file named MyExport is now created and ready for you to download to your workstation. __37. __38. Click the Download button. Youll be prompted for a location to save the exported file. You can save the file anywhere on your workstation. Click the Done button.
The file you just downloaded contains a complete backup of your application domain. The MyExport file could be imported into another DataPower appliance to replication purposes.
1.10.2 Device Status

The DataPower built-in monitoring subsystem can provide complete details as to the operational status of the appliance, including firmware and library information as well as memory usage, CPU utilization and hardware operational circumstances. All of this information is viewable from within the WebGUI as well as through remote monitoring tools (discussed in the next section). __39. __40. In the left navigation pane, click on the Status menu to reveal the various status sections. Locate the System section and explore the various status details.
Page 23
IBM Software
1.10.3 Remote monitoring

Administrators can monitor the health and activity of the appliance with any of the following protocols:

SNMP Web Services Distributed Management (WSDM) WS-Management Proprietary SOAP application programming interface (API)
Remote consoles such as SNMP console, or an IBM Tivoli Composite Application Manager for SOA console, can display throughput, CPU and memory usage, transaction latency, and general responsiveness of an appliance with these protocols. The following image shows a simple SNMP Management Information Base (MIB) Browser showing DataPower memory usage statistics.
Page 24
IBM Software
1.10.4 Configuration Comparison, Checkpoint, and Restore

Administrators can use the Configuration Comparison utility to determine what has changed between current and saved configurations, including previously exported configurations. Configuration checkpoints can be set at any time within an application domain. An administrator can then compare these checkpoints to any other configuration or roll-back the configuration of a domain to an existing checkpoint.
1.11 DataPower SOA Appliances Firmware

Unlike traditional servers which require an operating system and various layers of installed software, DataPower SOA Appliances rely on a single firmware image which provides all of the functionality. Updating the firmware in a DataPower appliance is a fast and simple process. The firmware image is first downloaded from IBMs support site, then uploaded to DataPower. Once uploaded, DataPower will verify the authenticity of the firmware, then decrypt and apply it. The previously running firmware is maintained on the device in the event a rollback is necessary.
1.12 Summary
In this lab, you learned:

About the various tools and procedures used to configure DataPower SOA Appliances. That configuration is accomplished through any of three administrative interfaces (command line, WebGUI, and SOAP-based XML interface) and had some exposure to using the WebGUI. How to upload a file to the local: directory in the Flash-based file system. How DataPower controls access to its administrative interfaces through the use of access control lists, user accounts, groups, and access policies. About application domains, and how they allow a single DataPower appliance to be partitioned into multiple logical devices. About the three phases of DataPower configuration (network services/user configuration phase, application development phase, and production management phase). About the various DataPower services that you can use to create simple to complex processing policies (XSL Accelerator, Web Application Firewall, XML Firewall, MultiProtocol Gateway, and Web Service Proxy). How the DataPower built-in logging subsystem is based on the publish-subscribe paradigm, with log targets acting as subscribers to specific message categories. How DataPower provides complete system status and metrics from the WebGUI. That DataPower supports various monitoring protocols such as SNMP, WSDM, and WS-Management.
Page 25
IBM Software
Lab 2
Working with XML
In this lab, youll create a fully functional Multi-Protocol gateway service that will perform various functions against a request containing an XML (SOAP) payload. Upon completing this lab, youll have a better understanding of:

How messages are processed. DataPowers object-oriented configuration architecture. The Multi-Protocol Gateway service configuration. Front-side protocol handlers. Configuring Processing Policies, Rules, and Actions. Matching Rules. Validating XML documents against a schema. DataPowers built-in XML threat protection and virus scanning support. Content-based Message Filtering. Transforming XML with XSL and XPath. DataPowers XSL caching mechanism.
2.1
Proof of Technology Network Topology
During this Proof of Technology, youll actually be creating several fully functional DataPower services that connect to a backend server. The backend server components needed for the various labs are running on the instructors workstation. The following diagram details the various hardware and software components used for this Proof of Technology.
Working with XML
Page 27
IBM Software
2.2
Service Processing Phases
When a service receives a message from a designated IP and port, a sequence of events are set into motion before the message is ultimately forwarded to its intended destination. The events are separated into three distinct phases: client-side processing, service processing, and server-side processing.
Request
Client-Side Processing Phase
Service Processing Phase (Multistep Scope)
Server-Side Processing Phase
Response
2.2.1
Client-Side (Front) Processing Phase
During this phase, DataPower will direct the received message to the service object that is configured for the IP address and port combination on which the message was received. Once the service object (such as a Multi-Protocol Gateway or XML Firewall) receives the message, a significant amount of processing of the message occurs. For example:
If SSL is configured for the service, SSL negotiation and decryption of the data stream will occur. SOAP envelope validation. Protocol-specific actions such as HTTP header suppression or injection.
This is not an exhaustive list, but gives an idea of some of the actions that occur upon receiving a message. The results of these pre-processing steps could result in the message being rejected before any message processing is even attempted.
2.2.2
Service Processing Phase
Once the message has been accepted from the front-side processing, DataPower will execute the services processing policy. This is often referred to as Multistep processing. A Processing Policy is a list of rules that contain processing actions that can be applied to a message. Actions are specific processing operations that can be applied to a message such as encryption and decryption, message signing, authentication, etc. As the request message passes through the processing policy, the actions are applied to the message in a specified sequence, ultimately resulting in a message that will be passed to the server-side processing phase.
Page 28
IBM Software
2.2.3
Server-Side (Back) Processing Phase
If the message makes it to this phase, it has been accepted by the client-side phase and processed by the service phase. Its now ready to be sent to the backend server. Before sending though, some additional steps may be required. Those steps occur in this phase and may include:

Establishing a new SSL connection to the back side server. Setting additional headers in the request. Mediating protocol versions (i.e. HTTP 1.1 to HTTP 1.0). Other protocol related tasks for MQ, FTP, NFS, etc.
Once all of the server-side processing is complete, the message is sent to the backend destination.
2.2.4
Response Processing
When (and if) a response is received from the backend server, a similar sequence of phases will occur to verify the validity of the response, execute a processing policy, and then forward the response back to the original client. The processing phase can be configured to have separate rules for request and response processing.
2.2.5
DataPower Configuration Architecture
A single DataPower appliance has the ability to host numerous service configurations. The following diagram shows a top-level object hierarchy of a DataPower service.
= Object = Service Parameter = File
DataPower Service
Threat Protection and Protocol Parameters
Front Side Handler
SSL Proxy
Backend Server Address
Processing Policy
XML Manager
Supporting Protocol Objects
Crypto Profile
Processing Rules
Key/Certificate Objects
Processing Actions
Match Rule
Key/Certificate Files
AAA Policy
XSL/XML Files
This diagram attempts to show some of the objects associated with a given DataPower service. For example, the top DataPower Service could be a Multi-Protocol Gateway service that you create for handling requests. That service will use a Front Side Handler object (possibly for HTTP, which identifies an IP address and port). It may or may not need an SSL Proxy object if your service requires the use of
Working with XML Page 29
IBM Software
SSL. The service will have a Processing Policy (for the service processing phase), and that policy contains one or more Processing Rules, and each rule contains one or more Processing Actions. Some of the objects will be created for you as a by-product of configuration wizards, and others will be created simply by dragging and dropping an icon in the WebGUI.
2.3
Creating the Multi-Protocol Gateway service
In this section, youll be creating a service that will receive messages posted from your workstation, and perform a variety of actions against the messages XML payload. There are several steps youll follow to create the service object:

Specify the basic information about the Multi-Protocol Gateway Service. Create an HTTP Front Side protocol handler to handle HTTP requests. Create a Processing Policy and Processing Rule
To get things started, lets create a service that simply acts as a pass-thru. Whatever you post to the service will get forwarded to an echo service running on the server. The response will pass back through DataPower and be displayed in your console window. The following steps will guide you through the process of creating and testing your service. If you logged out from the WebGUI, log back in with your assigned user id and password. Make sure to select the matching domain for your user id. __1. __2. If the control panel is not visible, click on the Control Panel link at the top of the left navigation pane. Click on the Multi-Protocol Gateway icon.
__3. __4. __5.
Click the Add button to create a new Multi-Protocol Gateway service. The Configure Multi-Protocol Gateway form will be displayed. In the Multi-Protocol Gateway Name field, type: MyService In the Backend URL field, type: http://demoserver:9080/EchoService/echo
Important! The URI portion of the URL is case sensitive. Make sure that you type EchoService/echo exactly as shown.
Page 30
IBM Software
__6.
Scroll down towards the bottom of the form and locate the Propagate URI field. Select Off. This field will cause any inbound URI to override the URI specified in the backend URL field. For instance, if the propagate URI switch is set to on and a request arrives with a URL of http://datapower:9080/myecho, then the service would attempt to forward the request to http://demoserver:9080/myecho instead of http://demoserver:9080/EchoService/echo. Turning this switch to off will guarantee that the URI specified in the Backend URL will be honored.
2.3.1
Creating the Front Side Handler (FSH)
The Multi-Protocol Gateway service employs one or more Front Side Handlers to manage all inbound traffic. In a simple configuration, there might be a single HTTP front side handler that listens for requests on a specific IP address and port.
In the scenario shown in the previous illustration, requests arrive over HTTP and are received by the HTTP front side handler. The HTTP FSH will then pass the request to the MPGW for processing. Its also possible to mix and match different types of protocols on the same multi-protocol gateway. For example, you can assign one FSH for HTTP, another for HTTPS, and yet another that acts as an MQ client.
HTTP FSH HTTPS FSH MQ FSH
Multi-Protocol Gateway
The server-side protocol is completely independent of the front-side and can be any of the protocols supported by the appliance.
Working with XML
Page 31
IBM Software
For this lab exercise, youll create a single HTTP Front Side Handler and assign it to the multi-protocol gateway. __7. In the middle of the form towards the right is a section labeled Front side settings. Locate and click the plus (+) button to create a new front side handler.
A pop-up list of front side handlers will be displayed. You can see from this list that the Multi-Protocol Gateway service supports many different front-side protocols. __8. In the pop-up list of front side handlers, click: HTTP Front Side Handler
The options provided in the pop-up 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 or not to use persistent connections. __9. __10. __11. __12. In the Name field, type a name for this listener: MyHttpFSH. Leave the Local IP Address field as 0.0.0.0. This will cause the front side handler to listen for traffic on all IP addresses defined on the appliance. In the Port Number field, replace the default port 80 with 444nn where nn is your student number. For example, if you are student01, use port 44401. Click the Apply button in the upper left corner of the form. The new HTTP FSH should be automatically added to the list of Front Side Protocols (see below).
2.3.2
Processing Policies, Rules, and Actions
Each service that you configure on DataPower will have exactly one Processing Policy. The processing policy defines exactly what should happen when a message arrives from either the client (request), or the server (response). A processing policy is comprised of one or more Processing Rules. A processing rule always begins with a Match Action, followed by one or more Processing Actions. Processing rules are identified as either request, response, both, or error types. A processing rule that is indicated as a request rule will be
Page 32
IBM Software
ignored during response processing. A processing rule that is identified as both will be evaluated for both requests and responses. Error rules are executed only when an error occurs during processing.
Multi-Protocol Gateway Processing Policy Processing Rule #1
[ Req | Rsp | Both | Error ] Match Action Processing Action #1 Processing Action #2
Processing Action #N
Processing Rule #2
[ Req | Rsp | Both | Error ]
Match Action
Processing Action #1
Processing Rule #N
[ Req | Rsp | Both | Error ]
Match Action
The Match Action references a Match Rule that contains one or more matching criteria (or expressions) that are evaluated to determine whether or not to execute the remaining actions in the processing rule. When more than one match expression is defined, the match rule can specify whether to combine them with Boolean AND or OR semantics. When the match rule is configured to use OR, only one of the match expressions must be True; when AND is specified, all expressions must evaluate to True.
Match Rule evaluate statements using: AND | OR Match Expression: URL | HTTP Header | XPath | Error Code Match Expression: URL | HTTP Header | XPath | Error Code
Match Expression: URL | HTTP Header | XPath | Error Code
Matching expressions can test the message in several ways. For instance, in this lab youll be specifying a matching expression that inspects the request URI for a specific pattern. Matching rules support the following types of matching expressions:

URL: A match template that inspects the URL for a specific pattern. HTTP: A match template that inspects the value of a specified HTTP header for a specific pattern. Error Code: A match template that matches against specific error codes that may have been raised by previously executed processing rules. XPath: A match template that uses the specified XPath expression to inspect the contents of the XML message body.
When a message arrives into the processing policy, DataPower will look at each processing rule, starting with the first one, and evaluate its associated match rule. If the match rule evaluates to True, DataPower will start executing the processing actions in that processing rule. If the match rule evaluates to False,
Working with XML
Page 33
IBM Software
the entire processing rule will be ignored and the process will repeat starting with the next processing rule. Once a match rule evaluates to True, no other match rules will be evaluated. Only one processing rule will be executed. __13. In the General Configuration section of the form on the right side, locate the field labeled Multi-Protocol Gateway Policy and click the plus (+) to create a new processing policy.
__14. __15. __16.
In the Policy Name field at the top of the policy editor, type: MyServicePolicy In the Rule section, click on the New Rule button. Change the Rule Name to: EchoRule
After you click the new rule button, a blank rule will be created that contains a match action.
For this lab, youll create a match rule that will match on any inbound URI. __17. __18. __19. __20. Double click the match action to reveal its configuration form. In the Configure a Match Action form, click on the plus (+) button to create a new matching rule. In the Configure Matching Rule form, in the Name field, type: MatchAnyURI At the top of the form, click on the Matching Rule tab.
Page 34
IBM Software
__21. __22. __23. __24. __25. __26. __27. __28. __29.
At the bottom of the list of matching rules, click the Add button to create a new expression. Leave the Matching Type field as URL. In the URL Match field, type: * (The asterisk is a wildcard character that will match anything). Click the Apply buton. In the Configure Matching Rule window, click the Apply button. In the Configure a Match Action window, click the Done button. Click the Apply Policy button to save these changes. When you do this, DataPower will insert a Results action into the processing rule. Click the Close Window link in the upper right corner to dismiss the policy editor. In the Configure Multi-Protocol Gateway form, click the Apply button to activate this new configuration.
You are now ready to test the service you just created. __30. __31. __32. Open a new command window. One way to accomplish this is to click the Windows Start button, select Run, and type cmd in the open field. At the command prompt, use the CD command to change directory to c:\labs\lab2. Type the following command, and replace the NN with your student number: post soapMsg.xml http://datapower:444nn
If you received an error, you can try and determine the cause by looking at the logs. Theres a convenient View Log link found towards the top of the Multi-Protocol Gateway configuration page. You can also view the logs from the main control panel by clicking on the View Logs icon.
Working with XML Page 35
IBM Software
At this point, you have created a multi-protocol gateway service that acts as a pass-thru and verified that it works. Now youll add some more interesting functionality to the service.
2.3.3
Save the Running Configuration
Once you have your configuration running properly, its a good idea to save the configuration to DataPowers flash memory. At this point, if the device was shut off or the power was disconnected, all of the work youve done until now would be lost. Saving the configuration causes DataPower to save your domain to the flash memory, making it available after the device is restarted. __33. At the top of the browser window, click on the Save Config link. You should see a message that says Configuration successfully saved.
2.4
Schema Validation
An XML Schema describes the structure of an XML document. Validating an XML document against a schema is one step to assuring that the structure and content of the document are valid and safe. The process of validating an XML document against a schema is generally considered to be processor intensive, resulting in increased server load. For this reason, schema validation is often disabled to reduce load (and cost) on application servers. This is considered a security risk. DataPower SOA Appliances solve this problem by providing wirespeed schema validation to messages before they reach the application server. Messages that fail validation are rejected by default (this behavior can be customized). In this section, youll add a new processing rule to your service that will ultimately perform a variety of actions against the inbound XML message. __34. If your browser is still showing the Configure Multi-Protocol Gateway page, you can jump to the next step; otherwise youll need to display it again. Use the following steps to get back to the Multi-Protocol Gateway configuration page for your service. __a. Click on the Control Panel link in the upper left part of the navigation pane. __b. Click on the Multi-Protocol Gateway icon to show the list of MPGW services. __c. Click on the service named MyService. __35. Click on the ellipsis () button next to the Multi-Protocol Gateway Policy.
__36.
Click the New Rule button to create a new processing rule.
Page 36
IBM Software
__37. __38. __39. __40. __41. __42. __43. __44. __45. __46. __47.
In the Rule section, change the Rule Name to: DemoRule Change the Rule Direction dropdown to: Client to Server. This rule should only execute on inbound requests (not server responses). Double click the Match Action icon (outlined in yellow) to configure a new matching rule. Click the plus (+) button to create a new matching rule. In the Name field, type: MatchXML At the top of the window, click on the Matching Rule tab. In the Matching Rule section, click the Add button to create a new expression. Leave the Matching Type as URL; for the URL Match, type: */xml Click the Apply button. In the Configure Matching Rule window, click the Apply button to save the new matching rule. In the Configure a Matching Action window, make sure the new matching rule (MatchXML) is in the dropdown list, and click Done.
Now youll add a schema validate action to the processing rule. Youll configure the Validate action to use the schema you uploaded (simpleSchema.xsd) in the first lab. __48. Click and drag a Validate action and drop it to the right of the matching action.
__49.
Double click the new validate action (outlined in yellow) to provide the missing configuration details.
There are several methods listed for the Schema Validation method. This is a good opportunity to see DataPowers online help. __50. Move the mouse over the field label Schema Validation Method. You should notice that it is actually a hyperlink. Almost all field labels in the DataPower WebGUI are hyperlinks and when clicked, will pop up a help window to explain the various options for that field.
Working with XML
Page 37
IBM Software
__51. __52. __53.
Click the Schema Validation Method label to show the help text. Close the help text window by clicking its close button. Select the radio button associated with: Validate Document via Schema URL. Selecting this option allows you to identify what schema file (XSD) to use. In the Schema URL, make sure the upper dropdown contains local:///. In the lower dropdown list, select simpleSchema.xsd that you previously uploaded. The Validate configuration window should look like the following image.
__54.
Click the Done button at the bottom of the window.
The processing rule is now complete, however theres one very important step that you must do before the policy will function properly. At the bottom of the policy editor window, theres a section labeled Configured Rules (you may have to make the policy editor window bigger). This section shows all of the rules that are in effect for this policy (see following image).
As explained previously, processing rules execute from top to bottom until a matching rule evaluates to True. The first rule (EchoRule) has a match action that will match any URL, therefore it will always evaluate to True and DemoRule will never have an opportunity to execute. You can see this by hovering the mouse over the match action icons in the list of rules.
Page 38
IBM Software
To solve this problem, youll need to move the EchoRule down below the DemoRule (or move DemoRule up above EchoRule). Use the Up/Down arrow buttons on the left side to rearrange the rule order. Assure that DemoRule is the first rule in the list. __55. Click the down arrow button next to EchoRule to move it down in the list. The correct order for the rules should look like the following image.
__56. __57. __58.
Click the Apply Policy button at the top of the policy editor to activate all your changes. DataPower will add a results action to the end of DemoRule. Click the Close Window link to close the policy editor. Click the Apply button in the Configure Multi-Protocol Gateway form. This will apply all changes to the service and make them active.
Youre now ready to test the service you just created. First, take a look at the inbound SOAP message.
Listing of file: 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>
Working with XML
Page 39
IBM Software
If youre 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 the various DataPower SOA Appliances models (XA35, XS40, etc.).
Listing of file: 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:enumeration value="XB60"/> <xs:enumeration value="XM70"/> </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> __59. In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post soapMsg.xml http://datapower:444nn/xml Notice the URI
If everything worked as expected, you should see the contents of the XML file echoed back to the console window. This indicates that the message passed the schema validation test. 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. The schema restricts the values of product-id to XA35, XS40, XI50, XB60, and XM70, but the file has 1234 as the product-id. __60. Post the soapBadProduct.xml file to the service as you did in the previous step. You should receive a SOAP fault instead of the original XML document. post soapBadProduct.xml http://datapower:444nn/xml
Page 40
IBM Software
The error message returned from DataPower indicates that an internal error occurred but no other details are provided. This is by design to prevent malicious attackers from gaining details information about the underlying service. You can see detailed information about the failure in the DataPower logs. __61. In the Multi-Protocol Gateway configuration page, click on the View Log link towards the top of the form (see below).
The log will reveal the underlying reason for the Internal Error message.
__62. __63.
Close the log window by clicking on the Windows close button (upper right corner of window). If your configuration is working properly, click the Save Config link in the upper right corner of the window to save your configuration to the flash memory.
2.5
SOAP Envelope Schema Validation
The Multi-Protocol Gateway service that you configured expects inbound messages to conform to SOAP standards. This setting is found towards the middle of the Multi-Protocol Gateway main configuration page (see following image).
Working with XML
Page 41
IBM Software
Selecting SOAP directs the service to check the inbound message (and in this case, the servers response) for a valid SOAP envelope. This validation assures that the inbound request, as well as the returned response, contains a valid, well-formed SOAP envelope. Now post a message that does not contain a SOAP envelope. __64. In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post noSoapEnv.xml http://datapower:444nn/xml You should receive a generic SOAP fault instead of the original message. __65. As you did earlier, locate and click the View Log link at the top of the Multi-Protocol Gateway configuration page. Notice the last logged message indicates a SOAP envelope or body validation error.
__66.
Close the pop-up log window by clicking the close button.
2.6
Implicit XML Threat Protection
DataPower services that are configured to receive XML messages provide a wide array of additional XML threat protection.
2.6.1
Malformed XML Content Detection
In this next step, youll post a malformed XML document to your service. The message appears valid, but in fact contains malformed XML. Notice that the second highlighted tag has a trailing X in the tag.
Listing of file: malformed.xml <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ...{omitted}... <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-infoX> </soap:Body> </soap:Envelope>
Page 42
IBM Software
__67.
In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post malformed.xml http://datapower:444nn/xml
You should receive a generic SOAP fault instead of the original message. __68. Click the View Log link at the top of the Multi-Protocol Gateway configuration page. The log clearly indicates a mismatched tag, resulting in a parse error.
__69.
Close the pop-up log window.
2.6.2
XML Denial of Service (XDoS)
DataPower can protect web services against both single message (XDoS) and multiple message (MMXDoS) denial of service attacks. Single message XDoS attacks may have any combination of the following characteristics:
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 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, resulting in excessive resource consumption in the target 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.
Multiple message XDoS (MMXDoS) attacks may have the following characteristics:
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.
Working with XML
Page 43
IBM Software
__70.
At the top of the Multi-Protocol Gateway configuration form is a set of tabs. At the right and left side of the tabs are arrow images. Moving the cursor over the arrow (without clicking) will cause the tabs to shift left or right. Move the mouse over the right arrow until the XML Threat Protection tab is visible.
__71. __72.
Click on the XML Threat Protection tab. In the Single Message XML Denial of Service section, click the on radio button for Gateway parser limits. Notice that DataPowers XDoS protection is highly customizable.
__73. __74. __75.
Click the off button for Gateway parser limits. In the Multiple Message XML Denial of Service section, click the on radio button for Enable MMXDoS Protection. Click the off button for Enable MMXDos Protection.
2.6.3
Virus Scanning
Viruses are typically contained in message attachments. XML Virus Protection sets parameters that handle the following types of attacks in attachments:

XML virus attacks XML encapsulation attacks Payload hijack attacks Binary injection attacks
There are two levels of protection against virus threats.
The first level is to determine whether or not to allow attachments. This is accomplished on the XML Threat Protection tab that is currently displayed in your browser in the XML Virus (X-Virus) Protection section. If attachments are allowed, the second level of protection occurs in the processing rule. A special Virus Scan action will extract the attachment from the message and send it to an ICAP compatible virus scanner. If the scanner responds that a virus exists in the attachment, the virus scanning action will either strip the attachment or reject the message (based on configuration settings).
2.7
Content-based Filtering
You can easily extend DataPowers built-in threat protection by defining custom filters. A custom filter is an XSL template that makes an accept or reject decision based on some custom logic that you define.
Page 44
IBM Software
The accept and reject decision are accomplished using IBM DataPower extension functions for XSL. The <dp:accept> and <dp:reject> extension functions are used to tell DataPower how to proceed with the message. The following XSL template inspects the <brand> element to make sure that it contains the word DataPower.
Listing of file: customFilter.xsl <xsl:template match="/"> <xsl:choose> <xsl:when test="contains(//brand,'DataPower')"> <dp:accept/> </xsl:when> <xsl:otherwise> <dp:reject>Missing 'DataPower' trademark</dp:reject> </xsl:otherwise> </xsl:choose> </xsl:template>
Now youll add a filter action to your processing rule. __76. In the Multi-Protocol Gateway configuration page, click on the General tab. You may have to use the left or right arrow icons to scroll to the General tab if its not visible.
__77.
Click on the ellipsis () in the Multi-Protocol Gateway Policy field.
__78.
In the policy editor window, drag a filter action onto the rule as shown below.
Working with XML
Page 45
IBM Software
__79. __80. __81. __82. __83. __84. __85.
Double click the yellow outlined filter action to complete its configuration. In the Processing Control File section, click the Upload button. In the File to upload field (in the pop-up window), click the Browse button. Navigate to your labs/lab2 folder and select customFilter.xsl; then click the Open button. Click the Upload button to upload the file to DataPower. Click the Continue button to dismiss the success window. In the Configure Filter Action window, click the Done button.
The processing policy should now look like the following image.
__86. __87.
Click the Apply Policy button to make your changes active. Click the Close Window link to close the policy editor.
Now run a test to make sure everything works properly. First, run a good message through. __88. In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post soapMsg.xml http://datapower:444nn/xml If everything worked as expected, you should see the contents of the XML file echoed back to the console window. This indicates that the message passed the schema validation test AND the custom filter. __89. Now post a message that is missing the word DataPower from the <brand> element. post missingDp.xml http://datapower:444nn/xml You should receive a SOAP fault with an error message indicating the DataPower trademark is missing.
Page 46
IBM Software
2.7.1
SQL Injection Threat Filtering
SQL Injection is an attack technique used to exploit web sites and services that construct SQL statements from user-supplied input. For example, assume that a web service expects a SOAP request containing a <last-name> element used for looking up a customer.
<soap:Body> <customer-lookup> <last-name>KAPLAN</last-name> </customer-lookup> </soap:Body>
The web service uses an SQL statement with substitution parameters similar to the following SQL snippet: SELECT * FROM EMPLOYEE WHERE LASTNAME = ? After the substitution takes place, the resultant SQL statement will be: SELECT * FROM EMPLOYEE WHERE LASTNAME = 'KAPLAN' However, if the value submitted in the <last-name> element contained a malicious SQL injection threat, it may look 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, since the WHERE clause will evaluate to true for every record in the EMPLOYEE table (because of the 1 = 1 clause). DataPower SOA Appliances can protect against such SQL injection threats using a special SQL injection threat filter. It works the same way as the filter you tried in the previous steps, except that the logic is a bit more complex. The SQL Injection Threat filter has two parts: the base stylesheet filter (that uses <accept/> and <reject/>), and an XML file that contains the various patterns to search for. Keeping the patterns in a separate XML file allows you to create more customized patterns. __90. Click on the ellipsis () in the Multi-Protocol Gateway Policy field.
Working with XML
Page 47
IBM Software
__91.
In the policy editor window, drag another Filter action onto the processing rule to the right of the previously added filter action (see below).
__92. __93.
Double click the yellow outlined filter action to complete its configuration. In the Processing Control File field, change the upper dropdown to show: store:///. In the lower dropdown box, select: SQL-Injection-Filter.xsl
__94. __95. __96. __97.
Click the Done button. Click the Apply Policy button to activate these changes. Click the Close Window link to close the policy editor. Click the Apply button in the Configure Multi-Protocol Gateway form.
The policy will now protect against malicious SQL injection threats. The file sqlThreat.xml contains a SOAP message with an SQL Injection Threat in it. The contents of the <brand> element contain the threat:
<product-info> <product-id>XI50</product-id> <brand>DataPower' or '1'='1</brand> <encoded-description>{omitted}</encoded-description> <benefits>Security;Integration;Performance</benefits> </product-info>
__98.
In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post sqlThreat.xml http://datapower:444nn/xml
Page 48
IBM Software
In the preceding screen image, the red underlined area shows that the message was rejected due to restricted content.
2.8
Transforming with XSL and XPath
At the heart of DataPower SOA Appliances is a high speed XSL compiler and execution engine. In fact, most built-in functionality provided by DataPower is engineered using XSL. Some of the built-in stylesheets can be found in the store: directory. XSL developers can easily copy and modify the IBM provided stylesheets to create new functionality or support emerging standards before IBM makes them available. When a stylesheet is referenced for the first time, it is compiled using a patented optimizing XSL compiler for execution on specialized DataPower hardware, then cached in memory for high-speed recall and execution. IBM has augmented XSL with a rich set of extension functions that enable you to easily add complex processing functionality to your processing rules. For example, there are extension functions for performing base-64 encoding and decoding, encryption and decryption, date and time functions, as well as the ability to open an HTTP connection to an off-device server. In this section, youll be introduced to how XSL templates are used within DataPower processing rules. Youll also get a chance to use the decode() extension function for decoding base-64 encoded text. __99. As you did before, open the policy editor by clicking on the ellipsis in the Multi-Protocol Gateway Policy field.
Working with XML
Page 49
IBM Software
__100. Click and drag a transform action and drop it after the last filter.
__101. Double click the yellow outlined transform action to complete its configuration. For this transform, the stylesheet will be located on a remote HTTP server rather than in your local: directory. __102. In the top dropdown of the Processing Control File field, select http://. In the lower text box, type: demoserver/files/productTransform.xsl __103. Click the Done button to save the transform action. __104. Click the Apply Policy button to apply the changes to the overall policy. __105. Click the Close Window link to dismiss the policy editor. __106. Click the Apply button in the Configure Multi-Protocol Gateway form. Youre now ready to run another transaction through your multi-protocol gateway service. Before you do that, lets take a look at what the XSL template will do to the message. Heres the SOAP body of the inbound message. Notice the <encoded-description> tag contains base-64 encoded text (some of it has been omitted).
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 for two different patterns:
When a <encoded-description> tag is encountered, it will change it into a <description> tag and then decode the original tags value. dp:decode() is a DataPower extension function that will perform the base-64 decoding.
Page 50
IBM Software
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. An identity transform is found at the end of the template, which will match anything else that hasnt explicitly been matched, and copy it to the output document.
Partial Listing of file: 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>
__107. In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post soapMsg.xml http://datapower:444nn/xml
Working with XML
Page 51
IBM Software
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. __108. If youve gotten everything working properly, you can save your configuration by clicking the Save Config link in the top of the browser window.
2.9
Stylesheet Caching
XSL stylesheets are compiled and then cached to improve performance. Previously you configured your processing rule to transform the request XML document against productTransform.xsl. The stylesheet was fetched from a remote server, compiled, and then cached. You can verify this by checking the status of the document cache. __109. In the left hand navigation pane, under the Status menu, scroll down to find the XML Processing section, and click on Stylesheet Cache. In the cached stylesheets column, you can see the number of stylesheets that DataPower has compiled and cached (this value also includes some system stylesheets). __110. In the XML Processing section, click on Stylesheet Status The Stylesheet Status page shows you all of the stylesheets that have been compiled and cached. Since schema documents (XSD) are compiled like stylesheets, they show up in this list too.
2.10 Summary
In this lab, you learned:
That there are three service processing phases that occur each time a message arrives. The client-side processing performs all protocol related processing as well as shielding against a variety of malicious attacks. The service processing phase contains all of the specific rules and actions that you define. The server-side processing phase is where any backside protocol tasks are performed before the message is forwarded to the intended destination. DataPower configurations are built using a pure object-oriented design. Every configuration object in DataPower, such as a SSL Proxy Profile or a Processing Policy, can be reused. How to configure a Multi-Protocol Gateway service, along with an HTTP Front Side protocol handler, and a Processing Policy. A Processing Policy contains a set of Processing Rules; each rule begins with a Match Action that is evaluated to determine whether the rule should be executed. Each processing rule contains a list of processing actions that are executed against the message. Match rules can match on various aspects of a message, including the URL, HTTP headers, error codes, or an XPath that inspects the XML payload of a message. The order of match rules is important. Once a match rule evaluates to True, no other match rules will be evaluated. Match rules that are catch-all rules, such as matching a URL pattern of *, should always be the last rule in the list.
Page 52
IBM Software
Clicking the Save Config link in the top navigation area will save your running configuration (for your domain) to DataPowers flash memory. The running configuration and the saved configuration are independent. How to add a schema validate action to the processing rule by dragging it from the action palette onto the processing rule. DataPower can perform schema validation against messages at near wire-speed, adding minimal latency to the overall transaction time. DataPower will automatically check SOAP requests and responses against a SOAP schema, assuring that the SOAP envelope is well-formed and correct. DataPower checks request and response XML documents are well-formed and rejects malformed messages. Custom Filters can be used for content-based message filtering and SQL injection threat protection. How to transform an XML document using a Transform action. DataPower compiles and caches XSD and XSL stylesheets, and how to see the contents of the cache. Content-based Message Filtering.
Working with XML
Page 53
IBM Software
Lab 3
Securing XML Message Content
In this lab, youll be adding a few new processing rules to your multi-protocol gateways processing policy to demonstrate some of DataPowers security features. Upon completing this lab, youll have a better understanding of:

Private keys and public certs. How DataPower handles digital keys and certificates. DataPower support for WS-Security digital signatures, encryption, and decryption. Field-level encryption. DataPowers extensive authentication and authorization framework. Connecting to an LDAP server. Configuring SSL.
3.1
Public Key Infrastructure (PKI)
In the digital world, public and private keys are often employed to perform cryptographic operations, such as encryption of message data. The use of key pairs (public/private) is known as asymmetric encryption. It is vital that the private key is protected, while its public counterpart, the public key (often carried in a certificate), can be freely distributed. Certificates are typically validated by a Certificate Authority (CA). In the event that an authority needs to revoke a previously distributed certificate, it adds the revoked certificate to a globally published certificate revocation list (CRL). In DataPower, public certificates and private keys are wrapped in crypto objects so that there is one level of indirection when using them. For example, when you upload a public certificate, it will be wrapped in a Crypto Certificate object. When a DataPower object needs to use that public certificate, it will reference it using the crypto certificate instead of the actual certificate. The following image shows a signing action that references a crypto key and crypto cert when digitally signing a message.
Crypto Key
Crypto Certificate
Private Key
Public Certificate
This single level of indirection allows the underlying key or certificate to be replaced without the need to reconfigure any services that are using it.
Page 55
IBM Software
In this lab, youll be configuring your service to sign, verify, encrypt, and decrypt. These actions rely on public certificates and private keys; therefore youll need to upload the ones that have been provided for you on your workstation.
Upload the Private Key and Public Certificate

In the following steps, youll upload a public certificate and private key from your workstation to the encrypted cert: directory on DataPower. Later, youll create a crypto cert and crypto key that will reference these files. __1. __2. If the control panel is not visible, click on the Control Panel link at the top of the left navigation pane. Click on the File Management icon in the bottom row of icons.
__3. __4. __5. __6. __7. __8. __9. __10. __11. __12. __13.
Click the Actions link associated with the cert: directory. Click the Upload Files link in the pop-up Directory Actions menu. In the File Management window, click the Browse button. Navigate to the labs/lab3 directory; select DataPower-privkey.pem, then click the Open button. Click the Add button on the right side of the file list box to add this file to the upload queue. Click the Browse button. Select DataPower-sscert.pem, then click the Open button. Click the Add button to add this file to the upload queue. Click the Upload button to upload both files to the cert: directory. Click the Continue button to dismiss the confirmation window. Click on the plus (+) sign next to the cert: folder to verify both files are uploaded.
Page 56
IBM Software
3.2
WS-Security Digital Signatures
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 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. For example, assume a business partner wants to send you a digitally signed message. First, they will compute a special checksum on the message they want to send (this is often referred to as a message digest). Then they encrypt the digest with their private key. The result is a digital signature for the message. They send this digital signature along with the original message to you. When you receive the message, youll first compute a message digest on the received message. Youll then use the business partners public key to decrypt the message digest that was sent along with the message. If the message digest that you calculated and the one that you decrypted are identical, then you can be certain that the data wasnt changed in transit (integrity) and that the data was signed by the business partner (authentication). Creating and verifying digital signatures involve a considerable amount of mathematical computations, and are thus very processor intensive. DataPower employs cryptographic hardware to do these calculations, thus freeing up costly processor cycles for business-related tasks.
3.2.1
__14. __15. __16. __17. __18.
Adding a Digital Signature to a Message

Click the Control Panel link to redisplay the control panel. Click on the Multi-Protocol Gateway icon. Click on the MyService link to open the configuration editor for your service. Click on the ellipsis () in the Multi-Protocol Gateway Policy field to open the policy editor. Drag a Sign action onto the processing rule to the right of the transform action.
Page 57
IBM Software
__19. __20.
Double click the yellow outlined sign action to complete its configuration. In the Configure Sign Action window, click on the plus (+) button next to the Key dropdown list.
Now you will create the Crypto Key wrapper object for the private key you uploaded earlier in this lab. __21. __22. __23. For the Name, type: DataPowerCryptoKey In the File Name dropdown box, select: DataPower-privkey.pem Click the Apply button to create the Crypto Key object.
Now create the Crypto Certificate wrapper object for the public certificate you uploaded earlier in this lab. __24. __25. __26. __27. __28. __29. __30. __31. Click the plus (+) button next to the Certificate dropdown list. For the Name, type: DataPowerCryptoCert In the File Name dropdown box, select: DataPower-sscert.pem Click the Apply button to create the Crypto Certificate object. Click the Done button to complete the sign action configuration. Click the Apply Policy button to make your changes to the policy effective. Click the Close Window link to close the policy editor. In the main browser window, click the Apply button to apply all the changes to the multi-protocol gateway.
You can now test the policy by posting a message like you did in the previous lab. This time, you should see a digital signature on the response. __32. __33. At the command prompt, use the CD command to change directory to c:\labs\lab3 In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post soapMsg.xml http://datapower:444nn/xml The response message displayed in the command window is now considerably bigger than it was before because it now contains a WS-Security compliant digital signature.
Page 58
IBM Software
3.2.2
Verifying a Digital Signature
The process of securely verifying a digital signature requires that the recipient of the message have access to the signers public certificate. The certificate is often included in the signed message, but the most reliable way of verifying the signature is with a certificate received from the signer and uploaded to DataPowers cert: directory.
3.2.3
Crypto Validation Credential
Earlier, you created a crypto certificate object which wrapped a single PKI certificate. Consider Crypto Validation Credential the case where you need to create a processing rule that will verify a digital signature, but the signer may be one of many different business Crypto Certificate Public Certificate partners. Creating separate processing rules for each partner would be cumbersome and subject Crypto Certificate Public Certificate to constant modification when partners were added or dropped. DataPower provides the crypto validation credential object which has the ability to group many crypto certificates together Crypto Certificate Public Certificate into a single object. With a crypto validation credential (often referred to as a valcred), you can create a single processing rule with a single signature verification action that will accommodate countless public certificates. Certificates can be added and removed from the validation credential independent of any verification actions that use it.
Creating a Crypto Validation Credential

__34. __35. __36. __37. __38. __39. __40. __41. If the control panel is not visible, click the Control Panel link to redisplay it. In the last row of icons, locate and click the Keys & Certs Management icon. In the Signature Verification section, click on the Validation Credentials link. Click the Add button to create a new validation credential object. In the name field, type: MyValcred In the Certificates field, dropdown the certificate list and choose: DataPowerCryptoCert Click the Add button to add the certificate to the list of certificates. Click Apply to save the new validation credential object.
Youre ready to add a new rule to your multi-protocol gateway service that will verify a digital signature. To mix things up a bit, youll use the left navigation pane to edit your service instead of the main control panel.
Page 59
IBM Software
__42.
In the left hand navigation pane, click on the Services menu (if the Status menu is still open, you may have to collapse it by clicking on it).
__43. __44. __45. __46. __47.
Locate the Multi-Protocol Gateway section and click: Edit Multi-Protocol Gateway. Click on the MyService link to open up the configuration for MyService. As youve done before, open the policy editor window by clicking on the ellipsis in the MultiProtocol Gateway Policy field. Click the New Rule button to create a rule that will be responsible for verifying digital signatures. In the Rule Name field, type the name: VerifyRule
This time, youll create a XPath match rule that will match positive if the message body contains a digital signature. __48. __49. __50. __51. __52. __53. __54. Double click the yellow outlined match action. In the Matching Rule field, click the plus (+) sign to create a new matching rule. In the Name field, type: MatchSignature Click the Matching Rule tab at the top of the form. Click the Add button to create a new match expression. For the Matching Type, select: XPath In the XPath Expression field, type: //*[local-name()='Signature']
Important! XPath is case sensitive. Make sure you type the XPath expression exactly as it is shown.
__55. __56. __57.
Click the Apply button to save the match expression. Click the Apply button to save the match rule. Click Done in the Configure a Match Action form.
Page 60
IBM Software
__58.
Drag a Verify action onto the processing rule after the match action.
__59. __60. __61.
Double click the yellow outlined verify action to complete its configuration. In the Validation Credential field's dropdown list, select: MyValcred. Click Done.
Now you'll add another transform action that will strip off the digital signature. DataPower comes with a library of pre-built stylesheets that perform various useful tasks such as stripping a digital signature. __62. In the policy editor, drag a transform action after the verify action.
__63. __64. __65.
Double click the yellow outlined transform action to complete its configuration. In the Processing Control File field, select store:/// in the upper dropdown box, and strip-wssec-signature.xsl in the lower dropdown box. Click the Done button.
Important! Remember that rules are evaluated from top to bottom. The rule you just created is at the bottom of the rule list below EchoRule which will ALWAYS evaluate to true
Page 61
IBM Software
__66.
Using the arrows to the left of EchoRule, move it down so that it is at the bottom of the list.
__67. __68. __69.
Click the Apply Policy button to apply these changes to the running configuration. Click the Close Window link to dismiss the policy editor. Click the Apply button to apply all the changes to the multi-protocol gateway.
It may be worth reviewing the three match rules in the policy:

DemoRule will match on any URL that ends with /xml VerifyRule ignores the URL but uses XPath to look into the message for a <signature> element. EchoRule matches any URL pattern.
Before you can verify a digital signature, you have to have a signed message. To create a signed message, post a message to your multi-protocol gateway service like you did in the previous steps, and save the output to a file. __70. In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post soapMsg.xml http://datapower:444nn/xml > signed.xml __71. __72. You can copy the message to the console to verify it has a digital signature. Type the following command: type signed.xml Now post the signed message to your service. This time, don't put the /xml at the end of the URL (if you do, then DemoRule will match and VerifyRule won't get called). post signed.xml http://datapower:444nn The output should contain the original message without the signature. You might notice that there is still some WS-Security information remaining in the header. DataPower removed the digital signature, but left the WS-Security header intact in the event that it may still be needed. There's another stylesheet in the store: directory named strip-security-header.xsl which will remove the ws-security header. If you have time at the end of this lab, you can add another transform to the policy to remove the ws-security header. Now you can test the negative. Edit signed.xml and change the product name from XI50 to XI51 (or anything you like). You can use Notepad or the edit command. Post the modified signed message again. You should receive a SOAP fault that says "Hash values do not match (from client)".
Page 62
IBM Software
Did you get a SOAP fault complaining about the Timestamp? The default expiration for a digital signature is 5 minutes. If 5 minutes has passed since you the time you created the signed message, you'll have to create a new signed message.
3.3
WS-Security Encryption & Decryption
Similarly to digital signatures, encryption use PKI keys and certificates for encryption and decryption. When encrypting a message, the recipient's public key is used; only the private key can decrypt the message.
3.3.1
__73. __74.
Encrypting the SOAP body

In the Configure Multi-Protocol Gateway form, click the ellipsis () in the Multi-Protocol Gateway Policy field to open the policy editor. Drag an Encrypt action to the right of the sign action.
__75. __76. __77. __78. __79.
Double click the encrypt action to complete its configuration. In the Configure Encrypt Action form, locate the Recipient Certificate field, then select DataPowerCryptoCert. Click the Done button. Click the Apply Policy button in the policy editor. In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post soapMsg.xml http://datapower:444nn/xml
Look closely at the output in the window. You should notice that the body of the SOAP message is encrypted. Now you'll add a decrypt action to the policy.
Page 63
IBM Software
__80. __81.
Back in the policy editor, in the Configured Rules section, click on the VerifyRule to make it the active rule in the editor. Drag a Decrypt action in front of the verify signature action. Since the original message is signed then encrypted, you need to perform the decrypt then verify (otherwise the verify step will fail).
__82. __83. __84. __85. __86. __87.
Double click the yellow outlined decrypt action. In the Decrypt Key field, select: DataPowerCryptoKey. (Notice that this is the key and not the cert). Click the Done button. Click the Apply Policy button. Click the Close Window link to close the policy editor. Click the Apply button in the main configuration page to apply all the changes to the service.
3.3.2
The Transaction Probe
So far, the processing rules that you've created have been relatively simple, but even with simple rules, sometimes you don't get the results you expect. The transaction 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. __88. __89. __90. __91. In the Configure Multi-Protocol Gateway form, towards the upper right corner, click on the Show Probe link. In the probe window, click on the Enable Probe button. Click the Close button in the completion dialog. Post the SOAP message to your service again, and save the output in another file. In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post soapMsg.xml http://datapower:444nn/xml > enc.xml
Page 64
IBM Software
__92. __93.
If you like, you can use the type command to view the file to see that it has been digitally signed and encrypted. Now post the new signed and encrypted file. The results should be the original SOAP message, unencrypted without the digital signature. post enc.xml http://datapower:444nn
__94.
Look back at the probe window; click the Refresh button. You should see two transactions in the list.
The transaction list shows the two transactions you just posted and which rule was executed (based on the match rules). You can see that the first transaction properly processed by DemoRule, and the second transaction was processed by VerifyRule. __95. Click on the magnifying glass on the first transaction.
In the top section of the window, there's an icon representing each of the actions in the processing rule you created. In front of each action icon is a magnifying glass. Clicking on the magnifying glass will reveal what the input to that action was. When the leftmost magnifying glass is selected, the original inbound XML document is shown. __96. Click on the magnifying glass in front of the transform action.
The XML document shown in the window shows what will be fed into the transform action as the context document. Notice that the <encoded-description> tag still exists and contains base-64 encoded data. __97. Click on the magnifying glass after the transform action (in front of the sign action).
This shows the results of the transform action and what is going to be fed into the sign action. Notice now that the <encoded-description> element has been replaced with a <description> element and that the text is no longer base-64 encoded. The <benefits> element has also been tokenized into a smaller XML tree.
Page 65
IBM Software
__98.
Click on the magnifying glass after the sign action.
Now the window shows a document that contains the digital signature. If you scroll the window down, you will notice that the SOAP body is still in clear text. __99. Click on the magnifying glass after the encrypt action.
Now the entire body of the SOAP message has been encrypted. __100. Close the transaction window. __101. Close the probe window. __102. If your configuration is working properly, click the Save Config link in the top navigation bar.
3.3.3
Field Level Encryption
In the previous steps, you saw how DataPower can encrypt the entire SOAP body. In some circumstances, it may be preferable to encrypt only specific elements. DataPower supports various encryption methods, including field-level encryption. Now youll modify the encrypt action so that only the <brand> tag will be encrypted. __103. Re-open the policy editor by clicking on the ellipsis button in the Multi-Protocol Gateway Policy field. __104. In the policy rule, double click the encrypt action to open its configuration settings.
__105. In the Message Type section, choose Selected Elements. When you make this selection, a new field, Document Crypto Map will appear. The Document Crypto Map is used to tell the encryption action which element(s) are to be encrypted. Since the document will be in XML, the most natural way of selecting the target elements is with XPath expressions. The Document Crypto Map represents a collection of XPath expressions which identify the elements to be encrypted.
Page 66
IBM Software
__106. Click the plus (+) button next to the Document Crypto Map dropdown. __107. For the Name field, type: MyCryptoMap __108. For the Operation, make sure Encrypt (WS-Security) is selected. __109. In the XPath Expression field, type //brand and then click the Add button to add this XPath to the list of expressions. __110. Click the Apply button. __111. Click the Done button in the Configure Sign Action window. __112. Click the Apply Policy button in the policy editor. __113. Click the Close Window link to close the policy editor. __114. Click the Apply button in the main configuration form. __115. In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post soapMsg.xml http://datapower:444nn/xml Notice in the output that the SOAP body is no longer encrypted, however the <brand> element is now encrypted.
If youre having a hard time reading the output from the command line, you can use the probe to view the formatted XML.
Page 67
IBM Software
3.4
DataPower Access Control Framework
Up until now, youve seen how DataPower can protect XML web traffic using built-in XML threat protection, digital signatures, and encryption. This section will introduce DataPowers access control framework which provides authentication, authorization, and audit services. Collectively, this is referred to as AAA. An AAA (Authentication, Authorization, Audit) 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.
Extract Identity & Extract Resource

The first action that occurs is to extract the claimed identity of the service requester and the requested resource from an incoming message and its protocol envelope. DataPower provides an extensive list of predefined identity and resource extraction methods. For example, the 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.
Authenticate
If the identity and resource are successfully extracted from the message, DataPower will attempt to authenticate the request. Authentication is most commonly accomplished via an external service such as Tivoli Access Manager or LDAP. If the authentication is successful, the process enters the resource and credential mapping phase.
Page 68
IBM Software
Credentials and Resource Mapping

Successful server-based authentication generates a set of credentials attesting to the service requesters identity. These credentials can then be mapped into another set more appropriate for the authorization method selected. In addition, the extracted resource name can also be optionally mapped to something more appropriate for the authorization method selected. 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.
Authorize
Like authentication, authorization is most commonly accomplished via an external policy server such as Tivoli Access Manager or an LDAP. The results of the authorization phase is to either allow or deny the request to proceed. 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.
Audit & Accounting

The final phase of the AAA policy optionally performs auditing and security mediation tasks such as converting between WS-Security UsernameToken element and Kerberos/SPNEGO. This phase has the ability to generate various types of security tokens, including Kerberos/SPNEGO, LTPA, and SAML a assertion. A stylesheet can also be identified for execution to do any custom auditing tasks.
3.5
LDAP Authentication
In this section, youll add an AAA action to your processing rule to authenticate requests against an LDAP. __116. Re-open the policy editor by clicking on the ellipsis button in the Multi-Protocol Gateway Policy field. __117. Drag an AAA action and drop it after the initial match action.
Page 69
IBM Software
__118. Double click the yellow outlined AAA action to configure it. __119. The AAA processing action references an AAA Policy. You need to create a new AAA Policy. Click the plus (+) sign next to the AAA Policy dropdown to start the AAA Policy wizard. __120. For the AAA Policy Name, type: MyAaaPolicy __121. Click the Create button. The next page identifies how to extract the users identity (and optionally password) from the message. The SOAP message that weve been experimenting with contains the user identity and password in a WS-Security UsernameToken element. __122. Select: Password-carrying UsernameToken Element from WS-Security Header.
__123. Click the Next button. Now youll identify how to authenticate the user. __124. Select: Bind to Specified LDAP Server. When you make the selection, LDAP specific configuration parameters will be displayed. __125. In the Host field, type: demoserver __126. Change the LDAP version to: v3 __127. In the LDAP Suffix field, type: ou=members,ou=datapower,dc=ibmdemo,dc=com __128. Click the Next button. Now you will define how to extract the resource. Since the message is a SOAP request, you can expect that the first element in the SOAP body contains the operation being requested. This is known as the Local Name of the Request Element. __129. In the Extract Resource form, check: Local Name of Request Element __130. Click the Next button. __131. For the authorization phase, leave the default set to: Allow Any Authenticated Client. __132. Click the Next button.
Page 70
IBM Software
The last page of the AAA policy configuration wizard gives you the options of performing various post processing tasks. One powerful post-processing task is to perform security protocol mediation such as creating a Kerberos/SPNEGO token or generating a signed SAML assertion. For this lab, just leave everything with the default values. __133. Click the Commit button to save the new AAA policy. __134. Click the Done button to dismiss the success window. __135. Make sure MyAaaPolicy is selected in the AAA Policy field, and then click the Done button. __136. In the policy editor, click the Apply Policy button. __137. Click the Close Window link to close the policy editor. __138. Click the Apply button in the main configuration form. __139. In the command window, type the following command, replacing the NN with your student number. Make sure to include the /xml path in the URI. post soapMsg.xml http://datapower:444nn/xml If the authentication succeeded, you should receive a lot of output (it includes a digital signature and encryption). __140. Now post a message that contains an incorrect password. post soapBadPwd.xml http://datapower:444nn/xml This time you should receive a SOAP fault indicating rejected by policy.
3.6
Securing with SSL
The final steps in this section will be to show how you can easily secure your multi-protocol gateway service using mutual (two-way) SSL. The basic process involves adding an HTTPS Front Side Handler to your multi-protocol gateway. The primary difference between an HTTP and HTTPS front side handlers is that the HTTPS FSH requires an SSL Proxy Profile object.
Page 71
IBM Software
The preceding image shows the relationships of various DataPower crypto objects that work together to provide mutual SSL services. The Crypto Identification Credential object is used when providing an identity to connecting clients. When a client connects, it requests a certificate from DataPower. The crypto ID credential references which certificate should identify DataPower. It also references a private key which is used by SSL in later steps. Earlier, you created a crypto validation credential for use when verifying a digital signature. When a crypto validation credential is used for mutual (two-way) SSL communication, it contains any certificates that DataPower will accept from clients. In other words, if during the SSL handshake, the client provides a certificate that is not found in the crypto valcred, the SSL handshake will fail. If a crypto valcred is omitted from the configuration, SSL will be one-way (identifying DataPower only). The Crypto Profile object ties together a Crypto ID credential and a Crypto Validation credential. The SSL Proxy Profile provides some protocol-specific options and references a crypto profile. The SSL Proxy Profile thus contains every bit of information needed to establish one or two-way SSL handshaking. This may seem like a lot of pieces to configure, but keep in mind that a single DataPower appliance can host multiple services and may need to have multiple identities. This object relationship provides the maximum flexibility and object re-use.
3.6.1
Create the Crypto Identification Credential
__141. In the left navigation pane, under the Objects menu, in the Crypto Configuration section, click on the Crypto Identification Credentials. __142. Click the Add button. __143. In the Name field, type: MyIdCred __144. In the Crypto Key dropdown, select: DataPowerCryptoKey
Page 72
IBM Software
__145. In the Certificate dropdown, select: DataPowerCryptoCert __146. Click the Apply button to create the Crypto Identification Credentials.
3.6.2
Update the Crypto Validation Credentials
When a client connects to DataPower using mutual SSL, the client will be required to provide a certificate during SSL handshaking. If that certificate (or its root certificate) does not exist in the crypto validation credential, handshaking will fail. In this step, youll upload another certificate into DataPower which represents the partner who will be connecting to your service. __147. In the same section in the navigation pane, click on Crypto Validation Credentials. __148. Click on MyValcred. __149. Click the plus (+) button in the Certificates field to add another certificate to the list. __150. In the Name field, type: PartnerCert __151. In the File Name field, click on the Upload button. __152. In the Upload window, click the Browse button. In the lab3 directory, select: partner-sscert.pem __153. Click the Upload button; then click the Continue button. __154. Click the Apply button to save the new Crypto Certificate. When you return to the validation credential configuration page, youll see that the new PartnerCert has been added to the list of certificates. __155. Click the Apply button in the Configure Crypto Validation Credentials form.
3.6.3
Create the Crypto Profile
The crypto profile object will now tie together the crypto identification credential and the crypto validation credential to form a relationship between the two. __156. In the same Crypto Configuration section of the navigation pane, locate and click Crypto Profile. __157. Click the Add button. __158. In the Name field, type: MyCryptoProfile __159. In the ID Credentials dropdown, select: MyIdCred __160. In the Validation Credentials dropdown, select: MyValcred __161. Click the Apply button to save the Crypto Profile.
3.6.4
Create the SSL Proxy Profile
The proxy profile object provides the SSL-specific configuration parameters, and references the crypto profile for any required crypto keys and certificates.
Securing XML Message Content Page 73
IBM Software
__162. In the same Crypto Configuration section of the navigation pane, locate and click SSL Proxy Profile. __163. Click the Add button. __164. In the Name field, type: MySslProxyProfile __165. In the Reverse (Server) Crypto Profile dropdown, select: MyCryptoProfile __166. Click the Apply button to save the new SSL Proxy Profile. __167. Click the Control Panel link to redisplay the control panel.
3.6.5
Create an HTTPS Front Side Handler
The final steps are to create the HTTPS front side protocol handler and add it to the multi-protocol gateway service. The HTTPS front side handler will identify which SSL Proxy Profile to use as well as a TCP port for communications. __168. Click the Multi-Protocol Gateway icon. __169. Click MyService to open the configuration for your multi-protocol gateway service. __170. In the Front Side Protocol field, click the plus (+) button to create a new front side protocol handler. __171. From the pop-up menu, select HTTPS (SSL) Front Side Handler __172. In the Name field, type: MyHttpsFSH __173. In the Port field, type: 443nn where nn is your student number. __174. Towards the bottom of the configuration window, locate the SSL Proxy field and select MySslProxyProfile from the dropdown list. __175. Click the Apply button to save the front side handler configuration. __176. Click the Apply button at the top of the Configure Multi-Protocol Gateway form. The configuration is complete. Now your multi-protocol gateway service is listening on two ports, one being HTTP and the other HTTPS.
Page 74
IBM Software
__177. In the command window, type the following command. Make sure to use the secured port number. post soapMsg.xml http://datapower:443nn/xml This should fail because port 443nn requires an SSL connection. __178. Now try the command again, but this time using the SSL protocol. Notice this time the protocol is https and not http. Also, you will use the sslpost command instead of post. sslpost soapMsg.xml https://datapower:443nn/xml __179. If your configuration is working properly, click the Save Config link in the upper right corner of the window to save your configuration to the flash memory.
3.7
Summary
In this lab, you saw a variety of ways in which DataPower can help secure your XML data from malicious threats, tampering and unauthorized access. You learned:
How DataPower uses crypto certificates and crypto keys to dereference key and certificate files for maximum flexibility and ease of maintainability. DataPower uses the crypto keys and certificates when creating and verifying digital signatures, as well as during encryption and decryption. You can add a digital signature to an XML message simply by dragging a sign action onto the processing rule and identifying which key to use. DataPower can perform field level, as well as message level encryption and decryption without sacrificing performance as a result of hardware encryption technology. The transaction probe is a powerful tool that allows you to visually inspect every aspect of a transaction, helping to identify configuration or communication problems. Access Control Policies, also known as AAA policies, are a powerful and flexible way to prevent unauthorized access to your services. Through the point-and-click WebGUI, you can easily configure access policies to contact external authentication and policy servers. AAA policies can also do security mediation, such as converting between HTTP Basic Authentication and Kerberos/SPNEGO. AAA policies can also create a SAML assertion based on authenticated credentials extracted from the message. SSL leverages several reusable DataPower crypto objects and is easily applied to a service by simply assigning an SSL Proxy Profile to an HTTPS front side handler.
Page 75
IBM Software
Lab 4
Protecting Web Services
With the wide-spread adoption of Web services, it has become essential to not only protect Web services from malicious attacks, but also adhere to standards and specifications (also referred to as WS-*) that help to assure interoperability while maintaining quality of service levels. The continuous evolution of WS-* specifications adds an additional challenge to developers. In this lab, youll learn about the DataPower Web Service Proxy, a service object designed specifically to provide Web services with a centralized location for:

Protection against malicious threats. Web service definitions (WSDL). Request authentication and authorization. Enforcement and compliance of WS-* specifications. Virtualization of service endpoints. Application of processing rules and policies. Application of WS-Security such as encryption and digital signatures. Enforcement of service level agreements and quality of service. Web service governance.
4.1
Web Services and WSDLs
A Web service is defined as a self-describing, standalone application that can be consumed by other applications. Web services use Web Services Description Language (WSDL) to provide the consumer with the essential details associated with its usage. A WSDL document is generally available to the consumer, and is used when developing clients that use the service. DataPowers Web Service Proxy (WS Proxy) object fully understands Web Services Description Language. In fact, a fully functional WS Proxy can be configured simply by providing it with a WSDL document. Once configured, additional processing requirements and quality of service parameters can be easily configured using the WebGUI.
4.1.1
WSRR and UDDI Integration
The central element to the configuration of a WS Proxy service is one or more WSDLs. There are several ways of which DataPower can gain access to a services WSDL:

The WSDL document can be uploaded into DataPowers flash-based file system. The WSDL can be referenced via a URL, such as http://myservice.com/service?WSDL The WS Proxy can subscribe to a centralized repository such as WebSphere Service Registry and Repository (WSRR) or a Universal Description Discovery and Integration (UDDI) server.
Using a WSDL repository such as WSRR or UDDI has some distinct advantages. When using a repository, the WS Proxy service subscribes to a WSDL and periodically checks for service definition or policy updates. When a new WSDL becomes available, the WS Proxy will obtain it and automatically reconfigure itself based on the new WSDL.
Protecting Web Services Page 77
IBM Software
4.2
About the Web Service
For this lab, youll be protecting a Web service that provides flight calculations similar to an E6B Flight Computer. An E6B is a form of circular slide rule used in aviation. E6Bs are mostly used in flight training, but many pilots still carry them. Theyre used to aid in calculating fuel burn, wind correction, time en route, and other flight-related values. In the air, the flight computer can be used to calculate ground speed as well. The back side is designed for wind correction calculations (determining how much the wind is affecting one's speed and course). There are three operations in the Web service:
CalculateFlightLeg given a set of input parameters, this operation will calculate elapsed time, fuel required, ground speed and true heading. CalculateHeadCrossWind given the wind direction, wind speed, and take-off runway number, this operation will calculate the headwind and crosswind strengths at take-off. CalculateCloudBase given the temperature and dew point, this operation will calculate the altitude of the base of cumulus clouds.
4.3
Setting up your Workstation
For the steps in this lab, youll use a freely downloadable tool called soapUI. Before getting started with this lab, make sure that soapUI is installed on your workstation. If soapUI is not installed on your workstation, you can access the installation files from demoserver. Open a browser window and navigate to http://demoserver. Click on the soapUI link. Once the installer launches, take all of the defaults. Start soapUI with the following steps: __1. __2. Double click the soapUI icon on your desktop to launch soapUI. If there are no projects showing in the Projects tree, follow these steps to open the predefined project. __a. Select: File Import Project __b. In the file browser, navigate to: labs/lab4 and select DataPower_PoT.xml; then click the Open button.
Page 78
IBM Software
__3.
If the soapUI starter page is showing, click the close box to dismiss it.
__4.
Select File Preferences and verify the following settings: __a. In the HTTP tab, make sure HTTP version 1.1 is selected. __b. In the UI Settings tab, uncheck: Show Startup Page. __c. Click OK to close the preferences dialog.
4.4
Verify the Service is Available
Before creating the DataPower configurations to protect the service, you can test the service to make sure its up and running. First, youll request the services WSDL from the actual service (not DataPower). __5. Open a new browser window and enter the following URL: http://demoserver:9080/E6BService/E6BService?WSDL You should see the WSDL similar to the following image.
Page 79
IBM Software
If the service returned its WSDL, you know the service is up and running. Now you can submit a SOAP request to test the service. __6. __7. __8. __9. If the DataPower_PoT project is not expanded, click the plus sign to its left to show the E6BServiceSOAP item. Expand the E6BServiceSOAP item by clicking the small plus sign to its left. This will reveal the various operations in the service. Expand the CalculateCloudBase item to reveal Request 1. Double click Request 1 to create a new SOAP request. After the window opens, you might want to click the maximize button to maximize the request window (see following image). .
__10.
Verify that the endpoint shown in the dropdown list shows a host name of demoserver. If it doesnt, dropdown the list and edit the endpoint address so that it reads: http://demoserver:9080/E6BService/E6BService Make sure that the <temperature> and <dewpoint> elements contain integer values. They should default to temperature 80 and dew point 40. Click the green submit button at the top of the request view to send the request to demoserver.
__11. __12.
__13.
If everything is working properly, the response window should expand itself and reveal the SOAP response that came back from the web service. If you submitted 80 and 40 for temperature and dew point, the service should respond with a cloud base altitude of 9090 feet.
If you did not receive a response, or you receive a SOAP fault, ask the instructor for additional help in troubleshooting your server connectivity.
Page 80
IBM Software
4.5
Defining the WebSphere Service Registry and Repository Server
For this Proof of Technology, the instructors workstation (demoserver) has a running instance of WebSphere Service Registry and Repository. The WSDL for the E6B service has been uploaded and published into the registry. When you create your Web Service Proxy object on DataPower, youll configure it to obtain the WSDL from the registry. Therefore, youll first need to configure DataPower to communicate with the Registry. Youll do that in the following steps. __14. __15. __16. __17. __18. In the left navigation menu, expand the Objects menu, then scroll almost to the bottom and locate the Configuration Management section. Click on WSRR Server. Click the Add button to create a new WebSphere Service Registry and Repository server connection. For the Name field, type: MyWsrrServer In the SOAP URL field, make the following changes. __a. Change https to: http (make sure to remove the s). __b. Change host to: demoserver __c. Change the port number to: 9080 The final URL should be: http://demoserver:9080/WSRRCoreSDO/services/WSRRCoreSDOPort __19. __20. __21. In the WSRR Server Version, select: 6.1 or later Click the Apply button to create the server connection object. Verify that the Op-State shows: up.
4.6
Creating the Web Service Proxy
The first step in create a Web Service Proxy object is to give it a WSDL. For this lab, the WSDL will be obtained from a registry (WebSphere Service Registry and Repository). In the following steps, youll create a subscription to WebSphere Service Registry and Repository to obtain the E6B Service WSDL. __22. __23. __24. __25. __26. __27. Click on the Control Panel link to display the DataPower control panel. Click on the Web Service Proxy icon. It is located on the top row of service icons. Click the Add button to create a new Web Service Proxy object. In the Web Service Proxy Name field, type: E6BServiceProxy Click the Create Web Service Proxy button. In the Web Service Proxy WSDLs section, click the radio button for: Add WSRR Subscription
Page 81
IBM Software
__28. __29. __30. __31.
In the WSRR Subscription Name field, type E6BServiceSubscription in the New field. Leave the Subscription Object field as: WSDL Document In the Object Name field, type: E6BService.wsdl In the Namespace field, type: http://www.ibm.com/datapower/E6BService/
Important! The Namespace is case sensitive and must be identical as shown above. Dont forget the trailing slash at the end.
__32. __33. __34.
In the WSRR Server dropdown, select: MyWsrrServer Leave the Fetch Policy Attachments field to: on At the bottom of the form, click the Next button.
4.6.1
Defining Local Connection Details
Now youll define how clients will connect to the Web Service Proxy. Youll do this the same way you did in previous labs when you created an HTTP front side handler (FSH). __35. In the Local settings box, click the plus (+) button in the Local Endpoint Handler column to create a new front side handler.
__36. __37. __38. __39.
In the pop-up list of protocol types, select: HTTP Front Side Handler In the Name field, type: E6BSvcFSH In the Port Number field, type: 445NN where NN is your student number. In the Allowed Methods and Versions section, click the checkbox to enable: GET method By default, DataPower doesnt allow HTTP GET operations against Web services since Web services involve POSTing SOAP requests. However, in a subsequent step, youll submit a GET to the service in order to see its WSDL, therefore you need to enable the HTTP GET verb. Click the Apply button to create this HTTP FSH.
__40.
The 2nd column labeled URI is used to specify what the inbound URI should be for the service. By default, this is taken from the WSDL; however you can also override the URI with a totally different URI for client
Page 82
IBM Software
requests, thus hiding the actual service URI. The 3rd column also indicates that all bindings should be taken from the retrieved WSDL. __41. Click the Add button to add these definitions to the Web Service Proxy.
4.6.2
Defining the Remote Server Details
The final step is to define details associated with the actual backend service. By default, DataPower will derive all of the details from the retrieved WSDL; however, you do have complete flexibility to override the backend hostname, port, and remote URI if necessary.
__42.
Click the Next button.
Your service is now created and ready to use. First, verify that everything is up and that the WSDL was successfully retrieved. __43. Towards the middle of the page, verify that the WSDL Status section shows: Okay
Page 83
IBM Software
__44.
At the top right section of the page, click on the View Operations link to show the details pertaining to the service operations.
A window will open showing you details about the three operations available in the E6BService. __45. Click the close button to close the pop-up window.
4.6.3
__46. __47. __48.
Turn on the Transaction Probe

At the top right section of the page, click on the Show Probe link to open the probe window. Click the Enable Probe button to turn on the probe. Click the Close button to dismiss the success window.
4.6.4
Execute the Service from soapUI
Before you submit another transaction, youll need to change and edit the endpoint that points to datapower instead of demoserver. __49. In the soapUI window, click the endpoint dropdown list and select the datapower:445 URL to make it the current endpoint.
__50. __51.
Once the datapower URL is selected, dropdown the list again and select [edit current..] In the edit box, replace the nn in the port number with your student number; then click OK. Make sure that the URL in the endpoint dropdown shows the proper port.
Page 84
IBM Software
__52.
Click the green submit button to submit the request to DataPower. DataPower will receive the request, perform XML security checks on the message (schema validation, XML threats, etc.), then forward the message to the actual demoserver service.
You should see a response in the soapUI response pane. __53. In the Transaction Probe window, click the Refresh button.
If the transaction was successful, it should appear in the probe similar to the following image:
__54.
Click on the small plus sign next to the magnifying glass to show both the request and the response. Click the magnifying glass to see the contents of the request and response. You learned how to use the transaction probe in a previous lab, so feel free to investigate the different details, headers, etc, about the request and response.
__55.
Close any open browser windows except the main DataPower WebGUI.
4.7
WS-Policy Support
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 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. For example, WS-Policy can dictate that all responses are digitally signed or encrypted.
4.7.1
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. This is referred to as an embedded policy. There may be times when the WSDL cannot be modified, or a single policy should be applied to many services (or operations within a service). In this situation, a separate WS-Policy document can be attached to an existing WSDL.
Page 85
IBM Software
4.7.2
Enforce vs. Filter
There are two ways in which DataPower can enforce policies:
Enforce mode DataPower will enforce the policy, and if the policy requirements arent satisfied, DataPower will attempt to satisfy them. If the policy requirements cannot be satisfied, the message will be rejected.
For requests, DataPower requires that all policy requirements are met; it will not attempt to satisfy them. For example, if the policy states that inbound messages must contain a WS-Security UsernameToken element, and the request does not contain it, the request will be rejected. For responses, DataPower will attempt to satisfy the requirements if the backend server did not. For example, if the policy states that all outbound responses must be digitally signed, but the server returned a response that is not signed, DataPower will attempt to sign the response.
Filter mode DataPower will enforce the policy, and if the policy requirements arent satisfied, DataPower will reject the message.
Requests and responses are handled the same. If the request or the response does not meet the policy requirements, the entire transaction will be rejected.
Earlier in this lab, you configured DataPower to obtain the E6BService WSDL from the service registry (WebSphere Service Registry and Repository). A WS-Policy attachment has also been uploaded into WebSphere Service Registry and Repository and attached to the E6BService WSDL. By fetching the WSDL from DataPower, you can actually see the attached policy. __56. Open a new browser window and navigate to the following URL: http://datapower:445nn/E6BService/E6BService?WSDL The services WSDL should be displayed in the browser window. The WSDL is being returned to the browser from DataPower (not demoserver). DataPower fetched the WSDL and Policy and combined them together. The policy is found towards the bottom of the WSDL.
Page 86
IBM Software
4.7.3
UsernameToken Policy
The CalculateHeadCrossWinds request operation has a policy attached to it. The policy requires that all input messages contain either a version 1.0 or a version 1.1 UsernameToken element in the WS-Security header. The policy looks like this:
Testing Policy Enforcement UsernameToken

__57. In the soapUI window, expand the CalculateHeadCrossWind operation.
__58.
Double click Req_UsernameToken to show the SOAP request for this operation.
Page 87
IBM Software
__59.
Make sure the request has valid parameters. In the example below, WindSpeed is 15, WindDirection is 45, and RunwayNumber is 1. Also, assure that the endpoint selected is still http://datapower:445nn/E6BService/E6BService
__60.
Click the green submit arrow to submit the request to DataPower. The request should FAIL because it does not have a WS-Security UsernameToken as required by the policy. The fault string should read: Required elements filter setting reject: expression ... was not satisfied (from client)
Adding the WS-Security UsernameToken to the Request

SoapUI has the ability to add a WS-Security UsernameToken to the request, thus satisfying the policy requirements. However, youll still need to make a few additional configuration changes to make everything work properly.
Adding the UsernameToken to the request only satisfies the policy requirements; it doesnt actually authenticate the user. To make it effective, youll add the previously created AAA policy to the WS-Proxy object so that it will authenticate the user credentials found in the UsernameToken. The backend service is not expecting a UsernameToken and will thus complain about it. Youll add a transform step that will strip the UserName token from the request before forwarding it to the backend service.
4.7.4
__61.
Adding Authentication for CalculateHeadCrossWind

In the WS-Proxy configuration page, click on the Policy tab.
Page 88
IBM Software
The Policy page allows you to define custom rules that are applied at various levels in the service. For example, you can create a rule that will be specific just for one operation in the WSDL. Rules are created exactly the same was as you did in the previous labs. __62. In the Web Service Proxy Policy section, click on: Open tree to Operations. This will show all of the operations in the service.
__63. __64.
Scroll the policy window down and locate the CalculateHeadCrossWind operation. Click the Add Rule button.
__65.
Specify that this rule should only be executed on inbound requests (client to server). In the Rule Direction dropdown, select: Client to Server
Page 89
IBM Software
__66.
Drag an AAA action after the match rule.
__67. __68. __69.
Double click the yellow outlined AAA action to complete its configuration. In the AAA Policy dropdown, select the previously created AAA policy: MyAaaPolicy Click the Done button to save the configuration.
4.7.5
Removing the WS-Security Header
In the following steps, youll add a transform action that will strip the WS-Security Header so that the backend server wont complain about it. DataPower comes with a library of pre-built XSL stylesheets that perform a variety of common functions. One of the stylesheets will strip the WS-Security header from a message. __70. Drag a transform action onto the rule.
__71. __72.
Double click the yellow outlined transform action to complete the configuration. In the Processing Control File field: __a. In the upper dropdown list, select: store:/// __b. In the lower dropdown list, select: strip-security-header.xsl
Page 90
IBM Software
__73. __74.
Click the Done button. At the top of the page, click the Apply button to make these changes active.
Youre ready to test the service now. SoapUI will add a WS-Security UsernameToken to the request. __75. In SoapUI, locate the Request Properties window (bottom left section). Set the property values as indicated: __a. Username: david __b. Password: foobar __c. WSS-Password Type: PasswordText __76. Click the green submit arrow again. This time, the request should succeed.
4.8
Service Level Monitoring (SLM)
DataPowers service level monitoring facility provides a policy-driven approach to governing web service traffic. At its simplest level, it allows you to configure thresholds that dictate how many transactions should be allowed to flow through a service, as well as what action to take should those thresholds be exceeded. More complex SLM policies can also be defined which have the ability to base activity thresholds on parameters such as client IP, user identity, or user defined message details to name just a few. When a threshold is exceeded, DataPower can be configured to take one of three actions:

Throttle the request will be rejected. Shape the request will be queued until the next timeframe window begins. For example, if the policy says 10 requests per 30 seconds and 11 requests arrive within the first two seconds, the 11th request will be queued until the next 30 second timeframe begins. Then it will be processed and forwarded to the final endpoint. Notify a message will be logged that the threshold was exceeded.
In the following steps, youll configure the CalculateFlightLeg operation to only allow 2 requests per 10 second interval, and throttle any requests that exceed the threshold. __77. In the WS-Proxy configuration page, click on the SLM tab.
__78.
In the Web Service Proxy SLM section, click on: Open tree to Operations. This will show all of the operations in the service.
Page 91
IBM Software
__79.
In the CalculateFlightLeg operation section, specify the following SLM parameters: __a. Request interval: 10 __b. Request limit: 2 __c. Request action: Throttle
__80. __81. __82. __83. __84.
Click the Apply button to save the SLM configuration changes. In the soapUI program window, expand the CalculateFlightLeg operation. Double click Request 1. Make sure that the endpoint shows: http://datapower:445nn/E6BService/E6BService Make sure the parameters are valid. You can use the following if they are not automatically filled in for you:
__85.
Now youll submit several requests to the web service. Click the green submit button several times and notice what the response from the server is. Starting with the 3rd request, you should get a SOAP fault indicating that the request was rejected by policy. Continue to try submitting requests. Eventually, the 10 second time window will elapse and requests will be permitted again.
4.9
Federation using SAML
In this lab, youll add support for federation using Security Assertion Markup Language (SAML). SAML is an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). In the context of Web services, SAML is used primarily for federation. The consumer of a Web service will authenticate a user and create a digitally signed SAML assertion on that users behalf. The digital signature assures that the assertion is not modified on its way to the service provider. At the service provider, the digital signature is verified using a validation credential (which could contain many client certificates). If the signature is valid and the assertion hasnt expired, the request is accepted as authenticated.
Page 92
IBM Software
In this lab, youll create a federated environment that will use an XML Firewall as the client, and the web service proxy that you created in this lab as the service provider. The following diagram illustrates how a request will be processed.
In the preceding illustration, the following sequence of events occur:
The service consumer (soapUI on your workstation) will submit a SOAP request which contains a WS-Security UsernameToken. An XML Firewall acts as the outbound federation point for the consumer. It first authenticates the client by extracting the credentials from the UsernameToken, then authenticates them against an LDAP server. If this succeeds, the AAA policy will generate a signed SAML assertion and forward the message to its intended service endpoint (the WS-Proxy E6BService that you created earlier in this lab). The message is received by the WS-Proxy which looks for the signed SAML assertion. If it does not find it, it rejects the request. If it is found, and the signature is valid, then it will allow the request to pass through to the actual E6BService.
4.9.1
Modify the AAA Policy to add a SAML Authentication Assertion
Previously you created an AAA policy that extracts the user and password from a WS-Security UsernameToken element and authenticates against a remote LDAP server. In the next few steps, youll modify that policy so that if the authentication succeeds, it will add a SAML authentication assertion to the original request. Youll also specify which private key and certificate to use to sign the assertion.
Page 93
IBM Software
This AAA Policy is for the Federated Partner The partner is responsible for authenticating the request before they send it to the consumer. This AAA policy will authenticate the request against an LDAP, create a SAML assertion, sign the assertion, and forward the request to the service provider.
__86. __87.
In the left navigation menu, expand the Objects menu; then locate the XML Processing section and click on the AAA Policy link. Click on MyAaaPolicy to open the configuration form.
In an earlier lab, you uploaded the partners certificate (for use in SSL). Since this AAA policy must sign the SAML assertion with the partners private key, youll now have to upload the private key and create a Crypto Key object. __88. __89. In the SAML Message Signing Key field, click the plus (+) sign to create a new Crypto Key. In the Configure Crypto Key form, use the following values: __a. In the Name field, type: PartnerKey __b. In the File Name field, click the Upload button. __c. Click the Browse button, and browse to the labs/lab4 directory and select: partner-privkey.pem. __d. Click the Upload button. __e. Click Continue to dismiss the confirmation window. __f. In the Configure Crypto Key form, click the Apply button to save the new crypto key. __90. __91. __92. __93. In the SAML Message Signing Certificate dropdown, select: PartnerCert Click the PostProcessing tab at the top of the form. For Generate SAML Authentication Assertion, click: on Click the Apply button.
4.9.2
Create the Web Service Consumer
For this step, youll create an XML Firewall service that will authenticate requests using the same AAA Policy that you created earlier, except youll modify the policy to add a signed SAML authentication assertion to the request. __94. Click on the Control Panel link to show the DataPower Control Panel.
Page 94
IBM Software
__95.
Click on the XML Firewall service icon to start the creation process.
__96. __97.
Click the Add Advanced button. In the Configure XML Firewall form, specify the following details: __a. Firewall Name: MyPartner __b. Server Address: E6BServer __c. Server Port: 445nn (where nn is your student number) __d. Front End Device Port: 555nn (where nn is your student number) __e. Response Type: Pass-Thru
__98.
In the Firewall Policy field, click the plus (+) button to create a new policy.
__99.
In the Policy Editor, specify the Policy Name as: MyPartnerPolicy
__100. Click the New Rule button to create a new rule for this policy. __101. In the Rule Direction dropdown, select: Client to Server __102. Double click the yellow outlined match action to open its configuration page. __103. In the Matching Rule dropdown, select: MatchAnyURI __104. Click the Done button.
Page 95
IBM Software
__105. Drag an AAA action onto the processing rule.
__106. Double click the yellow outlined AAA action to open its configuration page. __107. In the AAA Policy dropdown, select MyAaaPolicy __108. Click the Done button. __109. Click the Apply Policy button to save the new policy. __110. Click the Close Window link to close the policy editor. __111. Click the Apply button to save the XML Firewall configuration.
4.9.3
Create the SAML AAA Policy
The AAA policy you just modified will be executed by the service consumer (partner) before sending the request to the service provider. The service provider will need an AAA policy that looks for a signed SAML assertion as its authentication credentials. Youll create the AAA policy in the next steps. __112. In the left navigation menu, under the Objects menu, XML Processing section, click on AAA Policy. __113. Click the Add button to create a new AAA policy. __114. For the Name field, type: MySamlPolicy The request will contain a SAML assertion signed by the partner with PartnerKey. The PartnerCert is used to verify the signature. In an earlier lab, you created a validation credential that contained PartnerCert. This AAA policy will use that validation credential to verify the digital signature on the SAML assertion. __115. In the SAML Signature Validation Credential, select: MyValcred
Page 96
IBM Software
__116. Click on the Identity tab at the top of the form.
__117. For Methods, select: Name from SAML Authentication Assertion __118. Click on the Authenticate tab at the top of the form. __119. In the Method dropdown, select: Accept a SAML Assertion with a Valid Signature __120. Click on the Resource tab at the top of the form. __121. For the Resource Information, select: Local Name of Request Element __122. Click the Apply button. The final steps are to add the new AAA Policy to the E6BService. For this exercise, youll add the AAA policy to the CalculateFlightLeg operation. __123. Click on the Control Panel link at the top of the left navigation pane. __124. In the left navigation pane, click on the Services menu. __125. In the Web Service Proxy section, click on: Edit Web Service Proxy. __126. Click on E6BServiceProxy. __127. Click on the Policy tab. __128. In the Web Service Proxy Policy section, click on: Open tree to Operations. This will show all of the operations in the service.
__129. Scroll down and locate the CalculateFlightLeg operation. Click the Add Rule button. __130. In the Rule Direction field, select: Client to Server
Page 97
IBM Software
__131. Drag an AAA action after the match action.
__132. Double Click the yellow outlined AAA action to open its configuration page. __133. In the AAA Policy field, select: MySamlPolicy __134. Click the Done button. __135. Click the Apply button to save these configuration changes.
4.9.4
Testing SAML Federation
In these last steps, youll submit several requests to the E6BService to show that the SAML-based federation is effectively working. First, youll verify that you can no longer execute the CalculateFlightLeg operation without a SAML assertion. __136. In soapUI, under the CalculateFlightLeg operation, double click on Request 1 to bring it up again. __137. Make sure there is no Username, Password, or WSS-Password Type specified in the Request properties. __138. In the endpoint dropdown list, make sure that http://datapower:445nn/E6BService/E6BService is selected. __139. Click the green submit button to execute the request. It should fail with a SOAP fault: Rejected by Policy. It is failing because the policy now requires a signed SAML assertion and there isnt one. Now youll post a message to the XML Firewall that represents the partner consumer. Again, do it without a username and password so that you can see that it is enforcing the need for a WS-Security UsernameToken. __140. In the dropdown endpoint, select the partner service (XML Firewall) that is listening on port 555NN, and then edit it so the port correctly shows your student number. For example, student01 should show port 55501. __141. Click the green submit button to post the request to the XML Firewall (partner).
Page 98
IBM Software
The request should fail since the partners AAA policy is expecting to extract the username and password from a WS-Security UsernameToken. Finally, submit the request with the username and password. The request will pass authentication in the partner service, which will then create a signed SAML assertion and forward the request to the WS-Proxy thats protecting the real web service. The WS-Proxy will consume the signed SAML assertion and permit the request to go through. __142. In the Request Properties section in soapUI, specify the following properties: __a. Username: david __b. Password: foobar __c. WSS-Password Type: PasswordText __143. Once again, click the green submit button. This time, the request should succeed. __144. If your configuration is working properly, click the Save Config link in the upper right corner of the window to save your configuration to the flash memory
4.10 Summary
In this lab, you had a brief introduction to the Web Service Proxy (WSP) and how it can be configured to protect your web services. You saw how the WSP is self-configuring simply by providing a WSDL, either through uploading or subscription to a WSDL repository such as UDDI or WebSphere Service Registry and Repository. You also had a brief introduction to DataPowers support for WS-Policy, a specification that helps Web service consumers understand the required policy governing the services usage. Both WSDL and policy documents can be uploaded into WebSphere Service Registry and Repository and automatically retrieved by DataPower through a self-updating subscription. You then saw how DataPower can enforce service usage levels through its SLM facility. Though only a simple SLM policy was demonstrated that limited the request rate, complex SLM policies can also be defined that consider nearly any aspect of a request when determining whether or not the request should be processed or rejected. Finally, the lab wrapped up by creating a mock environment for SAML-based federation. You created an XML Firewall with an AAA policy that authenticates the user against an LDAP and then generates a signed SAML assertion. Then you created a new AAA policy that looks for a signed SAML authentication assertion.
Page 99
IBM Software
Lab 5

WebSphere MQ and Transformation Extender Integration

DataPower integrates with WebSphere MQ. To create a connection to a queue manager using a Queue Manager connection object. DataPower can bridge between HTTP and MQ. WebSphere Transformation Extender Design Studio is used to design maps that translate between XML and non-XML formats. To configure DataPower to execute WebSphere Transformation Extender maps created in WebSphere Transformation Extender Design Studio.
In this lab, youll learn how:
5.1
Protocol Bridging: HTTP to WebSphere MQ
DataPowers 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. When bridging HTTP to WebSphere MQ (or any messaging protocol), the multi-protocol gateway can function either synchronously or asynchronously. In a synchronous configuration, the Multi-Protocol Gateway (MPGW) receives a request over HTTP, processes it, and then forwards the message to a queue (using a PUT). The MPGW will then listen on another queue for the response (using the correlation ID). When the message arrives, the MPGW will process it, then convert it to HTTP and return it as the response to the original message.
GET
PUT
WebSphere MQ and TX Integration
Page 101
IBM Software
In an asynchronous scenario, the MPGW receives the request over HTTP or MQ, processes it, and then PUTs the message onto the designated queue. No response processing will occur.
Local Queue
Local Queue
5.2
MQ Lab Environment
The instructor machine has a Java application that connects to QM_demoserver and waits for messages on a queue named requests. When a message arrives, the application will copy the contents of the message to a new message, update the MQ correlation ID to be the original MQ message ID, and then put the new message on a queue named replies. Essentially, this is an echo service using queues instead of HTTP.
5.3
Connecting to an MQ Queue Manager
A DataPower queue manager connection object acts as a reusable proxy between the DataPower appliance and an actual MQ Queue Manager. The queue manager object is responsible for coordinating all communications between the DataPower appliance and WebSphere MQ. In the next steps, youll configure a MQ Queue Manager connection object. __1. __2. __3. __4. __5. __6. __7. In the left navigation pane, make sure the Objects menu is open. If its not, click on it to open it up. In the Network Settings section, locate and click MQ Queue Manager. In the Configure MQ Queue Manager form, click the Add button to create a new MQ Queue Manager object. In the Name field, type: MyMqManager For Host Name, type: demoserver(1414) For Queue Manager Name, type: QM_demoserver At the top of the form, click the Apply button.
Page 102
IBM Software
5.3.1
Modify the Multi-Protocol Gateway
To save time, youll re-use the multi-protocol gateway (MyService) that you created in lab 2. Youll create a new processing rule that will dynamically reroute inbound messages to the MQ echo service instead of the HTTP echo service. __8. __9. __10. __11. __12. __13. __14. __15. __16. __17. __18. __19. __20. __21. __22. __23. In the left navigation pane, click on the Control Panel link. Click on the Multi-Protocol Gateway icon in the top row of services. Click on the MyService link to open the configuration page. In the Multi-Protocol Gateway Policy field, click on the ellipsis () to open the policy editor. In the Rule section, click on the New Rule button to create a new processing rule. Change the Rule Name to: MqRule In the Rule Direction dropdown, select: Client to Server Double Click the yellow outlined match action to open its configuration page. In the Matching Rule field, click the plus (+) button to create a new matching rule. In the Name field, type: MatchMQ Click the Matching Rule tab at the top. In the Matching Rule section, click the Add button. In the URL Match field, type: */mq Click the Apply button. Click the Apply button in the Configure Matching Rule window. Click the Done button in the Configure Match Action window.
The Multi-Protocol Gateway service is currently setup to forward all requests to http://demoserver:9080/EchoService/echo. In the next steps, youll add a Route action to reroute messages to MQ instead of the HTTP echo service.
Page 103
IBM Software
__24.
Drag a Route action onto the rule after the match action.
__25. __26.
Double click the yellow outlined Route action to open its configuration page. In the Configure Route Action page, use the following values: __a. In the Selection Method, select: Use Variable to Select Destination __b. In the upper Destination dropdown, select: dpmq:// __c. In the lower Destination textbox, type the following URL: MyMqManager/?RequestQueue=requests;ReplyQueue=replies
__27.
Click the Done button to save the route action.
Important! You must move the new MqRule up in the list of configured rules so that it is ahead of EchoRule.
__28.
In the Configured Rules section at the bottom of the policy editor, click the up arrow next to the newly created MqRule to move it ahead of EchoRule.
__29. __30. __31.
Click the Apply Policy button to activate the changes to the policy. Click the Close Window link to close the policy editor. Click the Apply button to save these changes to the multi-protocol gateway service.
Now you can test the configuration by posting a message with /mq in the URL.
Page 104
IBM Software
__32. __33.
At the command prompt, use the CD command to change directory to c:\labs\lab5. Type the following command, and replace the NN with your student number: post soapMsg.xml http://datapower:444nn/mq The contents of soapMsg.xml should be echoed into the command window.
If youd like to see details about how the message travelled from HTTP to MQ, you can use the transaction probe or view the system logs.
5.4
Transforming Non-XML Payloads
Up until now, youve seen how DataPower can manipulate XML documents in a variety of ways including encrypting, decrypting, signing, and transforming. Youve also seen how DataPower can mediate between various types of protocols such as HTTP 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 havent yet been enabled for XML. The IBM WebSphere DataPower Integration Appliance XI50, together with the IBM WebSphere Transformation Extender Design Studio, enable you to create transformations that convert between XML and non-XML data (fixed-width fields, comma separated fields, etc). This are referred to as a binary transformations. The process involves two steps. First, a mapping between the XML and non-XML data must be created using WebSphere Transformation Extender Design Studio. Once the maps are created, a special mapping file is exported from WebSphere Transformation Extender Design Studio and imported into DataPower.
5.4.1
Creating the WebSphere Transformation Extender Maps
There are three basic steps to building a WebSphere Transformation Extender Map using the Design Studio

Define the input and output formats. Map the input to the output and apply any rules or functions to manipulate the data. Build, test and deploy the map.
5.4.2
Defining the Input and Output Data
When defining a binary transform, WebSphere Transformation Extender uses the notion of Input Cards and Output Cards. Input cards are used to define the format of the source data to be transformed, and output cards define how the data should be formatted. A Map contains the associations and rules for moving the data from the input to the output card.
Page 105
IBM Software
Input and output cards can be automatically created by importing various types of data descriptions, such as XML schema and COBOL copybook to name just a few. For this lab, the following schema was imported to create the input card.
The schema describes an XML document that looks like the following:
Page 106
IBM Software
The output card was generated by importing a COBOL copybook (shown below).
Once the input and output cards are defined, a map is created by dragging fields from the input card and dropping them onto the output card. WTX contains a large library of functions, such as math and string manipulation, that can be used when creating the maps.
Page 107
IBM Software
5.4.3
Building, testing and deploying your map to DataPower
Once the maps are defined, they are built and tested within WebSphere Transformation Extender Design Studio. If the map definitions produce the desired results, then they can be uploaded to DataPower for execution. __34. If youre interested to see a short video showing the actual map creation, do the following steps: __a. Open a browser window and navigate to: http://demoserver __b. In the Labs section, locate and click the WTX Design Studio Demo link. Note: If this does not work, you can also locate the video in the labs/lab5/WTXdemo folder. To manually start the video, locate and double click the html file in that directory.
5.5
Executing the Map on DataPower
To configure DataPower to execute the XML to COBOL map, youll add a binary transform action to the MQ rule you created earlier in this lab. __35. __36. __37. In the Multi-Protocol Gateway Policy field, click on the ellipsis () to open the policy editor. In the Configured Rules section, click on the MqRule name to make it the active rule in the editor. Drag an Advanced action onto the rule before the Route action.
__38. __39. __40.
Double click the yellow outlined Advanced action to open its configuration. In the list of action types, scroll to the bottom and select: Transform Binary. Click the Next button.
Page 108
IBM Software
__41.
In the WTX Map file field: __a. Click the Upload button. __b. Browse to labs\lab5 and select: XMLtoCBL.dpa __c. Click the Upload button. __d. Click the Continue button.
__42.
Click the Done button.
The rule should now look like the following image.
When you first created this rule, the results action (the last action in the rule) was automatically configured to forward the original INPUT message to the requests queue. This is no longer the desired action. The results of the binary transform (not the original received message) should be put on the queue. By deleting the results action, DataPower will automatically create a new results action that forwards the output from the binary transform. __43. Drag the results action off of the rule and drop it in the trash can.
__44. __45.
Click the Apply Policy button. Click the Close Window link to close the policy editor.
Theres one last thing to do before you can test this service. Previously you configured the service to expect the inbound requests and server responses to be SOAP messages. Since this example will use raw XML for the inbound message, you need to change the services configuration so that it wont complain when you send a message thats not SOAP.
Page 109
IBM Software
__46. __47. __48.
In the configuration page, scroll down and locate the section labeled Request Type and change its selection to: XML. In the Response Type section, select: Pass-Thru Click the Apply button to save the changes to the multi-protocol gateway service.
Youre now ready to test this service. Instead of posting the soapMsg.xml file, youll post ContactInfo.xml instead. __49. Type the following command, and replace the NN with your student number: post ContactInfo.xml http://datapower:444nn/mq The results should be a flat record instead of XML.
5.6
Summary
In this lab, you saw: How you can use the Route action to dynamically change the destination endpoint of a message. Specifically, you rerouted a message to an MQ queue instead of the original HTTP EchoService. How DataPower can act as a WebSphere MQ Client. That WebSphere Transformation Extender Design Studio can be used to create binary transformations (any to any). WebSphere Transformation Extender uses input cards to define how the input is formatted, output cards to define how the desired output should be formatted, and mapping files to define the relationship and mapping rules between the input and output cards. How DataPower can execute maps built using WebSphere Transformation Extender Design Studio to perform binary transformations.
Page 110
IBM Software
Appendix A. Common Deployment Scenarios

DataPower deployments are easily tailored to meet your enterprises requirements development, testing, production, and disaster recovery requirements. This appendix gives a brief overview on the most common enterprise deployment scenarios. There are six basic areas where DataPower SOA Appliances are deployed. These six areas can be mixed and matched as necessary. Pick and choose the categories that apply to your specific project timelines and risk profiles.
These categories are independent of network segment considerations such as DMZ vs. internal cloud.
Lab Environment
Isolated environment allows testing of major new firmware features without impacting ongoing development streams. Common in mature DataPower installations with multiple ongoing development efforts.
Development Environment

Very common practice to isolate development to a dedicated environment. Single appliance for developer sandbox as well as project-specific configuration.
Testing Environment
Isolating the test environment from the development environment is a common best practice. Unique environments ease the burden of code migration.
Staging Environment

Staging environment allows testing pre-releases, or rolling new releases into production. Often re-used as a performance test lab to determine peak supported throughput in a production-like environment.
Production Environment
Appliances can be deployed in active/active (with a load balancer) or active/passive (without). Appliances can balance traffic to target servers, so a second load balancer is NOT required.
Disaster Recovery

Many organizations require full data center failover to a second fully equipped site. Specific project risk profile will dictate this need.
Common Deployment Scenarios
Page 111
IBM Software
Appendix B. XACML Support

XACML, which is short for Extensible Access Control Markup Language, is an OASIS standard that describes both a policy language and an access control decision request/response language, both which are encoded using XML.
The policy language is used to describe general access control requirements, and has standard extension points for defining new functions, data types, combining logic, etc. The request/response language lets you form a query to ask whether or not a given action should be allowed. The response always includes an answer about whether the request should be allowed using one of four values: Permit, Deny, Indeterminate (an error occurred or some required value was missing, so a decision cannot be made) or Not Applicable (the request can't be answered by this service).
XACML employs two primary components to carry out authorization requests:
Policy Enforcement Point (PEP), which acts as the gatekeeper and is responsible for extracting the various bits of information from the inbound request and creating 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. Policy Decision Point (PDP), which acts as the decision maker and 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 response is returned in a XACML authorization response document.
There are many existing proprietary and application-specific languages for doing this kind of thing but XACML has several points in its favor:
It's standard. By using a standard language, you're using something that has been reviewed by a large community of experts and users, you don't need to roll your own system each time, and you don't need to think about all the tricky issues involved in designing a new language. Plus, as XACML becomes more widely deployed, it will be easier to interoperate with other applications using the same standard language. It's generic. This means that rather than trying to provide access control for a particular environment or a specific kind of resource, it can be used in any environment. One policy can be written which can then be used by many different kinds of applications, and when one common language is used, policy management becomes much easier. It's distributed. This means that a policy can be written which in turn refers to other policies kept in arbitrary locations. The result is that rather than having to manage a single monolithic policy, different people or groups can manage separate sub-policies as appropriate, and XACML knows how to correctly combine the results from these different policies into one decision.
XACML Support
Page 113
IBM Software
It's powerful. While there are many ways the base language can be extended, many environments will not need to do so. The standard language already supports a wide variety of data types, functions, and rules about combining the results of different policies. In addition to this, there are already standards groups working on extensions and profiles that will hook XACML into other standards like SAML and LDAP, which will increase the number of ways that XACML can be used.
The XACML Policy Document

The XACML policy document describes a security policy and is 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 rules effect attribute. XACML policy documents are not usually coded manually; rather a product such as Tivoli Security Policy Manager or some other XACML-enabled policy manager will generate the XACML policy document.
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 policy decision point (PDP). The XACML authorization request document 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 114
IBM Software
XACML and DataPower

DataPower has the ability to act as both the policy enforcement point and the policy decision point. As a policy enforcement point, DataPower uses an AAA action to extract the credentials and resource information from a request and create a XACML authorization request document. The AAA policy will then send that authorization request document to a XACML policy decision point. In the following diagram, DataPower receives requests from a client, extracts the credential and resource details, then creates and sends a XACML AuthZ request document to the PDP. The PDP responds with a XACML AuthZ response document. DataPower interprets the response and either allows or denies the request accordingly.
Policy Enforcement Point
XACML AuthZ Request Doc
XACML AuthZ Response Doc
XACML Policy Decision Point
XACML Support
Page 115
IBM Software
Since DataPower supports XACML policy documents, it can act as a PDP as well. The following diagram shows how DataPower can act as a PDP for many XACML PEPs. When DataPower receives an XACML AuthZ request, it makes the decision based on a cached XACML policy document and responds accordingly.
= XACML AuthZ Req/Rsp
PEP PEP
PEP
PEP
Policy Decision Point
XACML Policy Document (cached)
Policy Server
DataPower can also act as both a PEP and a PDP. In the following diagram, DataPower fetches and caches the XACML policy document from the policy server. When requests arrive, DataPowers can make the allow/deny decision independently without additional communications.
Policy Enforcement Point AND Policy Decision Point
XACML Policy Document (cached)
Tivoli Security Policy Manager
Page 116
IBM Software
Appendix C. Multi-Box Management with WebSphere Application Server Network Deployment v7.0
WebSphere Application Server Network Deployment v7.0 now provides robust management capabilities for DataPower SOA Appliances. The administration console now enables administrators to easily deploy, update, and manage configurations on multiple DataPower SOA Appliances. Specifically, appliances are managed using the WebSphere Integrated Solutions Console (also known as the admin console). The admin console exposes this new set of capabilities through an embedded engine known as the WebSphere DataPower Appliance Manager. Under the covers it communicates with DataPower SOA Appliances using the Appliance Management Protocol (AMP). Once a master appliance has been designated in a managed set it can be used to synchronize sharable appliance settings and managed domains for all appliances within the managed set. WebSphere Application Server admin console provides a simple graphical user interface to manage multiple appliances. There are no additional installation or configuration tasks required to enable this functionality. WebSphere Application Server Network Deployment 7.0 includes the following set of features for managing groups of DataPower SOA Appliances:
A centralized repository for firmware and the distribution of firmware across multiple devices. The configuration of device clusters (Managed Set) that are intended to share similar configuration. The discovery and propagation of modifications within a cluster. Firmware version control management, shareable device settings, and application domains (Managed Domains) with roll-back capability. Tracking of device synchronization and operation state.
Multi-Box Management
Page 117
IBM Software
The following image shows the administration console showing a managed cluster of two DataPower SOA Appliances.
The following image shows the DataPower SOA Appliances Firmware repository in the WebSphere Application Server administration console.
Page 118
IBM Software
Appendix D. 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.
The (XML) Threat is Out There
Page 119
IBM Software
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 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. 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. 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. 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. Data integrity/Confidentiality Message tampering -- Modifying parts of a request or response in-flight; most dangerous when undetected (less commonly known as Message alteration).
Page 120
IBM Software
Data tampering -- Exploiting weakness in the access control mechanism that permits the attacker to make unauthorized calls to the Web service to alter data. 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. 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
The (XML) Threat is Out There
Page 121
IBM Software
Appendix E. 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
Notices
Page 123
IBM Software
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. 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. All references to fictitious companies or individuals are used for illustration purposes only. 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 124
IBM Software
Appendix F.
Trademarks and copyrights
[The following list is a sample. Add any other IBM trademarks that are used in the workbook. The editor who performs the legal review of the workbook will also check this list to ensure that it is complete. Remove bracketed information when you are done.] The following terms are trademarks of International Business Machines Corporation in the United States, other countries, or both:
IBM Cube Views Informix Rational System z AIX DB2 Lotus Redbooks Tivoli CICS developerWorks Lotus Workflow Red Brick WebSphere ClearCase DRDA MQSeries RequisitePro Workplace ClearQuest IMS OmniFind System i System p Cloudscape IMS/ESA
Adobe, Acrobat, Portable Document Format (PDF), and PostScript are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, other countries, or both. Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom. 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. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. ITIL is a registered trademark and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce. Other company, product and service names may be trademarks or service marks of others.
Appendix
Page 125
NOTES
NOTES
Copyright IBM Corporation 2009. All rights reserved.
The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. This information is based on current IBM product plans and strategy, which are subject to change by IBM without notice. Product release dates and/or capabilities referenced in these materials may change at any time at IBMs sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way.
IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
IBM Software Group
2009 IBM Corporation

PoT - Websphere.08.4.060.09 Workbook

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PoT - Websphere.08.4.060.09 Workbook

Uploaded by

Copyright:

Available Formats

IBM Software Group

2009 IBM Corporation

Discovering the Value of IBM WebSphere DataPower SOA Appliances

Internet Explorer, version 6 or 7 Firefox 2

Introduction to DataPower SOA Appliances

DataPower SOA Appliances Family

WebSphere DataPower XML Accelerator XA35

WebSphere DataPower XML Security Gateway XS40

Introduction to DataPower Appliances

WebSphere DataPower Integration Appliance XI50

WebSphere DataPower B2B Appliance XB60

Discovering the Value of IBM WebSphere DataPower SOA Appliances

WebSphere DataPower Low Latency Appliance XM70

DataPower Access Control

Introduction to DataPower Appliances

DataPower Application Domains

The DataPower WebGUI

Discovering the Value of IBM WebSphere DataPower SOA Appliances

Upon successful login, the DataPower Control Panel will be shown.

Introduction to DataPower Appliances

There are several areas in the WebGUI worth noting:

Discovering the Value of IBM WebSphere DataPower SOA Appliances

DataPower Configuration Procedures

Network services and user access configuration phase

Application Development Phase

Production Management Phase

Introduction to DataPower Appliances

HTTP(S) GET HTML

HTTP(S) GET XML

XML to HTML Transformation

Web Application Firewall

Discovering the Value of IBM WebSphere DataPower SOA Appliances

HTTP POST HTML

HTTP POST HTML

Authentication/Authorization Cookie encryption/decryption Cross-site scripting protection

Session timeout management Name-value input processing/filtering

HTTP(S) POST: XML XML

HTTP(S) POST: XML XML

AuthN/AuthZ/Audit Encryption/Decryption Digital sign/verify

Schema validate XSL Transformation Service level monitoring

Any-to-Any Transform Message filtering Content-based routing

Introduction to DataPower Appliances

Web Service Proxy

Web Service Proxy

DataPower SOA Appliances and Service Matrix

DataPower Flash-based File System

Introduction to DataPower Appliances

Discovering the Value of IBM WebSphere DataPower SOA Appliances

__12. __13. __14. __15. __16.

Introduction to DataPower Appliances

Discovering the Value of IBM WebSphere DataPower SOA Appliances

Setting the Logging Level to Debug

Introduction to DataPower Appliances

In the Monitoring and Troubleshooting section, click on the View Logs.

Discovering the Value of IBM WebSphere DataPower SOA Appliances

Click the Add button to create a new Log Target.

Introduction to DataPower Appliances

Discovering the Value of IBM WebSphere DataPower SOA Appliances

1.10 Device management

1.10.1 Backup and Restore

1.10.2 Device Status

Introduction to DataPower Appliances

1.10.3 Remote monitoring

12. 13. 14. 15. __16.

3. 4. __5.

14. 15. __16.

21. 22. 23. 24. 25. 26. 27. 28. __29.

51. 52. __53.

56. 57. __58.

73. 74. __75.

79. 80. 81. 82. 83. 84. __85.

94. 95. 96. 97.