Xi 3[1].6.0-example configs

557 views

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
557
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Xi 3[1].6.0-example configs

  1. 1. WebSphere DataPower XML Integration Appliance XI50 ®Release 3.6.0Example Configurations
  2. 2. WebSphere DataPower IBM WebSphereDataPower XML Integration Appliance XI50 Example Configurations Release 3.6.0
  3. 3. First Edition (October 2006)This edition applies to version 3, release 6, modification 0 of IBM WebSphere DataPower XMLIntegration Appliance XI50© Copyright International Business Machines Corporation 2002, 2006. All rights reserved.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADPSchedule Contract with IBM Corp.
  4. 4. Table of ContentsChapter 1Human Resources Web Portal Scenario A: Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 XML Firewall Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7 Rule #1: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7 Rule #2: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15 Rule #3: Error Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18 Duration Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20 Message Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20 Message Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21 Message Filter Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22 Duration Monitor Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25 Object Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26 Event Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27 Scenario B: An HTML Forms Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28 XML Firewall Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29 Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-33 Rule #1: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-33 Rule #2: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-45 Rule #3: Error Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-48 SSL Server Crypto Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-50 Crypto Identification Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51 Crypto Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51 Crypto Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-52 Scenario C: Multi-Protocol, Single Port Service . . . . . . . . . . . . . . . . . . . . . . . . . . 1-53 XML Firewall Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-54 Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-58 Rule #1: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-58 Rule #2: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-64 Rules 3 to 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-68Chapter 2Bank Checking Web Service XML Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 Rule #1: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9 Match Rule: Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9 Implied Action 0: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9Release 3.6 iii
  5. 5. Action 1: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10 Action 2: Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 Action 3: Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14 Action 4: AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15 AAA Policy: SAML-Attr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16 Action 5: Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20 Rule #2: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21 Match Rule: Encrypted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21 Action 1: Decrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21 Action 2: Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24 Rule #3: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25 Match Rule: Signed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25 Action 1: Verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26 Action 2: Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27 Action 3: Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28 Rule #4: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31 Match Rule: Signed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31 Action 1: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31 Action 2: Encrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32 Action 3: Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33 Rule #5: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35 Match Rule: Encrypted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35 Action 1: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-36 Action 2: Encrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37 Rule #6: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39 Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46 Object Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47 Event Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47 SSL Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-49 Crypto Identification Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50 Crypto Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50 Crypto Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51 SomeBank Checking Service WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-52Chapter 3Multi-Protocol Gateway Multi-Protocol Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Advanced Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 XML Threat Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 Single Message XML Denial of Service (XDOS) . . . . . . . . . . . . . . . . . . . 3-7 Multiple Message XML Denial of Service (MMDOS) . . . . . . . . . . . . . . . . 3-7 Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 Front Side Protocol Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 HTTP Front Side Protocol Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 HTTPS Front Side Protocol Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10 MQ Front Side Protocol Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11 Websphere MQ Queue Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 Multi-Protocol Gateway Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15iv Release 3.6
  6. 6. Rule #1: Request Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17 Match Rule: Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17 Implied Action 0: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17 Action 1: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18 Action 2: Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20 Action 3: Verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22 Action 5: Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23 Rule #2: Response Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24 Match Rule: Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24 Action 1: Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24 Action 3: Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28 Object Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29 Event Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30 SSL Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31 SSL Proxy Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31 Crypto Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32 Crypto Identification Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33 Crypto Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34 Crypto Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34 Validation Credential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35Chapter 4Example Web Application Firewall Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Application Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 Request Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 Response Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6 Error Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7 Error Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12 Web Request Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12 HTML Form Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12 XML-Based Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16 Web Response Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20 Rate Limiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23 Name Value Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24 HeaderFilter Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24 Suppressor Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26 XycoPost Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28Chapter 5SOAP with Attachments XML Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5 Rule #1: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7 Rule #2: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11 Rule #3: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16 Rule #4: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18 Rule #5: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22Release 3.6 v
  7. 7. Rule #6: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24 Rule #7: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27 Rule #8: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32 Rule #9: Two Way Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34 Additional Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37 Base64 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37 Attachment Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37 DIME Attachment Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38Notices Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notices-1vi Release 3.6
  8. 8. Chapter 1 Human Resources Web PortalThis example configuration implements a human resources web portal benefits service, allowingemployees to request services from human resources through a web interface.Scenario A: Web ServicesThe service is implemented initially to support departmental application servers submitting well-formed SOAP requests to the DataPower system. The application servers interact with the enduser browsers. The headquarters IT systems employ task-specific Web service endpoints to handlethe range of HR information needs. Here is an illustration of the architecture involved. Web Service 1 SOAP HTML SOAP Web Service 2 DataPower SOAP Web Service 3 Browsers App Servers Figure 1 - 1. HR Web Service architectureThe traffic is monitored for transaction times that exceed a configured threshold. All errors arelogged in a special log target built for this service. 1-1
  9. 9. Human Resources Web PortalHere is an example SOAP request supported by this service:<?xml version="1.0" encoding="UTF-8"?><S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <S11:Header> <wsse:Security> <wsse:UsernameToken> <wsse:Username>sfelinish</wsse:Username> <wsse:Password>99cat99</wsse:Password> </wsse:UsernameToken> </wsse:Security> </S11:Header> <S11:Body> <xycohr:request xmlns:xycohr="http://xycohr.com/hrservices"> <xycohr:First_Name>Samantha</xycohr:First_Name> <xycohr:Last_Name>Felinish</xycohr:Last_Name> <xycohr:Employee_ID>7636356</xycohr:Employee_ID> <xycohr:Department>Sales</xycohr:Department> <xycohr:Requested_Service>floatholiday</xycohr:Requested_Service> <xycohr:Service_Date>05/01/2005</xycohr:Service_Date> </xycohr:request> </S11:Body></S11:Envelope>This implementation employs the following configured DataPower components. • XML Firewall • XML Firewall Policy • Document Processing Rules • Document Processing Actions • XPath Routing Map • Duration Monitor • Log TargetIn addition, service-specific stylesheets and schema files were uploaded to the device.1-2 Release 3.6
  10. 10. Scenario A: Web ServicesXML Firewall ServiceThe XML Firewall Service configuration page appears as shown here. Figure 1 - 2. Web Services Firewall ConfigurationThese are the field values.Firewall Name: XycoHRServices The name of the firewall object. This name may appear in the Via: field of the HTTP headers returned during SOAP and XML web service transactions. It also appears in the log files.Firewall Type: Dynamic backend The selection Dynamic backend indicates that the servers to which the firewall will forward requests are determined dynamically by the firewall’s document processing policy. In this case the determination is accomplished through a Route action that in turn employs an XPath Routing Map.XML Manager: Default The default is left in place.Firewall Policy: XycoHRServices The custom policy built for this service, XycoHRServices, is selected. This policy is covered in detail below.Release 3.6 1-3
  11. 11. Human Resources Web PortalURL Rewrite Policy: None The default is left in place. The URLs sent by the clients are not altered in any way.Back EndSSL Client Crypto Profile: None The default is left in place. Communication with the back end servers will not employ SSL in this case.Response Type: SOAP The selection SOAP indicates that the back end servers will post SOAP documents in response to requests from the firewall service. The firewall service automatically validates the documents against the SOAP schemas now in use (SOAP 1.1, 1.2 and variants).Response Attachments: Strip The default value (strip) is left in place. Any attachments sent by the back end service will be stripped off before the message is handled by the firewall service.Front EndDevice Address: 0.0.0.0 The default value of 0.0.0.0 is used. The service will listen at the port indicated on all ethernet addresses configured for the current device.Device Port: 2065 The automatically assigned value of 2075 is used. This could be altered to any value not used by another service on the current device. All traffic bound for this service must use port number 2075. The SOAP HTTP URL resembles http://10.10.13.35:2075/services.SSL Server Crypto Profile: None The default is left in place. Communication with the front end clients will not employ SSL in this case.Request Type: SOAP The selection SOAP indicates that the clients will post SOAP-formatted documents to the firewall service. Inbound SOAP documents are automatically validated against the published SOAP schemas. If the messages do not comply with the schemas, an error is returned to the client.Request Attachments : Strip The default value (strip) is left in place. Any attachments sent by the clients will be stripped off before the message is handled by the firewall service.1-4 Release 3.6
  12. 12. Scenario A: Web ServicesHere is the Advanced configuration page for this service: Figure 1 - 3. Advanced configuration pageAll defaults are left in place with the exception of the Message Duration Monitor. Here, thecustom configured Xycohr Duration Monitor is assigned to the service.Release 3.6 1-5
  13. 13. Human Resources Web PortalFirewall PolicyHere is the graphic representation of the firewall policy used for this implementation. Figure 1 - 4. XycoHRServices Firewall PolicyHere is a brief explanation of the column headings under Configured Rules: Priority The order in which the rules are executed by the policy. When two rules have a matching rule that could potentially match the inbound document, the rule with the highest priority executes first. Match Name This lists the name of the Matching Rule used to select inbound traffic for execution by the processing actions contained in the rule. Direction This indicates the directionality of the rule. Request rules handle inbound traffic from the front end clients, response rules handle responses from the back end services, and Error rules execute when an error is encountered. Actions The iconic representation of the actions contained in the rule.Click on any of the rules listed here to make the rule the current rule. The main display of the pagechanges to that rule. The action configurations can then be modified.1-6 Release 3.6
  14. 14. Scenario A: Web ServicesRulesRule #1: Request RuleHere is an examination of the components of Rule #1. Note that this is a Request rule; it will onlyhandle messages sent to the service by the client and will not handle messages sent by the serverback to the client.Match Rule: ServicesA Match Rule examines the inbound message and determines whether or not the rule should be runagainst the message. In this case, the match rule examines the URL used by the client to determinea match. Here is the configuration display of the match rule maps. Figure 1 - 5. Services Match Rule ConfigurationThe client must use the URL */services or this rule will not be applied to the message. Note that theexpression * means “any substring of any characters.”Implied Action 0: ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to insurethat no message that does not conform to the SOAP schemas will be sent to the back end webservice endpoints. This SOAP schema filtering is implied and no action needs to be created for it.However, the presence of this valildation action can cause inbound messages to be rejected by thefirewall before any of the actions visible in the Firewall Policy have run.Release 3.6 1-7
  15. 15. Human Resources Web PortalAction 1: ValidateThe first custom action of Rule #1 validates the contents of the SOAP Body element against acustom schema. This insures that the payload also contains the required elements and does notcontain invalid elements. Here is the configuration of this action: Figure 1 - 6. Validate ConfigurationInput: INPUT This is set to INPUT, the special context representing the original message received by the service.Schema Validation Method: Schema URL This is set to validate the document using a schema URL. A URL must be provided that identifies the location of the schema file to use.Schema URL: local:///Xycohr.xsd This is set to local:///Xycohr.xsd. The custom schema file has been uploaded to the device and placed in the local: directory.Output: tmpvar2 This is set to tmpvar2. The results of the validation will be placed in this context. If the input is valid, the context will contain the validated message. If an error occurs (the message fails to validate, for example), the context is empty. Any subsequent actions can access the results by using tmpvar2 as the input context.1-8 Release 3.6
  16. 16. Scenario A: Web ServicesHere is the schema file used for this action.<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xycohr="http://xycohr.com/hrservices"xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" target-Namespace="http://xycohr.com/hrservices" elementFormDefault="qualified"> <xs:element name="request" type="xycohr:hrrequest"/> <xs:complexType name="hrrequest"> <xs:sequence> <xs:element name="UserName" type="xs:string" minOccurs="0"/> <xs:element name="Password" type="xs:string" minOccurs="0"/> <xs:element name="First_Name" type="xs:string"/> <xs:element name="Last_Name" type="xs:string"/> <xs:element name="Employee_ID" type="xs:string"/> <xs:element name="Department" type="xs:string"/> <xs:element name="Requested_Service" type="xs:string"/> <xs:element name="Service_Date" type="xs:string"/> </xs:sequence> </xs:complexType></xs:schema>Action 2: FilterThis action filters the validated message for the presence of required values within the message. Iteither accepts or rejects the message. Here is the configuration display for this action: Figure 1 - 7. Filter ConfigurationInput: tmpvar2 This is set to tmpvar2, the named context used by the preceeding action. Note that this could have been set to INPUT since this action would not execute if the validation before it failed. However, validation can sometimes change the message format, thus this action uses the result of the validation.Release 3.6 1-9
  17. 17. Human Resources Web PortalProcessing Control File: local:///Xycohr.xsl This is set to local:///Xycohr.xsl. The custom XSLT file has been uploaded to the device and placed in the local: directory.Output: (blank) This is set to be automatically generated by the policy configuration page. Unlike a transform or a validate action, a filter action typically does not return a nodeset. It accepts or rejects the input for further processing by the next action in the rule.Here is the XSLT file used for this Filter action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" extension-element-prefixes="dp"xmlns:dp="http://www.datapower.com/extensions" exclude-result-prefixes="dp"> <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/> <xsl:template match="/"> <!-- the SOAP envelope must be taken into account --> <xsl:apply-templates select="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=request]"/> </xsl:template> <xsl:template match="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=request]"> <xsl:variable name="errtext" select="Incomplete Input"/> <xsl:variable name="errtest"> <!-- dont allow blank fields; all are required --> <xsl:for-each select="./*"> <xsl:if test="string-length() = 0"> <xsl:value-of select="local-name()"/>: </xsl:if> </xsl:for-each> </xsl:variable> <xsl:choose> <!-- $errtest will only have content if some element is blank; if so reject the message --> <xsl:when test="$errtest != "> <dp:xreject reason="$errtext"/> <!-- put a message in the log file; $errtest contains the names of the offending ele-ments --> <xsl:message dp:type="xmlfirewall" dp:priority="error"> <xsl:value-of select="$errtest"/> </xsl:message> </xsl:when> <xsl:otherwise> <!-- all is well --> <dp:accept/> </xsl:otherwise> </xsl:choose> </xsl:template></xsl:stylesheet>1 - 10 Release 3.6
  18. 18. Scenario A: Web ServicesAction 3: TransformThis tranform action serves to connect the last context that contained the possibly altered messageto any actions that follow. The policy configuration page automatically creates this actionfollowing a filter. Here is the configuration page display for this action. Figure 1 - 8. Transform ConfigurationInput: tmpvar2 This is set to tmpvar2, the named context used by the preceeding action. Note that this could have been set to INPUT since this action would not execute if the validation before it failed. However, validation can sometimes change the message format, thus this action uses the result of the validation.Document Processing Instructions: Specified by rule This is set to use an XSLT file specified in this rule rather than any instructions contained within the XML message itself.Processing Control File: store:///identity.xsl This is set to store:///identity.xsl. This XSLT file is supplied with the firmware. It simply copies the input to the output context.Output tempvar3 This is set to tempvar3. The policy configuration page automatically assigned this context name.Release 3.6 1 - 11
  19. 19. Human Resources Web PortalAction 4: RouteThis action dynamically routes the message to a target destination, which is, in this scenario, oneof three Web service endpoints. This action uses an XPath Routing Map object to determine theproper destination target. Figure 1 - 9. Route ConfigurationInput: tempvar3 This is set to tempvar3, the named Output context used by the preceeding action.Selection Method: XPath Routing Map This is set to use an XPath Routing Map.XPath Routing Map: xycohr This is set to xycohr. This is the name of a configured XPath Routing Map object that uses XPath expressions to extract values from the message. Those values are then used to match the message with a destination target. The XPath Routing Map is explained below.Output: (Blank) This is set to blank. A Route action does not output a nodeset. Note that because it does not, it will be necessary to include one more action in the rule to connect the last context that contains the full message to the special OUTPUT context, which is what is sent out on the wire to the destination target.XPath Routing Map: xycohrAn XPath Routing Map associates an XPath expression with a destination URL. When the XPathexpression evaluates to true, the target destination for the message is set to the correspondingURL. These mappings for this implementation are shown in Figure X below.An XPath Routing Map object can also use Namespace Mappings to associate namespace prefixesin the XPath expression maps to namespace URIs. This shortens the length of the XPathexpressions while preserving namespace information. This example does not use namespacemapping.1 - 12 Release 3.6
  20. 20. Scenario A: Web ServicesHere is the configuration display of this object. Figure 1 - 10. XPath Routing Map ConfigurationNote that the destinations are mapped according to the value of the Requested_Service node. Theseare mapped to endpoint operations at the destination server ports. If no match is found by thisRoute action using the above mappings, the object returns an error to the client. The next objectnever executes.Action 5: TransformLike Action 3, this transform connects the last context containing the message to the next action,or to the OUTPUT context. This is necessary because the Route action does not return a nodesetwhen doing its work. This is the final action of the rule; if this action executes at all, then theRoute has succeeded and all is clear for delivery to the back end service.Release 3.6 1 - 13
  21. 21. Human Resources Web PortalHere is the configuration display for this object. Figure 1 - 11. Transform ConfigurationInput: tempvar3 This is set to tempvar3, the named output context used by the action preceeding the Route action.Processing Control File: store:///identity.xsl This is set to store:///identity.xsl. This stylesheet is supplied with the firmware.Output: OUTPUT This is set to OUTPUT, the special context that is delivered to the wire. As this is the last action of the rule, whatever is in this context is sent to the destination determined by the Route action. The message goes off to the appropriate back end Web services endpoint.When a submitted message succeeds in transversing the firewall processing policy, the messageappears exactly as it did when it was submitted.1 - 14 Release 3.6
  22. 22. Scenario A: Web ServicesRule #2: Response RuleRule #2 in this policy is a Response rule. It handles messages returned to the service from the backend servers. Note that the Match rule is the same as the Request; the server must reflect the sameURI in its response as the client.Implied Action 0: ValidateThe firewall automatically validates the response message against the SOAP schemas, to insurethat no message that does not conform to the SOAP schemas will be sent back to the client. ThisSOAP schema filtering is implied and no action needs to be created for it. However, the presenceof this valildation action can cause response messages to be rejected by the firewall before any ofthe actions visible in the Firewall Policy have run.Action 1: TransformThis action is present to transform the response from the server prior to delivering it to therequesting client. In this case, it inserts a DataPower transaction ID into the resulting message fortracing purposes.Here is the configuration display for this action: Figure 1 - 12. Response Transform ConfigurationInput: INPUT This is set to INPUT, the special input context containing the original message from the back end server.Processing Control File: local:///xycosvcresponse.xsl This is set to local:///xycosvcresponse.xsl. This custom stylesheet has been uploaded to the device.Output: OUTPUT This is set to OUTPUT, the special context that is delivered to the wire. As this is the last action of the rule, whatever is in this context is sent back to the client as the response from the service.Release 3.6 1 - 15
  23. 23. Human Resources Web PortalHere is the XSLT stylesheet used for this action:<?xml version="1.0" encoding="utf-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig"> <xsl:output method="xml"/> <xsl:template match="/"> <xsl:apply-templates select="/*[local-name()=Envelope]"/> </xsl:template> <xsl:template match="/*[local-name()=Envelope]"> <S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <xsl:apply-templates select="/*[local-name()=Envelope]/*[local-name()=Body]"/> </S11:Envelope> </xsl:template> <!-- omit the header, leaving the uid/pwd behind --> <xsl:template match="/*[local-name()=Header]"> <xsl:copy-of select="."/> </xsl:template> <xsl:template match="/*[local-name()=Envelope]/*[local-name()=Body]"> <S11:Body xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/"> <xsl:apply-templates select="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=response]"/> </S11:Body> </xsl:template> <xsl:template match="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=response]"> <xycohr:response xmlns:xycohr="http://xycohr.com/hrservices"> <xsl:for-each select="./*"> <xsl:copy-of select="."/> </xsl:for-each> <xycohr:trans-id> <!-- get the DP transaction id and insert it into the response --> <xsl:variable name="rmsg" select="dp:variable(var://service/transaction-id)"/> <xsl:value-of select="$rmsg"/> </xycohr:trans-id> </xycohr:response> </xsl:template></xsl:stylesheet>1 - 16 Release 3.6
  24. 24. Scenario A: Web ServicesHere is an example of the completed round-trip response to the original request:<?xml version="1.0" encoding="UTF-8"?><S11:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/"> <S11:Body> <xycohr:response xmlns:xycohr="http://xycohr.com/hrservices"> <xycohr:First_Name>Samantha</xycohr:First_Name> <xycohr:Last_Name>Felinish</xycohr:Last_Name> <xycohr:Employee_ID>7636356</xycohr:Employee_ID> <xycohr:Department>Sales</xycohr:Department> <xycohr:Requested_Service>floatholiday</xycohr:Requested_Service> <xycohr:Service_Date>05/01/2005</xycohr:Service_Date> <xycohr:result> <xycohr:ticket>47846787498</xycohr:ticket> <xycohr:message>Your request has been received. You will receive email confir-mation regarding the floating holiday you requested within 24 hours. Have a great day.</xycohr:message> </xycohr:result> <xycohr:trans-id>132357</xycohr:trans-id> </xycohr:response> </S11:Body></S11:Envelope>Release 3.6 1 - 17
  25. 25. Human Resources Web PortalRule #3: Error RuleRule #3 in this policy is an Error rule. It handles any errors encountered during the processing ofeither the request or the response rule. Note that a Matching Rule is also used for an Error rule. Itis possible to match on particular error codes. In this case, however, the Match is the same for allother rules. The URL must match the expression */services.Action 1: TransformThis action is present to transform the error message generated by the DataPower processingsystem into something else that includes a traceable transaction number. This is often done toprovide an error message that will be more acceptable to the end user community, or to providemore or different information.Here is the configuration display for this action: Figure 1 - 13. Error Transform ConfigurationInput: INPUT This is set to INPUT, the special input context containing the original message from the back end server.Processing Control File: local:///xyerrormsg.xsl This is set to local:///xyerrormsg.xsl. This custom stylesheet has been uploaded to the device.Output: OUTPUT This is set to OUTPUT, the special context that is delivered to the wire. As this is the last action of the rule, whatever is in this context is sent back to the client as the response from the service.1 - 18 Release 3.6
  26. 26. Scenario A: Web ServicesHere is the XSLT used for this action:<?xml version="1.0" encoding="utf-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig"> <xsl:output method="xml"/> <xsl:template match="/"> <!-- This is not <xsl:copy-of select="."/> which would forward the service-generated message. Instead, this file creates a customized error message --> <env:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <env:Fault> <!-- get the DP transaction ID and include it for troubleshooting --> <xsl:variable name="err" select="dp:variable(var://service/transaction-id)"/> <env:faultcode> <xsl:value-of select="$err"/> </env:faultcode> <env:faultstring>Invalid submission. Please submit a valid request or notify youradministrator of this errorand reference the faultcode number.</env:faultstring> </env:Fault> </env:Body> </env:Envelope> </xsl:template></xsl:stylesheet>Release 3.6 1 - 19
  27. 27. Human Resources Web PortalDuration MonitorThis firewall service employs a Duration Monitor, which watches all traffic passing through thesystem. When the processing of a message, from the moment the request enters the DataPowersystem to the moment the response leaves the DataPower system, takes more time than allowed bythe monitor, the monitor posts a warning notice into the log message stream. Monitors can beconfigured to do more than simply post messages; monitors can throttle back traffic, allowingsome component (usually the back end service) to recover from an overload of requests. In thisexample, a message is posted to the logs.A Duration Monitor object relies on three other objects. The relationship of these objects is shownhere. Duration Monitor Message Type Message Match Message Filter Action Figure 1 - 14. Monitor Object RelationshipMessage MatchAt the lowest, or first level, the monitor will only watch messages that match some criteria. This isdetermined by the Message Match object. Here is the Message Match object configuration usedby Xyco: Figure 1 - 15. Message Match ConfigurationThis monitor will only watch messages that are sent to the service via an HTTP Post. Since allother fields are blank, no other restrictions are placed on the messages monitored. Note that theRequest URL field could have been set to “*/services”, thus restricting the monitor to only thoserequests that would meet the processing rule matching criteria. In this case, it is left open, thus1 - 20 Release 3.6
  28. 28. Scenario A: Web Servicessetting up a monitor that will also watch for invalid requests that take more than a set amount oftime to reject.Messages can also be matched by HTTP Header Values or by messages that don’t contain certainHTTP Header values. For example, a match could be constructed to match only HTTP Headervalues that indicate the message is SOAP. Neither of those constraints are used in this example.Message TypeThe Message Type object is a collection of Message Matching objects. Message Type objectsmake it possible to combine various Message Matching objects into one type. Each Message Typecan use a different combination of Message Matching objects. Here is the configuration for thisexample: Figure 1 - 16. Message Type ConfigurationOnly the one Message Match object is used. All HTTP Post messages are thus included in thisType.Release 3.6 1 - 21
  29. 29. Human Resources Web PortalMessage Filter ActionA Message Filter Action object determines what action to take when the Filter is invoked. Here isthe Message Filter Action object used by this monitor: Figure 1 - 17. Message Filter Action ConfigurationType: notify A log message will be posted (notification will be sent). The next field determines the severity level of the message. This field can also be set to “reject”, in which case the monitor will reject messages once the monitor’s threshold is reached. An unseen “Block Interval” field determines for how long messages will be rejected. This configuration does not take this drastic measure. However, if enough messages are posted by the monitor, this setting may be changed here.Log Priority: warning Log messages (notification) posted by this monitor will have the severity level of “warning”. Any log targets set to capture messages at or below the level of warning will capture posted notification messages.1 - 22 Release 3.6
  30. 30. Scenario A: Web ServicesDuration Monitor ObjectThe top level Duration Monitor object ties together the other three objects to create a singlecapability. Here is the configuration display for this example: Figure 1 - 18. Duration Monitor Main ConfigurationMessage Type: xycohr All messages of the type “xycohr” will be monitored. As shown above, this in effect means all HTTP Post messages.Measure: messages The duration monitored is that of each message - the amount of time it takes between initial receipt of the message from the client to the dispatch of the response. A monitor could be set to measure only requests (the time it takes to process the request), response (the time it takes to process the response), server (the time between dispatch of the message to the back end service to the receipt of the answer) and finally messages.Release 3.6 1 - 23
  31. 31. Human Resources Web PortalThresholds for this monitor are set on the Filter tab. The Filter tab configuration appears asfollows: Figure 1 - 19. Duration Monitor Filter ConfigurationName: xycohr This is the name of the threshold.Type: average This threshold is measuring the average duration of message processing time. This is the only available selection.Value: 5000 The number of milliseconds at which the threshold is reached.Action: xycohrsvc This is the Message Filter Action configured above. When the monitor discovers that the average processing time, end to end, of a message hits 5000 milliseconds, it will post a message to the logging system.1 - 24 Release 3.6
  32. 32. Scenario A: Web ServicesLoggingThis example employs a custom log target, which captures messages generated by the serviceshandling the XyCo HR web services traffic. Here is the configuration display of the custom LogTarget object Main page: Figure 1 - 20. Log Target Main ConfigurationType: File This log target captures messages into a file on the flash.Format: XML The log messages are stored in the file in XML format. Because this is true, it is possible to view the logs using the WebGUI interface.Timestamp: syslog All timestamps in the messages are formatted in the standard syslog format. This is what is commonly supported by off-device logging monitors.Release 3.6 1 - 25
  33. 33. Human Resources Web PortalLog Size (in kb): 500 The file will grow only to 500 kilobytes. As the entire flash filesystem is limited in size, this file should not be large.Filename: logtemp:///xycohr.log The log entries are captured in this file.Archive Mode: Rotate Once the log file reaches the limit in size, it is rotated. A copy of the current file is placed on the flash and a new file opened.Rotations: 3 When the archive method for a file is Rotate, this determines how many copies of the file are created before the last one is overwritten.Note that when a device is rebooted (as opposed to the firmware reloaded), all temporary files areerased. For this reason, log files are often moved off the device for storage. Here is an exampleconfiguration using FTP to move the log file off the device when it is time to begin a new file. Figure 1 - 21. Upload Log File ConfigurationObject FiltersLog targets capture messages by Object Filters and Event Subscriptions. Object filters determinewhat messages will be captured according to source object.1 - 26 Release 3.6
  34. 34. Scenario A: Web Services Figure 1 - 22. Log Target Object Filter ConfigurationOnly messages generated by the objects of the classes shown with the names shown are eligible forcapture.Event SubscriptionsEvent Subscrptions determine at what level of priority messages are captured. Here is theconfiguration display for this example: Figure 1 - 23. Log Target Event Subscription ConfigurationThis indicates that all messages of severity notice or higher will be captured. Above notice arewarning, error, critical, alert and emergency.Release 3.6 1 - 27
  35. 35. Human Resources Web PortalScenario B: An HTML Forms ServiceAfter the DataPower connection between the departmental application servers and the back endweb services endpoints was successfully deployed and run for some while, the CIO looked at thearchitecture and asked if were possible for the DataPower system to connect directly to end userbrowsers, which would submit a standard HTML Form to request service, thus eliminating theapplication server layer from the architecture. This would reduce costs and increase simplicity.Here is the resulting architecture: Web Service 1 SOAP Many Browsers HTML Web Service 2 DataPower SOAP Web Service 3 Figure 1 - 24. Browser-to-Service ArchitectureIt is entirely possible to implement this architecture using a DataPower system he was told. Showme, he said. Here is the HTML form supported by this service: Figure 1 - 25. End User HTML Form1 - 28 Release 3.6
  36. 36. Scenario B: An HTML Forms ServiceXML Firewall ServiceThe XML Firewall Service configuration page appears as shown here. Figure 1 - 26. Web Services Firewall ConfigurationThese are the field values.Firewall Name: HTTPForms The name of the firewall object. This name may appear in the Via: field of the HTTP headers returned during SOAP and XML web service transactions. It also appears in the log files.Firewall Type: Dynamic backend The selection Dynamic backend indicates that the servers to which the firewall will forward requests are determined dynamically by the firewall’s document processing policy. In this case the determination is accomplished through a Route action that in turn employs an XPath Routing Map.XML Manager: Default The default is left in place.Firewall Policy: XycoHRForms The custom policy built for this service, XycoHRServices, is selected. This policy is covered in detail below.Release 3.6 1 - 29
  37. 37. Human Resources Web PortalURL Rewrite Policy: None The default is left in place. The URLs sent by the clients are not altered in any way.Back EndSSL Client Crypto Profile: None The default is left in place. Communication with the back end servers will not employ SSL in this case.Response Type: SOAP The selection SOAP indicates that the back end servers will post SOAP documents in response to requests from the firewall service. The firewall service automatically validates the documents against the SOAP schemas now in use (SOAP 1.1, 1.2 and variants).Response Attachments: Strip The default value (strip) is left in place. Any attachments sent by the back end service will be stripped off before the message is handled by the firewall service.Front EndDevice Address: 0.0.0.0 The default value of 0.0.0.0 is used. The service will listen at the port indicated on all ethernet addresses configured for the current device.Device Port: 2075 The automatically assigned value of 2075 is used. This could be altered to any value not used by another service on the current device. All traffic bound for this service must use port number 2075. The SOAP HTTP URL resembles http://10.10.13.35:2075/services.SSL Server Crypto Profile: XycoHRWeb Communication with the front end clients will employ SSL in this case. The cryptographic profile XycoHRWeb will be used, which in turn identifies the cryptographic certificate and private keys used for SSL communications.Request Type: XML The selection XML indicates that the clients will not post SOAP-formatted documents to the firewall service. The service will initially expect XML- formatted documents.Request Attachments: Strip The default value (strip) is left in place. Any attachments sent by the clients will be stripped off before the message is handled by the firewall service.1 - 30 Release 3.6
  38. 38. Scenario B: An HTML Forms ServiceHere is the Advanced configuration page for this service: Figure 1 - 27. Advanced configuration pageAll defaults are left in place with the exception of the Message Duration Monitor. Here, thecustom configured Xycohr Duration Monitor is assigned to the service. Note that this reuses thesame Monitor as used for the Web Services implementation.Release 3.6 1 - 31
  39. 39. Human Resources Web PortalFirewall PolicyHere is the graphic representation of the firewall policy used for this implementation. Figure 1 - 28. XycoHRForms Firewall PolicyNote that this policy resembles that of the Web Services policy beginning with the Validate action.1 - 32 Release 3.6
  40. 40. Scenario B: An HTML Forms ServiceRulesRule #1: Request RuleHere is an examination of the components of Rule #1. Note that this is a Request rule; it will onlyhandle messages sent to the service by the client and will not handle messages sent by the serverback to the client.Match Rule: FormsA Match Rule examines the inbound message and determines whether or not the rule should be runagainst the message. In this case, the match rule examines the URL used by the client to determinea match. Here is the configuration display of the match rule maps. Figure 1 - 29. Forms Match Rule ConfigurationThe client must use the URL */forms or this rule will not be applied to the message. Note that theexpression * means “any substring of any characters.”Release 3.6 1 - 33
  41. 41. Human Resources Web PortalAction 1: Convert-httpThe first action of this policy converts the data posted by an HTTP Form into an XML document.The presence of this action in this rule and policy alerts the service to accept inbound submissionsthat are not necessarily XML documents. Here is the configuration display of this action. Figure 1 - 30. Convert-http Action ConfigurationThis is a very simple configuration. If a custom conversion of HTTP Input characters were neededor desired, that could be accomplished by configuring an Input Conversion object. Note that theOutput context is tmpvar1, which was entered by hand.Action 2: TransformThis tranform action serves to convert the XML created by the Convert-http action into somethingmore usable. Here is an example of the result of the Convert-http action:<?xml version="1.0" encoding="UTF-8" ?><request><url>/forms</url><base-url>/forms</base-url><args src="url" /><args src="body"><arg name="UserName">JBrown</arg><arg name="Password">lad;fj</arg><arg name="First_Name">Jack</arg><arg name="Last_Name">Brown</arg><arg name="Employee_ID">03498</arg><arg name="Department">Engineering</arg><arg name="Requested_Service">floatholiday</arg><arg name="Service_Date">05/10/05</arg></args></request>1 - 34 Release 3.6
  42. 42. Scenario B: An HTML Forms ServiceHere is the configuration page display for this action. Figure 1 - 31. Transform ConfigurationInput: tmpvar1 This is set to tmpvar1, the named context used by the preceeding action.Document Processing Instructions: Specified by rule This is set to use an XSLT file specified in this rule rather than any instructions contained within the XML message itself.Processing Control File: local:///ConvertForm.xsl This is set to local:///ConvertForm.xsl. This XSLT file was uploaded to the device and stored in the local: directory..Output: tmpvar2 This is set to tempvr2. This value was entered during configuration.Release 3.6 1 - 35
  43. 43. Human Resources Web PortalHere is the stylesheet used for this transform action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/> <xsl:template match="/"> <xsl:apply-templates select="/request/args"/> </xsl:template> <xsl:template match="request"> <xsl:copy-of select="."/> </xsl:template> <xsl:template match="args"> <xsl:if test="@src = body"> <xsl:element name="xycohr:request" namespace="http://xycohr.com/hrservices"> <xsl:for-each select="arg"> <xsl:element name="xycohr:{@name}" namespace="http://xycohr.com/hrservices"> <xsl:value-of select="."/> </xsl:element> </xsl:for-each> </xsl:element> </xsl:if> </xsl:template></xsl:stylesheet>Here is the result of the transform:<?xml version="1.0" encoding="UTF-8"?><xycohr:request xmlns:xycohr="http://xycohr.com/hrservices"> <xycohr:UserName>JBrown</xycohr:UserName> <xycohr:Password>lad;fj</xycohr:Password> <xycohr:First_Name>Joe</xycohr:First_Name> <xycohr:Last_Name>Brown</xycohr:Last_Name> <xycohr:Employee_ID>03498</xycohr:Employee_ID> <xycohr:Department>Engineering</xycohr:Department> <xycohr:Requested_Service>floatholiday</xycohr:Requested_Service> <xycohr:Service_Date>05/10/05</xycohr:Service_Date></xycohr:request>1 - 36 Release 3.6
  44. 44. Scenario B: An HTML Forms ServiceAction 3: ValidateThis action validates the transformed contents of the message against a custom schema. Thisinsures that the payload also contains the required elements and does not contain invalid elements.Here is the configuration of this action: Figure 1 - 32. Validate ConfigurationInput: tmpvar2 This is set to tmpvar2, the context containing the result of the transform.Schema Validation Method: Schema URL This is set to validate the document using a schema URL. A URL must be provided that identifies the location of the schema file to use.Schema URL: local:///Xycohr.xsd This is set to local:///Xycohr.xsd. The custom schema file has been uploaded to the device and placed in the local: directory.Output: tmpvar3 This is set to tmpvar2. The results of the validation will be placed in this context. If the input is valid, the context will contain the validated message. If an error occurs (the message fails to validate, for example), the context is empty. Any subsequent actions can access the results by using tmpvar3 as the input context.Release 3.6 1 - 37
  45. 45. Human Resources Web PortalHere is the schema file used for this action.<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xycohr="http://xycohr.com/hrservices"xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" target-Namespace="http://xycohr.com/hrservices" elementFormDefault="qualified"> <xs:element name="request" type="xycohr:hrrequest"/> <xs:complexType name="hrrequest"> <xs:sequence> <xs:element name="UserName" type="xs:string" minOccurs="0"/> <xs:element name="Password" type="xs:string" minOccurs="0"/> <xs:element name="First_Name" type="xs:string"/> <xs:element name="Last_Name" type="xs:string"/> <xs:element name="Employee_ID" type="xs:string"/> <xs:element name="Department" type="xs:string"/> <xs:element name="Requested_Service" type="xs:string"/> <xs:element name="Service_Date" type="xs:string"/> </xs:sequence> </xs:complexType></xs:schema>Action 4: FilterThis action filters the validated message for the presence of required values within the message. Iteither accepts or rejects the message. Here is the configuration display for this action: Figure 1 - 33. Filter ConfigurationInput: tmpvar3 This is set to tmpvar3, the named context used by the preceeding action.Processing Control File: local:///XycohrForms.xsl This is set to local:///XycohrForms.xsl. The custom XSLT file has been uploaded to the device and placed in the local: directory.Output: (blank) This is set to be automatically generated by the policy configuration page. Unlike a transform or a validate action, a filter action typically does not return1 - 38 Release 3.6
  46. 46. Scenario B: An HTML Forms Service a nodeset. It accepts or rejects the input for further processing by the next action in the rule.Here is the XSLT file used for this Filter action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" extension-element-prefixes="dp"xmlns:dp="http://www.datapower.com/extensions" exclude-result-prefixes="dp"> <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/> <xsl:template match="/"> <!--no SOAP envelope --> <xsl:apply-templates select="/*[local-name()=request]"/> </xsl:template> <xsl:template match="/*[local-name()=request]"> <xsl:variable name="errtext" select="Incomplete Input"/> <xsl:variable name="errtest"> <!-- dont allow blank fields; all are required --> <xsl:for-each select="./*"> <xsl:if test="string-length() = 0"> <xsl:value-of select="local-name()"/>: </xsl:if> </xsl:for-each> </xsl:variable> <xsl:choose> <!-- $errtest will only have content if some element is blank; if so reject the message --> <xsl:when test="$errtest != "> <dp:xreject reason="$errtext"/> <!-- put a message in the log file; $errtest contains the names of the offending elements --> <xsl:message dp:type="xmlfirewall" dp:priority="error"> <xsl:value-of select="$errtest"/> </xsl:message> </xsl:when> <xsl:otherwise> <!-- all is well --> <dp:accept/> </xsl:otherwise> </xsl:choose> </xsl:template></xsl:stylesheet>Release 3.6 1 - 39
  47. 47. Human Resources Web PortalAction 5: TransformThis action serves to transform the now validated and filtered payload into a fully compliant SOAPmessage, and to connect the last context that contained the possibly altered message to any actionsthat follow. Here is the configuration page display for this action. Figure 1 - 34. Transform ConfigurationInput: tmpvar3 This is set to tmpvar3, the named context used by the preceeding action.Document Processing Instructions: Specified by rule This is set to use an XSLT file specified in this rule rather than any instructions contained within the XML message itself.Processing Control File: local:///InsertWSSHeaders.xsl This is set to local:///InsertWSSHeaders.xsl. This custom XSLT file converts the payload into a SOAP-compliant message with WS-Security headers.Output: tmpvar4 This is set to tmpvar4. This was entered during configuration.1 - 40 Release 3.6
  48. 48. Scenario B: An HTML Forms ServiceHere is the XSLT file used for this action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/> <xsl:template match="/"> <S11:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/"> <S11:Header> <wsse:Security> <wsse:UsernameToken> <wsse:Username> <xsl:value-of select="/*[local-name()=request]/*[local-name()=UserName]"/> </wsse:Username> <wsse:Password> <xsl:value-of select="/*[local-name()=request]/*[local-name()=Password]"/> </wsse:Password> </wsse:UsernameToken> </wsse:Security> </S11:Header> <S11:Body> <xsl:element name="xycohr:request" namespace="http://xycohr.com/hrservices"> <xsl:for-each select="/*[local-name()=request]/*"> <xsl:if test="local-name() != UserName and local-name() != Password"> <xsl:copy-of select="."/> </xsl:if> </xsl:for-each> </xsl:element> </S11:Body> </S11:Envelope> </xsl:template></xsl:stylesheet>Here is the message after this transform completes successfully:<?xml version="1.0" encoding="UTF-8"?><S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <S11:Header> <wsse:Security> <wsse:UsernameToken> <wsse:Username>JBrown</wsse:Username> <wsse:Password>lad;fj</wsse:Password> </wsse:UsernameToken> </wsse:Security> </S11:Header> <S11:Body> <xycohr:request xmlns:xycohr="http://xycohr.com/hrservices"> <xycohr:First_Name>Joe</xycohr:First_Name> <xycohr:Last_Name>Brown</xycohr:Last_Name> <xycohr:Employee_ID>377389</xycohr:Employee_ID> <xycohr:Department>Engineering</xycohr:Department> <xycohr:Requested_Service>floatholiday</xycohr:Requested_Service> <xycohr:Service_Date>05/10/2005</xycohr:Service_Date> </xycohr:request> </S11:Body></S11:Envelope>Release 3.6 1 - 41
  49. 49. Human Resources Web PortalAction 6: RouteThis action dynamically routes the message to a target destination, which is, in this scenario, oneof three Web service endpoints. This action uses an XPath Routing Map object to determine theproper destination target. Figure 1 - 35. Route ConfigurationInput: tmpvar4 This is set to tmpvar4, the named context used by the preceeding action.Selection Method: Path Routing Map This is set to use an XPath Routing Map.XPath Routing Map: xycohr This is set to xycohr. This is the name of a configured XPath Routing Map object that uses XPath expressions to extract values from the message. Those values are then used to match the message with a destination target. The XPath Routing Map is explained below.Output: (Blank) This is set to blank. A Route action does not output a nodeset. Note that because it does not, it will be necessary to include one more action in the rule to connect the last context that contains the full message to the special OUTPUT context, which is what is sent out on the wire to the destination target.XPath Routing Map: xycohrAn XPath Routing Map associates an XPath expression with a destination URL. When the XPathexpression evaluates to true, the target destination for the message is set to the correspondingURL. These mappings for this implementation are shown in Figure X below.An XPath Routing Map object can also use Namespace Mappings to associate namespace prefixesin the XPath expression maps to namespace URIs. This shortens the length of the XPathexpressions while preserving namespace information. This example does not use namespacemapping.1 - 42 Release 3.6
  50. 50. Scenario B: An HTML Forms ServiceHere is the configuration display of this object. Figure 1 - 36. XPath Routing Map ConfigurationNote that the destinations are mapped according to the value of the Requested_Service node. Theseare mapped to endpoint operations at the destination server ports. If no match is found by thisRoute action using the above mappings, the object returns an error to the client. The next objectnever executes.Release 3.6 1 - 43
  51. 51. Human Resources Web PortalAction 7: TransformThis transform connects the last context containing the message to the next action, or to theOUTPUT context. This is necessary because the Route action does not return a nodeset whendoing its work. This is the final action of the rule; if this action executes at all, then the Route hassucceeded and all is clear for delivery to the back end service. Here is the configuration displayfor this object. Figure 1 - 37. Transform ConfigurationInput: tmpvar4 This is set to tmpvar4, the named output context used by the action preceeding the Route action.Processing Control File: store:///identity.xsl This is set to store:///identity.xsl. This stylesheet is supplied with the firmware.Output: OUTPUT This is set to OUTPUT, the special context that is delivered to the wire. As this is the last action of the rule, whatever is in this context is sent to the destination determined by the Route action. The message goes off to the appropriate back end Web services endpoint.When a submitted message succeeds in transversing the firewall processing policy, the messageappears exactly as it did after the last transform completed. This message is identical in form tothose submitted by the Web Services implementation of this service.1 - 44 Release 3.6
  52. 52. Scenario B: An HTML Forms ServiceRule #2: Response RuleRule #2 in this policy is a Response rule. It handles messages returned to the service from the backend servers. Note that the Match rule is the same as the Request; the server must reflect the sameURI in its response as the client.Implied Action 0: ValidateThe firewall automatically validates the response message against the SOAP schemas, to insurethat no message that does not conform to the SOAP schemas will be sent back to the client. ThisSOAP schema filtering is implied and no action needs to be created for it. However, the presenceof this valildation action can cause response messages to be rejected by the firewall before any ofthe actions visible in the Firewall Policy have run.Action 1: TransformThis action is present to transform the response from the server prior to delivering it to therequesting client. Because the requesting client is a browser, this rule must transform the SOAPresponse from the back end server into HTML. Note that because the service Response Type is setto SOAP that the service itself validates the server’s response against the SOAP schemas.Here is the configuration display for this action: Figure 1 - 38. Response Transform ConfigurationInput: INPUT This is set to INPUT, the special input context containing the original message from the back end server.Processing Control File: local:///xycoformresponse.xsl This is set to local:///xycoformresponse.xsl. This custom stylesheet has been uploaded to the device.Release 3.6 1 - 45
  53. 53. Human Resources Web PortalOutput: OUTPUT This is set to OUTPUT, the special context that is delivered to the wire. As this is the last action of the rule, whatever is in this context is sent back to the client as the response from the service.Here is the XSLT stylesheet used for this action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig"> <xsl:output method="html" version="1.0"/> <xsl:template match="/"> <html> <head> <title>As Requested</title> </head> <body> <h2>XyCo HR Instant Benefits</h2> <xsl:apply-templates select="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=response]"/> <!-- <xsl:value-of select="date:date-time()"/> --> <p> <font size="2">Transaction ID:<xsl:value-of select="dp:variable(var://service/transaction-id)"/> </font> </p> </body> </html> </xsl:template> <xsl:template match="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=response]"> <table cellspacing="3"> <xsl:for-each select="./*"> <xsl:choose> <xsl:when test="local-name() != result"> <tr> <td align="right"> <b> <xsl:value-of select="local-name()"/>: </b> </td> <td align="left"> <xsl:value-of select="."/> </td> </tr> </xsl:when> <xsl:otherwise> <xsl:apply-templates select="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=response]/*[local-name()=result]"/> </xsl:otherwise> </xsl:choose> </xsl:for-each> </table> </xsl:template> <xsl:template match="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=response]/*[local-name()=result]"> <xsl:for-each select="./*"> <tr> <td align="right" valign="top"> <b><xsl:value-of select="local-name()"/>:</b> </td>1 - 46 Release 3.6
  54. 54. Scenario B: An HTML Forms Service <td align="left"> <xsl:value-of select="."/> </td> </tr> </xsl:for-each> </xsl:template></xsl:stylesheet>Here is an example of the completed round-trip response to the original request: Figure 1 - 39. Response in BrowserRelease 3.6 1 - 47

×