Your SlideShare is downloading. ×
Xi 3[1].6.0-example configs
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Xi 3[1].6.0-example configs

245
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
245
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. WebSphere DataPower XML Integration Appliance XI50 ®Release 3.6.0Example Configurations
  • 2. WebSphere DataPower IBM WebSphereDataPower XML Integration Appliance XI50 Example Configurations Release 3.6.0
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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&#58;request" namespace="http://xycohr.com/hrservices"> <xsl:for-each select="arg"> <xsl:element name="xycohr&#58;{@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. 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. 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. 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. 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. 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&#58;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. 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. 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. 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. 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. 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. 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
  • 55. 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 an HTML file that includes a traceable transaction number. Because the client is abrowser, this transform is required.Here is the configuration display for this action: Figure 1 - 40. Error Transform ConfigurationInput: NULL This is set to NULL, a special input context containing nothing. This error response will not include any device-generated message fragment.Processing Control File: local:///xycoformerror.xsl This is set to local:///xycoformerror.xsl. This custom stylesheet has been uploaded to the device.Output: OUTPUT 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 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"1 - 48 Release 3.6
  • 56. Scenario B: An HTML Forms Service exclude-result-prefixes="dp dpconfig"> <xsl:output method="html" version="1.0"/> <xsl:template match="/"> <html> <head> <title>As Requested</title> </head> <body> <h2>XyCo HR Instant Benefits</h2> <p>Please submit a complete form.</p> <p>If the form you submitted is completely filled in, please report this transaction ID to Network Operations.</p> <p>Thank you.</p> <p> <font size="2">Transaction ID:<xsl:value-of select="dp:variable(var://service/transaction-id)"/> </font> </p> </body> </html> </xsl:template></xsl:stylesheet>Action 2: SetvarWhenever the DataPower device encounters an error, it returns an HTTP 500 to the calling entity.The HTTP 500 status code prevents the browser from displaying the error message. This Setvaraction changes the 500 to a 200.Here is the configuration display for this action: Figure 1 - 41. Setvar ConfigurationContext: OUTPUT This is the special context sent on the wire.Variable Name: var://service/error-protocol-response This is a special service variable that can be changed. This controls the HTTP status code sent on the wire.Variable Assignment: 200 The code is reset to 200. The browser will now display the error message.Release 3.6 1 - 49
  • 57. Human Resources Web PortalSSL Server Crypto ProfileIn this scenario, the communication channels between the DataPower service and the requestingclient are not guaranteed to be encrypted or secure in any way. For this reason, thisimplementation uses SSL to encrypt communications between the browser client and theDataPower system. The firewall configuration page shows the setting to use SSLcommunications. Figure 1 - 42. SSL Server Crypto Profile settingHere is the configuration of the Crypto Profile: Figure 1 - 43. Crypto Profile ConfigurationIdentification Credentials: XycoHRWeb These credentials identify the private cryptographic key and public cryptographic certificate used by this service to identify itself to clients. A browser client connecting to this service will be given a copy of the certificate identified by these credentials for use in SSL communications.Validation Credentials: None This setting indicates that the service will not request a certificate of authority to identify the requesting clients.All other inputs are set to the default, requiring no configuration action. With SSL enabled, thebrowsers use HTTPS rather than HTTP to communicate with the DataPower system.1 - 50 Release 3.6
  • 58. Scenario B: An HTML Forms ServiceCrypto Identification CredentialsThe SSL Crypto Profile relies upon the Crypto Identification Credential XycoHRWeb. Here is theconfiguration of the Identification Credential object: Figure 1 - 44. Crypto Identification Credentials ConfigurationThe Key and Certificate objects identify the private key and public certificate used for securecommunications over an SSL channel. Both of those objects were generated automatically on theDataPower system using the Cryptographic Key tool. Those objects can also use private keys andcertificates uploaded to the device.Crypto KeyHere is the configuration of the Key object: Figure 1 - 45. Crypto Key ConfigurationRelease 3.6 1 - 51
  • 59. Human Resources Web PortalThe object points at a key file stored in the encrypted cert: directory on the local flash filesystem.Files placed in the cert: directory can be read by the system, but cannot be copied or moved in anyway.Crypto CertificateHere is the configuration of the Certificate object: Figure 1 - 46. Crypto Certificate ConfigurationThis object points to a certificate file stored on the local flash filesystem, in the encrypted cert:directory. Files placed in the cert: directory can be read by the system, but cannot be copied ormoved in any way.1 - 52 Release 3.6
  • 60. Scenario C: Multi-Protocol, Single Port ServiceScenario C: Multi-Protocol, Single Port ServiceThe CIO was duly impressed with the flexibility and capability of the DataPower system. But theCTO now saw an opportunity to combine the two services into one well-known address and portand asked if the DataPower system could take in either SOAP or HTML Forms traffic on the sameport and do the right thing. This would simplify the change control process. Yes, of course, he wastold, DataPower can do that.In this scenario, the DataPower firewall can accept requests directly from an end user browser,which posts HTML forms, or from an application server, which posts SOAP documents. TheHTML form posting is converted into a SOAP document. The request is schema validated,filtered for complete information, and then dynamically routed to the appropriate back end serverfor processing. The response, whether success or error, is returned to the calling entity in theappropriate form. The browser receives an HTML page and the application server receives aSOAP response. Here is an illustration of the architecture involved. Server 1 HTML Many Browsers SOAP Server 2 DataPower SOAP SOAP Server 3 Many App Servers Figure 1 - 47. Multi-portocol architectureThis configuration is explained below.Release 3.6 1 - 53
  • 61. Human Resources Web PortalXML Firewall ServiceThe XML Firewall Service configuration page appears as shown here. Figure 1 - 48. SOAP/HTTP Firewall ConfigurationThese are the field values.Firewall Name: XycoMultiSvc 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: XycoHRWeb The custom policy built for this service, XycoHRWeb, is selected. This policy is covered in detail below.1 - 54 Release 3.6
  • 62. Scenario C: Multi-Protocol, Single Port ServiceURL 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: 2085 The value of 2085 is used. This could be altered to any value not used by another service on the current device. All traffic bound for this service must use port number 2085. The SOAP HTTP URL resembles http:// 10.10.13.35:2085/services or http://10.10.13.35:2085/forms.SSL Server Crypto Profile: XycoHRWeb Communication with the front end clients will employ SSL in this case, using the same certificates and keys as the HTML Forms service used.Request Type: XML The selection XML indicates that the service is expecting inbound messages in XML format. The SOAP-formatted messages sent by application servers are valid XML. However, the service will not automatically validate the inbound message against the SOAP schemas. In this scenario, that validation is performed in the Policy rule, rather than automatically by the service. The HTML forms sent by the browser clients will be accepted by this service, even though they are not well-formed XML, because of the convert-http action included in the Policy rules used.Request Attachments: Strip The default value (strip) is left in place. Any attachments sent by the clients will be stripped off before the message is handled by the firewall service.Release 3.6 1 - 55
  • 63. Human Resources Web PortalHere is the Advanced configuration page for this service: Figure 1 - 49. 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.1 - 56 Release 3.6
  • 64. Scenario C: Multi-Protocol, Single Port ServiceFirewall PolicyHere is the graphic representation of the firewall policy used for this implementation. Figure 1 - 50. XycoHRWeb Firewall PolicyThis policy employs 6 rules to handle the two possible kinds of submissions. Three rules handleSOAP - request, response and error - all identified by the services match rule. Three rules handleHTML forms - request, response and error - all identified by the HTTP Forms match rule.Here is an overview of these rules.Rule #1 services Request Rule This rule matches to all submissions posted to the URI */services. The Validate action uses the same schema definitions as the firewall uses when it does automatic SOAP schema validation. The subsequent Filter action verifies that values are provided for all fields and, through the use of DataPower extension functions, validates the custom payload portion (within the SOAP Body tags) of the message. If both of these steps succeed, the message is routed dynamically according to the service requested.Rule #2 HTML Forms Request Rule This rule matches submissions with the URI */forms. It immediately converts the HTML forms data posted to the service into XML. The next Transform action converts this XML into a well-formed SOAP document, just as would be received from an application server. The final action Calls the first rule to complete validation, filtering and routing.Release 3.6 1 - 57
  • 65. Human Resources Web PortalRule #3 services Response Rule This rule handles responses from the server bound for an application server client that expects SOAP in response. It is an identity transform that adds a transaction id to the response.Rule #4 HTML Forms Response Rule This rule handles responses from the server bound for a browser, that cannot handle SOAP. It converts the SOAP response into HTML for the browser’s consumption, adding a transaction id in the process.Rule #5 services Error Rule This rule handles all errors bound for an application server expecting SOAP.Rule #6 HTML Forms Error Rule This rule handles all errors bound for a browser, expecting HTML.RulesRule #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. This rule is designed to handle Web Services submissions - that is, XML-formatted documents, and not HTTP Forms POST submissions.Match Rule: ServicesA Match Rule examines the inbound message and determines whether or not the rule should be 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 - 51. 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.”1 - 58 Release 3.6
  • 66. Scenario C: Multi-Protocol, Single Port ServiceAction 1: ValidateWhen the firewall Request Type is set to SOAP, the firewall automatically validates the inboundmessage against the SOAP schemas, to insure that no message that does not conform to the SOAPschemas will be sent to the back end web service endpoints. However, this firewall uses theRequest Type XML, to support submissions from browsers (handled in Rule #2 below). To ensurethat inbound messages sent to the Matching URL are valid SOAP, it is necessary to validate theSOAP conformance with an action.The first validates the contents of the SOAP Body element against the SOAP schemas usedinternally by the firewall. This replaces the automatic behavior. Here is the configuration of thisaction: Figure 1 - 52. 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: store:///schemas/soap-envelope.xsd This is set to store:///schemas/soap-envelope.xsd. This is the SOAP schema used by the firewall to validate SOAP messages for conformance.Output: tmpvar1 This is set to tmpvar1. The results of the validation will be placed in this context. If the input is valid, the context will contain the validated message. If an error occurs (the message fails to validate, for example), the context is empty. Any subsequent actions can access the results by using tempvar1 as the input context.Release 3.6 1 - 59
  • 67. Human Resources Web PortalAction 2: FilterThis action filters the validated message for the presence of required values within the message. Italso submits that portion of the message within the SOAP:Body tags for validation against thecustom schema used for the particular web service. This is done by using Extension Functionswithin the stylesheet itself. It either accepts or rejects the message. Here is the configurationdisplay for this action: Figure 1 - 53. Filter ConfigurationInput: tmpvar1 This is set to tmpvar1, the named context used by the preceeding action. Note that this could have been set to INPUT since this action would not execute if the validation before it failed. However, validation can sometimes change the message format, thus this action uses the result of the validation.Processing Control File: local:///Xycohr3.xsl This is set to local:///Xycohr3.xsl. The custom XSLT file has been uploaded to the device and placed in the local: directory.Output: (Blank) This is set to be automatically generated by the policy configuration page. Unlike a transform or a validate action, a filter action typically does not return a nodeset. It accepts or rejects the input for further processing by the next action in the rule.Here is the XSLT file used for this Filter action:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" extension-element-prefixes="dp"xmlns:dp="http://www.datapower.com/extensions" exclude-result-prefixes="dp"> <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/> <xsl:template match="/"> <xsl:apply-templates select="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=request]"/> </xsl:template> <xsl:template match="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=request]"> <xsl:variable name="errtext" select="Incomplete Input"/> <xsl:variable name="errtest"> <!-- dont allow blank fields; all are required --> <xsl:for-each select="./*"> <xsl:if test="string-length() = 0">1 - 60 Release 3.6
  • 68. Scenario C: Multi-Protocol, Single Port Service <xsl:value-of select="local-name()"/>: </xsl:if> </xsl:for-each> </xsl:variable> <xsl:choose> <xsl:when test="$errtest != "> <dp:xreject reason="$errtext"/> <xsl:message dp:type="xmlfirewall" dp:priority="error"> <xsl:value-of select="$errtest"/> </xsl:message> </xsl:when> <xsl:otherwise> <dp:accept/> <!-- Now validate the schema --> <xsl:variable name="payload" select="/*[local-name()=Envelope]/*[local-name()=Body]/*"/> <dp:set-variable name="var://context/tempvar3/payload" value="$payload"/> <xsl:variable name="validation" select="dp:schema-validate(local:///Xycohr.xsd, $payload)"/> <dp:set-variable name="var://context/tempvar3/postval" value="$validation"/> <xsl:variable name="results"> <xsl:value-of select="$validation"/> </xsl:variable> <xsl:if test="$results = "> <dp:reject>Failed validation</dp:reject> <xsl:message dp:type="xmlfirewall" dp:priority="error">Failed Payload Validation </xsl:message> </xsl:if> </xsl:otherwise> </xsl:choose> </xsl:template></xsl:stylesheet>Action 3: 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 - 54. Route ConfigurationRelease 3.6 1 - 61
  • 69. Human Resources Web PortalInput: tmpvar1 This is set to tmpvar1, the named 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.Here is the configuration display of this object. Figure 1 - 55. XPath Routing Map Configuration1 - 62 Release 3.6
  • 70. Scenario C: Multi-Protocol, Single Port ServiceNote 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: 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 - 56. Transform ConfigurationInput: tmpvar1 This is set to tmpvar1, 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.Release 3.6 1 - 63
  • 71. Human Resources Web PortalRule #2: Request RuleHere is an examination of the components of Rule #2. 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 - 57. 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.”Action 1: Convert-httpThe first action of this policy converts the data posted by an HTTP Form into an XML document.The presence of this action in this rule and policy alerts the service to accept inbound submissionsthat are not necessarily XML documents. Here is the configuration display of this action. Figure 1 - 58. Convert-http Action Configuration1 - 64 Release 3.6
  • 72. Scenario C: Multi-Protocol, Single Port ServiceThis 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 1: TransformThis tranform action serves to convert the XML created by the Convert-http action into a fullycompliant SOAP document suitable for submission to Rule #1.Here is the configuration page display for this action. Figure 1 - 59. 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:///InsertWSSHeader2.xsl This is set to local:///InsertWSSHeader2.xsl. This XSLT file was uploaded to the device and stored in the local: directory..Output: tmpvar2 This is set to tempvr2. This value was entered during configuration.Release 3.6 1 - 65
  • 73. 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" 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="/"> <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:if test="/request/args/arg/@name=UserName"> <xsl:choose> <xsl:when test="/request/args/arg[@name=UserName] = "> <dp:reject>No UserName</dp:reject> </xsl:when> <xsl:otherwise> <xsl:value-of select="/request/args/arg[@name=UserName]"/> </xsl:otherwise> </xsl:choose> </xsl:if> </wsse:Username> <wsse:Password> <xsl:if test="/request/args/arg/@name=Password"> <xsl:choose> <xsl:when test="/request/args/arg[@name=Password] = "> <dp:reject>No Password</dp:reject> </xsl:when> <xsl:otherwise> <xsl:value-of select="/request/args/arg[@name=Password]"/> </xsl:otherwise> </xsl:choose> </xsl:if> </wsse:Password> </wsse:UsernameToken> </wsse:Security> </S11:Header> <S11:Body> <xsl:apply-templates select="/request/args"/> </S11:Body> </S11:Envelope> </xsl:template> <xsl:template match="request"> <xsl:copy-of select="."/> </xsl:template> <xsl:template match="args"> <xsl:if test="@src = body"> <xsl:element name="xycohr&#58;request" namespace="http://xycohr.com/hrservices"> <xsl:for-each select="arg"> <xsl:if test="@name != UserName and @name != Password"> <xsl:element name="xycohr&#58;{@name}" namespace="http://xycohr.com/hrservices"> <xsl:value-of select="."/> </xsl:element> </xsl:if> </xsl:for-each> </xsl:element> </xsl:if>1 - 66 Release 3.6
  • 74. Scenario C: Multi-Protocol, Single Port Service </xsl:template></xsl:stylesheet>Action 3: CallThis action calls Rule #1 to complete the full processing of the submission from the browser.Since the rest of the validation, filtering and routing is identical to that of a SOAP request, andsince the transform in the previous step created a fully compliant SOAP request, it is now possibleto eliminate the double work by simply calling Rule #1. The Call action then sends the results ofexecuting the actions in Rule #1 to the back end service, preserving the URI.Here is the configuration display for this action: Figure 1 - 60. Call Action ConfigurationInput: tmpvar2 This is set to tmpvar2, the named context used by the preceeding action.Processing Rule: XycoHRWeb_Rule_0 This is set to XycoHRWeb_Rule_0. This is the name stored in the system for Rule #1.Output: OUTPUT This is set to OUTPUT. The result of the Call will be sent directly to the back end server.Release 3.6 1 - 67
  • 75. Human Resources Web PortalBoth the Input and the Output to this rule should resemble the following:<?xml version="1.0" encoding="UTF-8"?><S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <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>Rules 3 to 6The remaining rules are identical to the Response and Error rules used for the Scenario A WebServices and Scenario B HTML Forms implementations. For full explanations, refer to thosesections of this chapter.1 - 68 Release 3.6
  • 76. Scenario C: Multi-Protocol, Single Port ServiceRelease 3.6 1 - 69
  • 77. Human Resources Web Portal1 - 70 Release 3.6
  • 78. Chapter 2 Bank Checking Web ServiceThis example configuration implements a simple bank checking service. Requests arrive from anynumber of other hosts that offer the consumer the checking service. The SOAP request for serviceis formatted according to a published schema (available from the WSDL for the service; refer tothe end of this chapter) and includes a signed Security Assertion Markup Language (SAML)Attribute Assertion. The presence of this Assertion indicates that the remote host has contacted aSAML Authority prior to sending the request to the banking service central servers. This assertionis used for authentication and authorization.Here is an illustration of the architecture involved. Endpoint 1 Endpoint 2 DataPower SAML SSL Authority Endpoint 3 SOAP SOAP Many App ServersAll traffic between the DataPower device and the application servers travels over SSL. As definedin the WSDL for the service, requests may be one of the following: • Plain XML text • Field level Encrypted XML text • Field Level Encrypted and Signed XML textThe DataPower system performs the following tasks on requests: • Verifies Signatures (if signed) • Decrypts Encrypted Fields (if encrypted) • Validates Request Against Schema 2-1
  • 79. Bank Checking Web Service • Filters Request Data • Authenticates and Authorizes Request (using SAML) • Forwards to EndpointThe DataPower box performs the following tasks on the response from the server: • Vaildates Response Format • Encrypts Response Message (if request was encrypted) • Signs Response Message (if request was signed)The traffic is monitored for service threats. All errors are logged in a special log target built forthis service.2-2 Release 3.6
  • 80. XML FirewallXML FirewallThe XML Firewall Service configuration page appears as shown here. Figure 2 - 1. Web Services Firewall ConfigurationThese are the field values.Firewall Name: SomeBankCheckService 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: Static backend The firewall forwards all requests to a single back end server IP address and Port.XML Manager: Default The default is left in place.Release 3.6 2-3
  • 81. Bank Checking Web ServiceFirewall Policy: SomeBankCheckService The custom policy built for this service, SomeBankCheckService, is selected. This policy is covered in detail below.URL Rewrite Policy: None The default is left in place. The URLs sent by the clients are not altered in any way.Back EndSSL Client Crypto Profile: None The default is left in place. Communication with the back end servers will not employ SSL in this case.Response Type: 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: 2061 The automatically assigned value of 2061 is used. This could be altered to any value not used by another service on the current device. All traffic bound for this service must use port number 2061. The SOAP HTTP URL resembles http://10.10.13.35:2061/SomeBank/services/checking.SSL Server Crypto Profile: SomeBank Communication with the front end clients will employ SSL. The SomeBank Crypto Profile defines the cryptographic keys and certificates used for this purpose.Request Type: SOAP 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.2-4 Release 3.6
  • 82. XML FirewallHere is the Advanced configuration page for this service: Figure 2 - 2. Advanced configuration pageThe XML Threat Protection wizard has added three Count monitors and one Duration monitor tothis service. The purpose of these monitors is more easily seen on the Threat Protection page.Release 3.6 2-5
  • 83. Bank Checking Web ServiceHere is the excerpted Threat Protection Page. Figure 2 - 3. Threat Protection page (top) Figure 2 - 4. Threat Protection page (bottom)2-6 Release 3.6
  • 84. Firewall PolicyFirewall PolicyHere is the graphic representation of the firewall policy used for this implementation. Figure 2 - 5. SomeBankCheckServices 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.Release 3.6 2-7
  • 85. Bank Checking Web ServiceRulesOverviewHere is an overview of the rules used in this policy.Rule 1 Request Rule Matching */SomeBank/services/checking This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Validate against the published schema for the service 2 Filter requests for valid values 3 Filter requests for SQL Injection threats 4 Authenticate and Authorize request 5 Send to back end serviceRule 2 Request Rule Matching */SomeBank/services/encrypted This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Decrypt encrypted fields 2 Pass to Rule 1 for standard processingRule 3 Request Rule Matching */SomeBank/services/signed This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Verify signature 2 Pass to Rule 2 for decryptionRule 4 Response Rule Matching */SomeBank/services/signed This rule runs when the client sends the matching URL. This rule operates on the response from the server. The rule performs the following actions: 1 Validate server response against schema 2 Encrypt entire message body 3 Sign response messageRule 5 Response Rule Matching */SomeBank/services/encrypted This rule runs when the client sends the matching URL. This rule operates on the response from the server. The rule performs the following actions: 1 Validate server response against schema 2 Encrypt entire message bodyRule 6 Response Rule Matching */SomeBank/services/checking This rule runs when the client sends the matching URL. This rule operates on the response from the server. The rule performs the following actions: 1 Validate server response against schema2-8 Release 3.6
  • 86. RulesRule #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.This is the core processing rule of the policy. All messages must pass through this set ofvalidations, filter, and authentication/authorization steps.Match Rule: CheckingA 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 2 - 6. Checking Match Rule ConfigurationThe client must use the URL */SomeBank/services/checking or this rule will not be applied to themessage. Note that the expression * means “any substring of any characters.”Implied Action 0: ValidateThe firewall automatically validates the inbound message against the SOAP schemas, to 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.It is possible, however, for the firewall to reject a message before any of the actions in theconfigured policy run due to this validation.Release 3.6 2-9
  • 87. Bank Checking Web ServiceAction 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 2 - 7. 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:///SomeBankCheckService.xsd This is set to local:///SomeBankCheckService.xsd. The custom schema file has been uploaded to the device and placed in the local: directory.Output: tempvar1 This is set to tempvar1. If the input is valid, the context will contain the validated message. If an error occurs (the message fails to validate, for example), the context is empty. Any subsequent actions can access the results by using tempvar1 as the input context.2 - 10 Release 3.6
  • 88. RulesHere is the schema file used for this action.<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:bank="http://somebank.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://somebank.com"elementFormDefault="qualified"> <xs:element name="CheckRequestElement" type="bank:CheckRequest"/> <xs:complexType name="CheckRequest"> <xs:sequence> <xs:element name="PayorAccountName" type="xs:string"/> <xs:element name="PayorAccountID" type="xs:string"/> <xs:element name="CheckType" type="xs:string"/> <xs:element name="Payee" type="xs:string"/> <xs:element name="PayeeAddr" type="xs:string" minOccurs="0"/> <xs:element name="PayeeRouteNo" type="xs:string" minOccurs="0"/> <xs:element name="Amount" type="xs:float"/> <xs:any namespace="##any" processContents="skip" minOccurs="0"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="skip"/> </xs:complexType> <xs:element name="CheckResponseElement" type="bank:CheckResponse"/> <xs:complexType name="CheckResponse"> <xs:sequence> <xs:element name="TransactionNum" type="xs:int"/> <xs:element name="CheckNum" type="xs:int"/> <xs:element name="CheckType" type="xs:string"/> <xs:element name="PayorAccountID" type="xs:string"/> <xs:element name="Payee" type="xs:string"/> <xs:element name="Amount" type="xs:float"/> <xs:any namespace="##any" processContents="skip" minOccurs="0"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="skip"/> </xs:complexType> <xs:element name="CheckRequestErrorElement" type="bank:CheckRequestError"/> <xs:complexType name="CheckRequestError"> <xs:sequence> <xs:element name="TransactionNum" type="xs:int"/> <xs:element name="ErrorNum" type="xs:int"/> <xs:element name="CheckType" type="xs:string"/> <xs:element name="PayorAccountID" type="xs:string"/> <xs:element name="Payee" type="xs:string"/> <xs:element name="ErrorMessage" type="xs:string"/> </xs:sequence> </xs:complexType></xs:schema>Release 3.6 2 - 11
  • 89. Bank Checking Web ServiceAction 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 2 - 8. Filter ConfigurationInput: tempvar1 This is set to tempvar1, the named context used by the preceeding action. Note that this could have been set to INPUT since this action would not execute if the validation before it failed. However, validation can sometimes change the message format, thus this action uses the result of the validation.Processing Control File: local:///SomeBankCheckService.xsl This is set to local:///SomeBankCheckService.xsl. The custom XSLT file has been uploaded to the device and placed in the local: directory.Output: (blank) 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 extension-element-prefixes="dp" version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP12="http://www.w3.org/2003/05/soap-envelope"xmlns:dp="http://www.datapower.com/extensions" xmlns:bank="http://somebank.com"> <xsl:template name="valid-operation"> <xsl:param name="op"/> <xsl:choose> <xsl:when test="$op=CheckRequestElement"> <xsl:choose> <xsl:when test="string-length(/SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:PayorAccoun-2 - 12 Release 3.6
  • 90. RulestID) != 0 and length(/SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:Payee) != 0 and /SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:Amount > 10"> <!-- <dp:accept/> --> <xsl:copy-of select="/"/> </xsl:when> <xsl:otherwise> <xsl:variable name="errtext" select="Invalid Input"/> <dp:xreject reason="$errtext"/> <xsl:message> <xsl:value-of select="$errtext"/> </xsl:message> </xsl:otherwise> </xsl:choose> <!-- <dp:accept/> <xsl:copy-of select="/"/> --> </xsl:when> <xsl:when test="$op=CheckResponseElement"> <dp:accept/> </xsl:when> <xsl:otherwise> <xsl:variable name="errtext" select="concat(Rejected illegal operation , $op)"/> <dp:xreject reason="$errtext"/> <xsl:message> <xsl:value-of select="$errtext"/> </xsl:message> </xsl:otherwise> </xsl:choose> </xsl:template> <xsl:template match="/"> <xsl:choose> <xsl:when test="dp:responding()"> <dp:accept/> </xsl:when> <xsl:otherwise> <xsl:choose> <xsl:when test="count(/SOAP:Envelope) > 0"> <xsl:call-template name="valid-operation"> <xsl:with-param name="op" select="local-name(/SOAP:Envelope/SOAP:Body/*)"/> </xsl:call-template> </xsl:when> <xsl:when test="count(/SOAP12:Envelope) > 0"> <xsl:call-template name="valid-operation"> <xsl:with-param name="op" select="local-name(/SOAP12:Envelope/SOAP12:Body/*)"/> </xsl:call-template> </xsl:when> <xsl:otherwise> <xsl:call-template name="valid-operation"> <xsl:with-param name="op" select="local-name(/*)"/> </xsl:call-template> </xsl:otherwise> </xsl:choose> </xsl:otherwise> </xsl:choose> </xsl:template></xsl:stylesheet>Release 3.6 2 - 13
  • 91. Bank Checking Web ServiceAction 3: FilterThis action filters the validated message for SQL Injection attacks. It either accepts or rejects themessage. Here is the configuration display for this action: Figure 2 - 9. Filter ConfigurationInput: tempvar1 This is set to tempvar1, the named context used by the preceeding action. Note that this could have been set to INPUT since this action would not execute if the validation before it failed. However, validation can sometimes change the message format, thus this action uses the result of the validation.Processing Control File: store:///Sql_Injection_Filter.xsl This is set to store:///Sql_Injection_Filter.xsl. This is the standard SQL Injection Filter stylesheet supplied with the device.Output: (blank) 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.The stylesheet and SQL Injection Threat pattern file used for this filter can be found in the store:directory of the device. Note that the pattern file can be modified to include new or custominjection threats.2 - 14 Release 3.6
  • 92. RulesAction 4: AAAThis action authorizes and authenticates the entity (person) requesting checking services. AnAAA Action simply identifies an AAA Policy that is applied to the incoming message. Here is theconfiguration of the action: Figure 2 - 10. AAA Action ConfigurationInput: tempvar1 This is set to tempvar1, the named context used by the preceeding action. Note that this could have been set to INPUT since this action would not execute if the validation before it failed. However, validation can sometimes change the message format, thus this action uses the result of the validation.AAA Policy: SAML_Attr This is set to the AAA Policy named SAML_Attr. The Policy contains the business logic of the access and authorization policy. it is covered in detail below.Output: tempvar4 This is set to be automatically generated by the policy configuration page. If the AAA action succeeds (the request is authenticated and authorized), this context will contain the message.Release 3.6 2 - 15
  • 93. Bank Checking Web ServiceAAA Policy: SAML-AttrExtract IdentityThis policy obtains the identity of the requestor from a SAML Attribute Assertion contained in theSOAP header of the request message. Here is an excerpted example request message SOAPheader. The fields used by the AAA Policy are highlighted in bold.<soapenv:Header> <saml:Assertion AssertionID="Ide8d5cf8c-84c5-4fb3-81cf-8e2999dc6dc0" IssueInstant="2005-05-05T19:47:19Z"MajorVersion="1" MinorVersion="1" Issuer="BankConsortium"> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier>CN=Bob</saml:NameIdentifier> </saml:Subject> <saml:Attribute AttributeName="CheckingServices" AttributeNamespace="http://www.some-bank.com"> <saml:AttributeValue>Query</saml:AttributeValue> <saml:AttributeValue>Request</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> ... <SignatureValue>ePZifp/YHA3yrEZvUMLc+0U0cVQXgqng6GRrUyxaYLqhkMEHR2v35O82vy9wEUI/xE7M1WLaKHzU3qj1J45HK02EEqNodDMtLXM5YJy51lIcB+ACacT+OcyGUvfd66oEjzUPpqrKevZoj2rIO9V9x34HXNGdNgRasaZECaiDlM=</SignatureValue> ... </saml:Assertion> </soapenv:Header>Here is the policy screen showing the Extract Identity method selected: Figure 2 - 11. Extract Identity from SAML Assertion2 - 16 Release 3.6
  • 94. RulesThis step uses the value of the NameIdentifier element (in this case, CN=Bob)shown in the examplemessage above.AuthenticateThe policy considers the identity authenticated if the SAML signature is valid. Here is the AAAPolicy configuration screen where this is selected: Figure 2 - 12. Authentication MethodExtract ResourceThe policy uses the top level element of the SOAP Body element to extract the requested resource.Here is an example message SOAP Body: <soapenv:Body> <bank:CheckRequestElement xmlns:bank="http://somebank.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <bank:PayorAccountName>Cartoon Studios</bank:PayorAccountName> <bank:PayorAccountID>8458jf8757275234</bank:PayorAccountID> <bank:CheckType>P</bank:CheckType> <bank:Payee>Elmer Fudd</bank:Payee> <bank:PayeeAddr>124 East Sunset Drive; Sunset, AL 64846</bank:PayeeAddr> <bank:PayeeRouteNo>03849032874908</bank:PayeeRouteNo> <bank:Amount>999.00</bank:Amount> </bank:CheckRequestElement> </soapenv:Body>Release 3.6 2 - 17
  • 95. Bank Checking Web ServiceHere is the configuration screen establishing this policy. Figure 2 - 13. Requested Resource configurationAuthorizeThe policy authorizes the request using the SAML Attribute Assertion contained in anauthenticated SAML Assertion. The Attribute Assertion consists of an Attribute Name and one ormore values. This assertion and the corresponding values can be seen in this excerpt (repeatedfrom above): <saml:Attribute AttributeName="CheckingServices" AttributeNamespace="http://www.somebank.com"> <saml:AttributeValue>Query</saml:AttributeValue> <saml:AttributeValue>Request</saml:AttributeValue> /saml:Attribute>Here is the configuration screen setting this policy: Figure 2 - 14. Authorization Method2 - 18 Release 3.6
  • 96. RulesThis policy requires that at least SAML Attribute Assertion name and value match for the requestto be considered valid. The values in the message must match a set of values configured in thepolicy for authorization to succeed.Here are the SAML Attributes configured for matching this policy: Figure 2 - 15. SAML AttributesIn this case, the SAML Attribute assertion matches at least one name and value. Note thatNamespace URI must also match.Finally, this policy employs a Rejected Counter, which is also part of the Threat Protectionestablished for this service. Here is the inclusion of that counter in this policy. Figure 2 - 16. Rejected Counter configurationNote under the Logging section that allowed accesses and rejected accesses are both logged.Release 3.6 2 - 19
  • 97. Bank Checking Web ServiceAction 5: 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 2 - 17. Transform ConfigurationInput: tempvar4 This is set to tempvar4, 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: 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 OUTPUT This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is forwarded to the back end service. If none of the filters and authorization steps have rejected the message after it is validated, it is forwarded to the back end server.2 - 20 Release 3.6
  • 98. RulesRule #2: Request RuleHere is an examination of the components of Rule #2. 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.This rule handles encrypted requests.Match Rule: EncryptedA 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 2 - 18. Encrypted Match RuleThe rule will not run unless the client submits the URL */SomeBank/services/encrypted.Action 1: DecryptA Decrypt action decrypts encrypted messages. In this case, only certain fields of the messagehave been encrypted. Here is an example message, with two encrypted fields:<soapenv:Body> <bank:CheckRequestElement xmlns:bank="http://somebank.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <bank:PayorAccountName>Cartoon Studios</bank:PayorAccountName> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns="http://www.w3.org/2001/04/xmlenc#"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <ds:KeyInfo> <EncryptedKey Recipient="name:SomeBank"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo> <ds:KeyName>SomeBank</ds:KeyName> </ds:KeyInfo> <CipherData> <CipherValue>OXgQ...KUaE=</CipherValue> </CipherData> </EncryptedKey> </ds:KeyInfo> <CipherData> <CipherValue>A1v7C...jvJyw=</CipherValue> </CipherData>Release 3.6 2 - 21
  • 99. Bank Checking Web Service </EncryptedData> <bank:CheckType>P</bank:CheckType> <bank:Payee>Elmer Fudd</bank:Payee> <bank:PayeeAddr>124 East Sunset Drive; Sunset, AL 64846</bank:PayeeAddr> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns="http://www.w3.org/2001/04/xmlenc#"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <ds:KeyInfo> <EncryptedKey Recipient="name:SomeBank"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo> <ds:KeyName>SomeBank</ds:KeyName> </ds:KeyInfo> <CipherData> <CipherValue>b2NMi...f1jIo=</CipherValue> </CipherData> </EncryptedKey> </ds:KeyInfo> <CipherData> <CipherValue>nH1oQ...ehsYMv</CipherValue> </CipherData> </EncryptedData> <bank:Amount>999.00</bank:Amount> </bank:CheckRequestElement> </soapenv:Body>Here is the configuration of the Decrypt action: Figure 2 - 19. Decrypt Action ConfigurationInput: INPUT This is set to INPUT, the special context that contains the original response message.Message Type: Selected Elements (Field Level) The action will decrypt only certain elements within the message. This requires the configuration of a Document Crypto Map object.Document Crypto Map: SBSCE This is set to the SBSCE Document Crypto Map object. That object is explained in detail below.2 - 22 Release 3.6
  • 100. RulesOutput: tempvar1 This context name was assigned automatically by the system. The results of the decrption will be placed in this context.Here is the configuration of the SBSCE Document Crypto Map object: Figure 2 - 20. Document Crypto Map Object ConfigurationThe XPath Expression identifies the elements that are encrypted. Note that although this is onlyone expression, it can apply to more than one element in the node containing the EncryptedDataelement. If the identified encrypted elements do not appear in the submission, no decryption isperformed. A client could submit an unencrypted message to this URL and it would be processedsuccessfully.Release 3.6 2 - 23
  • 101. Bank Checking Web ServiceAction 2: CallThis action calls Rule #1 to complete the full processing of the submitted message. Thiseliminates the need to duplicate that complicated set of actions for the supported encrypted serviceendpoint.The Call action then sends the results of executing the actions in Rule #1 to the back endservice, preserving the URI.Here is the configuration display for this action: Figure 2 - 21. Call Action ConfigurationInput: tempvar1 This is set to tempvar1, the named context used by the preceeding action.Processing Rule: SomeBankCheckService_Rule_0 This is the name stored in the system for Rule #1.Output: OUTPUT This is set to OUTPUT. The result of the Call will be sent directly to the back end server.2 - 24 Release 3.6
  • 102. RulesRule #3: Request RuleHere is an examination of the components of Rule #3. 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.This rule handles signed encrypted requests.Match Rule: SignedA 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 2 - 22. Signed Match RuleThe rule will not run unless the client submits the URL */SomeBank/services/signed.Release 3.6 2 - 25
  • 103. Bank Checking Web ServiceAction 1: VerifyA Verify action verifies the signature contained in the message. If the signature cannot be verified,the message is rejected. If the signature is valid, the rule passes processing to Rule #2, which thendecrypts any encrypted fields. The WSDL specifies that signed messages may also be encrypted.Here is the configuration of the Verify action: Figure 2 - 23. Verify Action ConfigurationInput: INPUT This is set to the special INPUT context, which contains the original message submission.Filter Method: Standard Filter The Standard Filter just checks the signature for validity.Signer Certificate: (Blank) This setting causes the system to use the certificate contained in the signature to verify the signature in the message. If this field had a value, it would need to point to the Crypto Certificate object that would be used for verification.Validation Credentials: None This setting indicates that the system will not perform certificate validation. If this field had a value, it would point to a Crypto Validation Credential object, that in turn would have to include the certificate included in the message to validate that certificate. Additional trust chain checking can also be performed by a Validation Credential object.Output: (Blank) This setting indicates that the system will automatically use the correct context in the following actions. A Verify action is a type of filter that only accepts or rejects the message and does not output the contents of the message.2 - 26 Release 3.6
  • 104. RulesAction 2: TransformThis tranform action serves to connect the last context that contained the message to any actionsthat follow. The policy configuration page automatically creates this action following a filter.Here is the configuration page display for this action. Figure 2 - 24. Transform ConfigurationInput: INPUT This is set to INPUT, the special context containing the submitted message.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 tempvar2 This is set to tempvar2. The policy configuration page automatically assigned this context name. Any subsequent actions can use this context to operate on the message.Release 3.6 2 - 27
  • 105. Bank Checking Web ServiceAction 3: CallThis action calls Rule #2 to complete the full processing of the submitted message. If the messagecontains encrypted elements, the system will decrypt them. The result is passed to Rule #1 forcomplete processing.This eliminates the need to duplicate that complicated set of actions for thesupported service endpoint.The Call action then sends the results of executing the actions in Rule#2 (and subsequently Rule#1) to the back end service, preserving the URI.Here is the configuration display for this action: Figure 2 - 25. Call Action ConfigurationInput: tempvar2 This is set to tempvar2, the named context used by the preceeding action.Processing Rule: SomeBankCheckService_Rule_1 This is the name stored in the system for Rule #2.Output: OUTPUT This is set to OUTPUT. The result of the Call will be sent directly to the back end server.Here is an example of the message sent to the back end server after full processing by theDataPower device:<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <saml:Assertion AssertionID="Ide8d5cf8c-84c5-4fb3-81cf-8e2999dc6dc0" IssueInstant="2005-05-05T19:47:19Z" MajorVersion="1" MinorVersion="1" Issuer="BankConsortium"> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier>CN=Bob</saml:NameIdentifier> </saml:Subject> <saml:Attribute AttributeName="CheckingServices" AttributeNamespace="http://www.somebank.com"> <saml:AttributeValue>Query</saml:AttributeValue> <saml:AttributeValue>Request</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> <Signature xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext" xmlns:SOAP="http://sche-2 - 28 Release 3.6
  • 106. Rulesmas.xmlsoap.org/soap/envelope/" xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#Ide8d5cf8c-84c5-4fb3-81cf-8e2999dc6dc0"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>oLZZRO+Gc/7TSASkipyqCkeBp6I=</DigestValue> </Reference> </SignedInfo> <SignatureValue>ePZifp/YHA3yrEZvUMLc+0U0cVQXgqng6GRrUyxaYLqhkMEHR2v35O82vy9wEUI/xE7M1WLaKHzU3qj1J/45HK02EEqNodDMtLXM5YJy51lIcB+ACacT+OcyGUvfd66oEjzUPpqrKevZoj2rIO9V9x34HXNGdNgRasaZECaiDlM=</SignatureValue> <KeyInfo> <X509Data><X509Certificate>MIICNTCCAZ6gAwIBAgIBADANBgkqhkiG9w0BAQUFADAdMQ0wCwYDVQQKEwRCYW5rHhcNMDUwMzMxMDMyNDIxWhcNMDYwMzMxMDMyNDIxWjAdCwYDVQQKEwRCYW5rMQwwCgYDVQQDEwNDVE8wgZ8wDQYJKoZIhvcNAQEBBQADMIGJAoGBAMM5YZbKZHUR50pUE4ohL7I2uwP/2rssa5c2E0LPLzdEn7n7bWYZY9ScQ0SRUnEbp19eLWkDwQjELCq/92Yk3UaOYVQPB8x//sxFnRoXYn02QHRnzys+gn99WEhTWTNgzIP934DXCnYNQ8h/G3mbpMwEoUlTa8oxAgMBAAGjBAUwAwEB/zAdBgNVHQ4EFgQU7QpIZden38pyV+N5qcCUQW0GRQYDVR0jBD4wPIAU7QpIZden38pyV+N5qcCUQW0Gn5+hIaQfMB0xDTALBgNVUT4IBADALBgNVHQ8EBAMCArwwDQYJKoZIhvcNLl17YMpx4o47ZkM3qxBx3ylIHo3boLq9KS1TbLPyAKatIB0CvG0RXVcf9985jWVNM31QfNY0XMjZ/vLL0tQkgx5v/5aPB1VOHk6jZNlje443jejfASSBMH/JEtSVZ987UHGo1p9NBOIQWIELl0GOljjIU=</X509Certificate> <X509IssuerSerial> <X509IssuerName>CN=CTO, O=Bank</X509IssuerName> <X509SerialNumber>0</X509SerialNumber> </X509IssuerSerial> </X509Data> </KeyInfo> </Signature> </saml:Assertion> </soapenv:Header> <soapenv:Body> <bank:CheckRequestElement Id="G109f6618-3fD" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:bank="http://somebank.com"> <bank:PayorAccountName>Cartoon Studios</bank:PayorAccountName> <bank:PayorAccountID>8458jf8757275234</bank:PayorAccountID> <bank:CheckType>P</bank:CheckType> <bank:Payee>Elmer Fudd</bank:Payee> <bank:PayeeAddr>124 East Sunset Drive; Sunset, AL 64846</bank:PayeeAddr> <bank:PayeeRouteNo>03849032874908</bank:PayeeRouteNo> <bank:Amount>999.00</bank:Amount> <Signature xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://schemas.xml-soap.org/ws/2002/07/secext" xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#G109f6618-3fD"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>Release 3.6 2 - 29
  • 107. Bank Checking Web Service </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>m61euoh0SdFqgTBE1JHky2EylT8=</DigestValue> </Reference> </SignedInfo> <SignatureValue>FsQP6YeA7Fjnl4huOtqiPhzciFCHx5qofsCVvr/xFAoPcjDHqmp/2fMeoxkCKDA6UO/509ijbxICZQlr+BINptJkEF5SBQaAj2ut1PasCkQFr92AuKAlwwPRz5ORda7ZjlOgkfezf2AwqYXz0UB6YKdYAgRJ1EIf0H5HquAVQQI=</SignatureValue> <KeyInfo> <X509Data><X509Certificate>MIICNTCCAZ6gAwIBAgIBADANBgkqhkiG9w0BAQUFADAdMQ0wCwYDVQQKEwRCYW5rHhcNMDUwMzMxMDMyNDIxWhcNMDYwMzMxMDMyNDIxWjAdCwYDVQQKEwRCYW5rMQwwCgYDVQQDEwNDVE8wgZ8wDQYJKoZIhvcNAQEBBQADMIGJAoGBAMM5YZbKZHUR50pUE4ohL7I2uwP/2rssa5c2E0LPLzdEn7n7bWYZY9ScQ0SRUnEbp19eLWkDwQjELCq/92Yk3UaOYVQPB8x//sxFnRoXYn02QHRnzys+gn99WEhTWTNgzIP934DXCnYNQ8h/G3mbpMwEoUlTa8oxAgMBAAGjBAUwAwEB/zAdBgNVHQ4EFgQU7QpIZden38pyV+N5qcCUQW0GRQYDVR0jBD4wPIAU7QpIZden38pyV+N5qcCUQW0Gn5+hIaQfMB0xDTALBgNVUT4IBADALBgNVHQ8EBAMCArwwDQYJKoZIhvcNLl17YMpx4o47ZkM3qxBx3ylIHo3boLq9KS1TbLPyAKatIB0CvG0RXVcf9985jWVNM31QfNY0XMjZ/vLL0tQkgx5v/5aPB1VOHk6jZNlje443jejfASSBMH/JEtSVZ987UHGo1p9NBOIQWIELl0GOljjIU=</X509Certificate> <X509IssuerSerial> <X509IssuerName>CN=CTO, O=Bank</X509IssuerName> <X509SerialNumber>0</X509SerialNumber> </X509IssuerSerial> </X509Data> </KeyInfo> </Signature> </bank:CheckRequestElement> </soapenv:Body></soapenv:Envelope>2 - 30 Release 3.6
  • 108. RulesRule #4: Response RuleHere is an examination of the components of Rule #4. Note that this is a Response rule; it willonly handle messages sent by the server back to the client and will not handle messages sent to theservice by the client.This rule handles server responses to messages that were sent signed and encrypted by the client.The response rule returns a message that is encrypted and signed.Match Rule: SignedThis rule uses the same Signed match rule as Rule #3. The client must have used the URL*/SomeBank/services/signed when making the request for service.Action 1: ValidateThe first custom action of Rule #4 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 2 - 26. 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:///SomeBankCheckService.xsd This is set to local:///SomeBankCheckService.xsd. The custom schema file has been uploaded to the device and placed in the local: directory.Release 3.6 2 - 31
  • 109. Bank Checking Web ServiceOutput: tempvar1 This is set to tempvar1. The system automatically assigned this output context.Action 2: EncryptThis action encrypts the entire body of the message using the WS-Security encryption standard.Here is the configuration page for this action. Figure 2 - 27. Encrypt Response ActionInput: tempvar1 This is set to the output context of the previous action.Envelope Method: WS-Sec Encryption This is set to encrypt the message according to the WS-Security Encryption standards. This places much of the information about the encrypted methods in the SOAP Header.Message Type: SOAP Message This setting causes the entire Body of the SOAP message to be encrypted, rather than just given elements.Recipient Certificate: SomeBank This indicates what Cryptographic Certificate object to use to encrypt the message. This is the certificate issued by the recipient of the messageOutput: tempvar2 The results of the encryption action will be placed in the tempvar2 context.2 - 32 Release 3.6
  • 110. RulesAction 3: SignThis action signs the encrypted response. The configuration display appears as follows. Figure 2 - 28. Sign Response ActionInput: tempvar2 This is the output context of the previous action, containing the encrypted message.Envelope Method: WS-Sec This method causes the signature to be placed in the SOAP header of the message, in accordance with the WS-Security specifications.Message Type: SOAP The entire contents of the Body of the SOAP message will be signed.Key: SomeBank The private cryptographic key contained in the SomeBank key object will be used for the signature. The configuration of this object is covered below.Certificate: SomeBank The public cryptographic certificate contained in the SomeBank certificate object will be used for the signature. The configuration of this object is covered below.Release 3.6 2 - 33
  • 111. Bank Checking Web ServiceOutput: OUTPUT This is the special OUTPUT context, sent back to the client.This rule returns an encrypted, signed message to the client.<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <soapenv:Header> <wsse:Security> <wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509" wsu:Id="cert">MIICN...ljjIU=</wsse:BinarySecurityToken> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SignedInfo xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#Body" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>nIY+QHKv+g+/pTxHOSVVxnAmCgw=</DigestValue> </Reference> </SignedInfo> <SignatureValue>kARx6lAeA...dHvc=</SignatureValue> <KeyInfo> <wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns=""> <wsse:Reference URI="#cert" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509"/> </wsse:SecurityTokenReference> </KeyInfo> <KeyInfo> <X509Data> <X509Certificate>MIICNTCCAZ6...</X509Certificate> <X509IssuerSerial> <X509IssuerName>CN=CTO, O=Bank</X509IssuerName> <X509SerialNumber>0</X509SerialNumber> </X509IssuerSerial> </X509Data> </KeyInfo> </Signature> <xenc:EncryptedKey> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns="http://www.w3.org/2001/04/xmlenc#"/> <dsig:KeyInfo> <wsse:SecurityTokenReference> <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-mes-sage-security-1.0#X509SubjectKeyIdentifier"> 7QpIZden38pyV+N5qcCUQW0Gn58= </wsse:KeyIdentifier> </wsse:SecurityTokenReference> </dsig:KeyInfo> <CipherData xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns="http://www.w3.org/2001/04/xmlenc#">2 - 34 Release 3.6
  • 112. Rules <CipherValue>msag...9zu8tVTA=</CipherValue> </CipherData> <xenc:ReferenceList> <xenc:DataReference URI="#body"/> </xenc:ReferenceList> </xenc:EncryptedKey> </wsse:Security> </soapenv:Header> <soapenv:Body wsu:Id="Body" id="Body"> <xenc:EncryptedData Id="body" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:bank="http://some-bank.com"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <CipherData xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <CipherValue>aYYD...2oPo</CipherValue> </CipherData> </xenc:EncryptedData> </soapenv:Body></soapenv:Envelope>Rule #5: Response RuleHere is an examination of the components of Rule #5. Note that this is a Response rule; it willonly handle messages sent by the server back to the client and will not handle messages sent to theservice by the client.This rule handles server responses to messages that were sent signed and encrypted by the client.The response rule returns a message that is encrypted and signed.Match Rule: EncryptedA Match Rule examines the response message and determines whether or not the rule should berun against the message. In this case, the match rule examines the URL used by the client todetermine a match. As with the corresponding request rule, the response rule will not run unlessthe client submits the URL */SomeBank/services/encrypted.The 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 to the calling client. ThisSOAP schema filtering is implied and no action needs to be created for it.Release 3.6 2 - 35
  • 113. Bank Checking Web ServiceAction 1: ValidateThe first custom action of Rule #5 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 2 - 29. 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:///SomeBankCheckService.xsd This is set to local:///SomeBankCheckService.xsd. The custom schema file has been uploaded to the device and placed in the local: directory.Output: (Blank) This is set to Blank. The system will automatically configure the correct output context.2 - 36 Release 3.6
  • 114. RulesAction 2: EncryptThis action encrypts the entire body of the message using the WS-Security encryption standard.Here is the configuration page for this action. Figure 2 - 30. Encrypt Response ActionInput: INPUT This is set to the special INPUT context, which contains the message submitted by the server.Envelope Method: WS-Sec Encryption This is set to encrypt the message according to the WS-Security Encryption standards. This places much of the information about the encrypted methods in the SOAP Header.Message Type: SOAP Message This setting causes the entire Body of the SOAP message to be encrypted, rather than just given elements.Recipient Certificate: SomeBank This indicates what Cryptographic Certificate object to use to encrypt the message. This is the certificate issued by the recipient of the messageOutput: OUTPUT The results of the encryption action will be sent directly back to the client.Release 3.6 2 - 37
  • 115. Bank Checking Web ServiceHere is an example response sent to the client.<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <soapenv:Header xml:space="preserve"> <wsse:Security soapenv:mustUnderstand="1"> <xenc:EncryptedKey> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <dsig:KeyInfo> <wsse:SecurityTokenReference> <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#X509SubjectKeyIdentifier"> 7QpIZden38pyV+N5qcCUQW0Gn58= </wsse:KeyIdentifier> </wsse:SecurityTokenReference> </dsig:KeyInfo> <CipherData xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmld-sig#"> <CipherValue>YhZpyC...Z26Ws=</CipherValue> </CipherData> <xenc:ReferenceList><xenc:DataReference URI="#body"/></xenc:ReferenceList> </xenc:EncryptedKey> </wsse:Security> </soapenv:Header> <soapenv:Body xmlns:bank="http://somebank.com"> <xenc:EncryptedData Id="body" Type="http://www.w3.org/2001/04/xmlenc#Content"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <CipherData xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmld-sig#"> <CipherValue>+I8I+EO2...a7Cycd0</CipherValue> </CipherData> </xenc:EncryptedData> </soapenv:Body></soapenv:Envelope>2 - 38 Release 3.6
  • 116. RulesRule #6: Response RuleHere is an examination of the components of Rule #6. Note that this is a Response rule; it willonly handle messages sent by the server back to the client and will not handle messages sent to theservice by the client.This rule handles server responses to messages that were sent unsigned and unencrypted by theclient. The response rule returns a message that is neither encrypted and signed.Match Rule: CheckingA Match Rule examines the response message and determines whether or not the rule should berun against the message. In this case, the match rule examines the URL used by the client todetermine a match. As with the corresponding request rule, the response rule will not run unlessthe client submits the URL */SomeBank/services/checking.The 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 to the calling client. ThisSOAP schema filtering is implied and no action needs to be created for it.Action 1: ValidateThe first custom action of Rule #6 validates the contents of the SOAP Body element against 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 2 - 31. 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.Release 3.6 2 - 39
  • 117. Bank Checking Web ServiceSchema URL: local:///SomeBankCheckService.xsd This is set to local:///SomeBankCheckService.xsd. The custom schema file has been uploaded to the device and placed in the local: directory.Output: (Blank) This is set to Blank. The system will automatically configure the correct output context.Action 2: TransformThis action connects the original response message to the OUTPUT context, if the Validate actionsucceeds. Figure 2 - 32. Transform Action ConfigurationInput: INPUT This is set to INPUT, the special context containing the submitted message.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.2 - 40 Release 3.6
  • 118. RulesOutput: OUTPUT The action sends the INPUT message directly to OUTPUT, which is then transmitted to the client.Here is an example response message.<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:bank="http://somebank.com"> <soapenv:Body> <bank:CheckResponseElement> <bank:TransactionNum>66287</bank:TransactionNum> <bank:CheckNum>23423</bank:CheckNum> <bank:CheckType>P</bank:CheckType> <bank:PayorAccountID>8458jf8757275234</bank:PayorAccountID> <bank:Payee>Elmer Fudd</bank:Payee> <bank:Amount>999.00</bank:Amount> </bank:CheckResponseElement> </soapenv:Body></soapenv:Envelope>Release 3.6 2 - 41
  • 119. Bank Checking Web ServiceMonitorsThis service employs four different monitors for security against XML threats. These monitorswere listed on the Advanced page of the Firewall configuration. These monitors are as follows.Monitor Name Type PurposeSomeBank- Count Track the number of access requests rejected by theRejectedAccess Authentication and Authorization system. If more than x submissions are rejected within x milliseconds, the monitor will block access. This is one method to detect dictionary attacks.SomeBankCheckService- Count Track the total number of access requests to the service. Ifcount-monitor-firewall more than x requests occur within x milliseconds, the monitor will block access for a period of time. This detects a DDOS attack.SomeBankCheckService- Count Track the total number of access requests from any givencount-monitor-from-ip host IP address. If more than x requests occur within x milliseconds, the monitor will block access for a period of time. This detects a DOS attack.SomeBankCheckService- Duration Track the total duration of request processing. If theduration-monitor average duration exceeds a threshold, the monitor will block access for a period of time. This is another type of DOS attack and also enforces service response time levels.All of these monitors were configured automatically by the device. All but the SomeBank-RejectedAccess monitor can be easily altered from the XML Threat Protection page of the firewallservice. On the Control Panel, click Edit XML Firewall. Click the firewall name in the list offirewalls. Finally, scroll to the bottom of the page and click the XML Threat Protection button.Altering the SomeBank-RejectedAccess monitor can be done from the Firewall Policy page;however, it is easier to alter the Count Monitor object directly. Click the Services navigation barand then click Message Monitors. The following page appears. Figure 2 - 33. Message Monitor ListingClick SomeBank-RejectedAccess. The Message Monitor appears.2 - 42 Release 3.6
  • 120. Monitors Figure 2 - 34. Message Monitor PropertiesClick Next. The following page appears. Figure 2 - 35. Count Monitor FiltersClick the filter name. The following page appears. Figure 2 - 36. Edit Count Monitor FilterYou can now change the thresholds for this monitor. When you have made the needed changes,click Submit. The screen redisplays the previous page.Release 3.6 2 - 43
  • 121. Bank Checking Web ServiceIf you wish to change the Action taken when the threshold is reached, click the ... button alongsidethe Action. The following appears. Figure 2 - 37. Editing a Message Filter ActionMake any necessary changes and click Apply. This window closes.After making the necessary changes to the Count Monitor filter and clicking either Submit orCancel,the following page reappears. Figure 2 - 38. Monitor FiltersClick Next.2 - 44 Release 3.6
  • 122. MonitorsThe following page appears. Figure 2 - 39. Confirm Monitor changesClick Commit.Release 3.6 2 - 45
  • 123. Bank Checking Web ServiceLoggingThis example employs a custom log target, which captures messages generated by the serviceshandling the SomeBank Checking web services traffic. Here is the configuration display of thecustom Log Target object Main page: Figure 2 - 40. Log Target Main ConfigurationType: syslog This log target sends captured log messages to a syslog process elsewhere on the network..Local Identifier: DP The Local Identifier embedded in the syslog message. Syslog management tools can filter on this value.Remote Host Address: 10.10.100.3 This is the IP address of the remote syslog utility.Remote Port: 263 The syslog listens on port 263.Syslog Facility: user The log entries are sent to the syslog with this facility.Backup Log: default-log In the event the syslog facility cannot be reached, this back up log will capture log messages.2 - 46 Release 3.6
  • 124. LoggingNote that when a device is rebooted (as opposed to the firmware reloaded), all temporary files onthe filesystem are erased. For this reason, log files are often moved off the device for storage.Using a remote logging utility is a common strategy.Object FiltersLog targets capture messages by Object Filters and Event Subscriptions. Object filters determinewhat messages will be captured according to source object. Figure 2 - 41. 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 2 - 42. Log Target Event Subscription ConfigurationRelease 3.6 2 - 47
  • 125. Bank Checking Web ServiceThis indicates that all messages of severity notice or higher will be captured. Above notice arewarning, error, critical, alert and emergency.2 - 48 Release 3.6
  • 126. SSL CommunicationsSSL CommunicationsIn this scenario, the communication channels between the DataPower service and the requestingclient use SSL to encrypt communications. The firewall configuration page shows the setting touse SSL communications. Figure 2 - 43. SSL Server Crypto Profile settingHere is the configuration of the Crypto Profile: Figure 2 - 44. Crypto Profile ConfigurationIdentification Credentials: SomeBank These credentials identify the private cryptographic key and public cryptographic certificate used by this service to identify itself to clients. A browser client connecting to this service will be given a copy of the certificate identified by these credentials for use in SSL communications.Validation Credentials: None This setting indicates that the service will not request a certificate of authority to identify the requesting clients.All other inputs are set to the default, requiring no configuration action. With SSL enabled, thebrowsers use HTTPS rather than HTTP to communicate with the DataPower system.Release 3.6 2 - 49
  • 127. Bank Checking Web ServiceCrypto Identification CredentialsThe SSL Crypto Profile relies upon the Crypto Identification Credential SomeBank. Here is theconfiguration of the Identification Credential object: Figure 2 - 45. Crypto Identification Credentials ConfigurationThe Key and Certificate objects identify the private key and public certificate used for securecommunications over an SSL channel. Both of those objects were generated automatically on theDataPower system using the Cryptographic Key tool. Those objects can also use private keys andcertificates uploaded to the device.Crypto KeyHere is the configuration of the Key object:2 - 50 Release 3.6
  • 128. SSL Communications Figure 2 - 46. Crypto Key ConfigurationThe object points at a key file stored in the encrypted cert: directory on the local flash filesystem.Files placed in the cert: directory can be read by the system, but cannot be copied or moved in anyway.Crypto CertificateHere is the configuration of the Certificate object: Figure 2 - 47. Crypto Certificate ConfigurationThis object points to a certificate file stored on the local flash filesystem, in the encrypted cert:directory. Files placed in the cert: directory can be read by the system, but cannot be copied ormoved in any way.Release 3.6 2 - 51
  • 129. Bank Checking Web ServiceSomeBank Checking Service WSDL<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace="http://somebank.com" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:bank="http://somebank.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <wsdl:types> <xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://somebank.com"> <xs:element name="AccountRequestElement" type="bank:AccountRequest"/> <xs:complexType name="AccountRequest"> <xs:sequence> <xs:element name="accountName" type="xs:string"/> <!-- Account Name --> <xs:element name="accountID" type="xs:string"/> <!-- Account ID --> <xs:element name="accountType" type="xs:string"/> <!-- Account Type --> </xs:sequence> </xs:complexType> <xs:element name="AccountResponseElement" type="bank:AccountResponse"/> <xs:complexType name="AccountResponse"> <xs:sequence> <xs:element name="balance" type="xs:float"/><!-- Account Balance --> </xs:sequence> </xs:complexType></xs:schema><xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://somebank.com"> <xs:element name="CheckRequestElement" type="bank:CheckRequest"/> <xs:complexType name="CheckRequest"> <xs:sequence> <xs:element name="PayorAccountName" type="xs:string"/> <xs:element name="PayorAccountID" type="xs:string"/> <xs:element name="CheckType" type="xs:string"/> <xs:element name="Payee" type="xs:string"/> <xs:element name="PayeeAddr" type="xs:string" minOccurs="0"/> <xs:element name="PayeeRouteNo" type="xs:string" minOccurs="0"/> <xs:element name="Amount" type="xs:float"/> <xs:any namespace="##any" processContents="skip" minOccurs="0"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="skip"/> </xs:complexType> <xs:element name="CheckResponseElement" type="bank:CheckResponse"/> <xs:complexType name="CheckResponse"> <xs:sequence> <xs:element name="TransactionNum" type="xs:int"/> <xs:element name="CheckNum" type="xs:int"/> <xs:element name="CheckType" type="xs:string"/> <xs:element name="PayorAccountID" type="xs:string"/> <xs:element name="Payee" type="xs:string"/> <xs:element name="Amount" type="xs:float"/> <xs:any namespace="##any" processContents="skip" minOccurs="0"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="skip"/> </xs:complexType> <xs:element name="CheckRequestErrorElement" type="bank:CheckRequestError"/> <xs:complexType name="CheckRequestError"> <xs:sequence> <xs:element name="TransactionNum" type="xs:int"/> <xs:element name="ErrorNum" type="xs:int"/>2 - 52 Release 3.6
  • 130. SomeBank Checking Service WSDL <xs:element name="CheckType" type="xs:string"/> <xs:element name="PayorAccountID" type="xs:string"/> <xs:element name="Payee" type="xs:string"/> <xs:element name="ErrorMessage" type="xs:string"/> </xs:sequence> </xs:complexType></xs:schema> </wsdl:types><wsdl:message name="AccountResponse"> <wsdl:part element="bank:AccountResponseElement" name="response"/></wsdl:message><wsdl:message name="AccountRequest"> <wsdl:part element="bank:AccountRequestElement" name="request"/></wsdl:message> <wsdl:message name="CheckResponse"> <wsdl:part element="bank:CheckResponseElement" name="checkresponse"/></wsdl:message><wsdl:message name="CheckRequest"> <wsdl:part element="bank:CheckRequestElement" name="checkrequest"/></wsdl:message><wsdl:message name="CheckRequestError"> <wsdl:part element="bank:CheckRequestErrorElement" name="checkrequesterror"/></wsdl:message><wsdl:portType name="SomeBankPortType"> <wsdl:operation name="accountEnquiry" parameterOrder="request"> <wsdl:input message="bank:AccountRequest"/> <wsdl:output message="bank:AccountResponse"/> </wsdl:operation> <wsdl:operation name="checkRequest" parameterOrder="request"> <wsdl:input message="bank:CheckRequest"/> <wsdl:output message="bank:CheckResponse"/> <wsdl:fault message="bank:CheckRequestError"/> </wsdl:operation></wsdl:portType><wsdl:binding name="SomeBankBinding" type="bank:SomeBankPortType"> <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="accountEnquiry"> <wsdlsoap:operation soapAction=""/> <wsdl:input> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="checkRequest"> <wsdlsoap:operation soapAction=""/> <wsdl:input> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output> <wsdlsoap:body use="literal"/> </wsdl:output> <wsdl:fault name="bank:CheckRequestError"> <wsdlsoap:fault use="literal"/> </wsdl:fault> </wsdl:operation></wsdl:binding><wsdl:service name="SomeBankService">Release 3.6 2 - 53
  • 131. Bank Checking Web Service <wsdl:port binding="bank:SomeBankBinding" name="SomeBankPort"> <wsdlsoap:address location="http:/10.10.13.35:2068/SomeBankService/services/SomeBankPort"/> </wsdl:port> <wsdl:port binding="bank:SomeBankBinding" name="SomeBankPortSignedAndEncrypted"> <wsdlsoap:address location="http:/10.10.13.35:2068/SomeBank/services/signed"/> </wsdl:port> <wsdl:port binding="bank:SomeBankBinding" name="SomeBankPortEncrypted"> <wsdlsoap:address location="http:/10.10.13.35:2068/SomeBank/services/encrypted"/> </wsdl:port> <wsdl:port binding="bank:SomeBankBinding" name="SomeBankPortChecking"> <wsdlsoap:address location="http:/10.10.13.35:2068/SomeBank/services/checking"/> </wsdl:port></wsdl:service></wsdl:definitions>2 - 54 Release 3.6
  • 132. Chapter 3 Multi-Protocol GatewayThis example configuration implements a simple bank checking service. Requests arrive from anynumber of other hosts that offer the consumer the checking service. Requests may arrive using theMQ, HTTP or HTTPS protocol. The SOAP request for service is formatted according to apublished schema (available from the WSDL for the service; refer to the end of this chapter), andis signed. Requests are validated against well-known SOAP schemas, the published schema forthe service, filtered for data correctness and finally the WS-Security signature on the message isverified. Here is an illustration of the architecture involved. MQ Endpoint HTTPS DataPower HTTP HTTP Many App ServersAll traffic between the DataPower device and the application server travels over plain HTTP. TheDataPower system performs the following tasks on requests: • Validates Request Against Schema • Filters Request Data • Verifies Signatures • Forwards to EndpointThe DataPower box performs the following tasks on the response from the server: • Vaildates Response Format • Signs Response Message (if request was signed)XML Threat Protection is applied to all traffic passing through the Gateway. 3-1
  • 133. Multi-Protocol GatewayMulti-Protocol GatewayThe upper portion of the Multi-Protocol Gateway Service configuration page appears as shownhere. Figure 3 - 1. Multi-Protocol Gateway Configuration (partial)These are the field values.Multi-Protocol Gateway Name: CheckingService The name of the gateway object. This name may appear in the Via: field of the HTTP headers returned during SOAP and XML web service transactions. It also appears in the log files.Multi-Protocol Gateway Type: Static backend The gateway forwards all requests to a single back end server IP address and Port.XML Manager: Default The default is used.Multi-Protocol Gateway Policy: CheckServicePolicy The custom processing policy built for this service, CheckServicePolicy, is selected. This policy is covered in detail below.URL Rewrite Policy: None The default is used. The URLs sent by the clients are not altered in any way before the processing policy is run.3-2 Release 3.6
  • 134. Multi-Protocol GatewayBack Side SettingsBack End URL: http://10.10.13.35:2068 All traffic is routed to the address given here. Note that no URI is included in this value. This is because the Propogate URI property is set to on - the default. The gateway will automatically append whatever the client provides from the first forward-slash in the URL to the last character. Thus if the client uses the URL http://gwaddr:3001/SomeBank/services/checking, the complete URL employed by the gateway when sending to the back end service is http:// 10.10.13.35:2068/SomeBank/services/checking.Front Side SettingsFront Side Protocol: (HTTP, HTTPS and MQ Protocol Handlers) The gateway has three Front Side Protocol Handlers configured, one for the HTTP protocol, one for the HTTPS protocol and one for the MQ protocol. The Front Side Handlers determine the IP address, port number and other transport-layer properties. These handlers are covered in detail below. Figure 3 - 2. Multi-Protocol Gateway Configuration (partial)Back End Settings (left column)User Agent Settings: None The default is used. No User Agent settings will affect gateway communications.Release 3.6 3-3
  • 135. Multi-Protocol GatewaySSL Client Crypto Profile: None The default is used. Communication with the back end server will not employ SSL in this case. Even if a profile were selected, the Back End URL indicates that the traffic will pass over HTTP and not HTTPS, so this setting would be ignored.Response Type: SOAP The selection SOAP indicates that the back end server will post SOAP documents in response to requests from the gateway service. The gateway service automatically validates the documents against the SOAP schemas now in use (SOAP 1.1, 1.2 and variants).Response Attachments: Strip The default value (strip) is used. Any attachments sent by the server will be stripped off before the message is handled by the gateway service.Back Attachment Processing Format:: Automatically detect The default value (Automatically detect) is used. Leaving this at the default ensures that all attachments may pass through the gateway regardless of format. Since the gateway is configured to pass through attachments, selecting the wrong format could cause an error.Front End Settings (right column)Request Type: SOAP The selection SOAP indicates that the clients will post SOAP-formatted documents to the gateway service. Inbound SOAP documents are automatically validated against the published SOAP schemas. If the messages do not comply with the schemas, an error is returned to the client.Request Attachments: : Attachments are sent but unprocessed. This setting allows the gateway to accept and forward any attachments contained in the message payload but frees the gateway from the need to apply any processing to attachments. Thus, this service may receive a MIME or DIME message containing the primary XML document in the root part of the message and perhaps a check image in an attachment but the image will not be handled in any way. The root part XML document, however, will be processed by the Policy selected.Front Attachment Processing Format: Automatically detect The default value (Automatically detect) is used. As any attachments sent by the back end service will be stripped off before the message is handled by the gateway service, this setting has no meaning.3-4 Release 3.6
  • 136. Multi-Protocol Gateway Figure 3 - 3. Multi-Protocol Gateway Configuration (partial)The service accepts a number of other inputs, all of which are set to the default. These are shownabove.Advanced TabThe Advanced tab offers several properties that were changed from the defaults. Here is the page: Figure 3 - 4. Advanced ConfigurationAll of these inputs have been left at the defaults with the exception of the following properties.Release 3.6 3-5
  • 137. Multi-Protocol GatewayLoop Detection: On This has been changed to On from the default. The gateway will automatically insert the HTTP Header Via: and the name of the gateway service into messages it processes. This will allow the gateway to detect loops.Follow Redirects: On This has been changed to On from the default. If the back end server sends the gateway an HTTP Redirect, the Gateway will follow it, and resend the HTTP message to the redirected URL. This allows the back end service to redirect traffic during maintenance windows. This can be considered a security risk.Allow Chunked Uploads: On This has been changed to On from the default. This setting allows the gateway to send large files in chunked uploads to the back end server. The back end server must implement HTTP 1.1 to support this. This can speed transmission.XML Threat ProtectionThe gateway has been configured to provide a degree of XML Threat Protection. These settingsautomatically create a set of monitors for the service. Figure 3 - 5. XML Threat Protection ConfigurationOnly the Single Message and Multiple Message sections have been configured, as shown above.3-6 Release 3.6
  • 138. Multi-Protocol GatewaySingle Message XML Denial of Service (XDOS)Maximum Message Size: 0 This is zero, the default. The gateway will accept a message of any size.Gateway Parser Limits: On This has been changed to On from the default. The following inputs will override any similar settings in the XML Manager used by the gateway.XML Attribute Count: 32 This has been changed to 32 from the default of 128. This setting applies significantly more stringent limits on the number of attributes allowed within submitted documents.XML Element Depth: 64 This has been changed to 64 from the default of 512. This setting applies significantly more stringent limits on the depth of elements allowed within submitted documents.XML Attribute Maximum Node Size: 500000 This has been changed to 500K from the default. No single element node within the submitted document can exceed 500K in size.Attachment Byte Count Limit: 20000000 This has been changed to 20 Meg from the default of 2 gigabytes. Very large binary attachments will not be accepted by the gatewayMultiple Message XML Denial of Service (MMDOS)Max Duration for a Request: 10000 Ten thousand milliseconds (10 seconds) are allowed for processing any one request.Interval for Measuring Request Rate from Host: 3000 The value of 3000 measures how many requests are received from any given host every 3 seconds. Note that this is not set lower due to the fact that a busy gateway will not execute this check as the highest priority task; instead it will process documents and then check this measurement.Max. Request Rate from Host: 50 No host can send more than 50 requests every 3 seconds.Interval for Measuring Request Rate for Gateway: 3000 The value of 3000 sets the measurement interval at 3 seconds.Max Request Rate for Gateway: 300 The gateway will accept 300 requests every 3 seconds.Block Interval: 500 The gateway will block access after one of the other thresholds have been reached for 500 milliseconds.Log Level When a threshold is reached, the gateway generates an error log message.Release 3.6 3-7
  • 139. Multi-Protocol GatewayMonitorsThe XML Threat Protection settings automatically create the monitors shown on the Monitors tab. Figure 3 - 6. MonitorsIt is easier to modify these monitors through the XML Threat Protection Page than through theMonitors directly.3-8 Release 3.6
  • 140. Front Side Protocol HandlersFront Side Protocol HandlersThis gateway employs two Front Side Protocol Handlers.HTTP Front Side Protocol Handler Figure 3 - 7. HTTP Front Side Protocol HandlerAll of the defaults have been used with the exception of the following information.Name: chk-http-handler The name of the handler. This is the name that appears in the gateway configuration page.Local IP Address: 0000 This has been left at the default. The default indicates that this Handler will listen on the port number indicated for all configured IP addresses.Port Number: 3001 This was entered by hand. The system does not assign the next available number. This value must be unique throughout the device.Release 3.6 3-9
  • 141. Multi-Protocol GatewayHTTPS Front Side Protocol Handler Figure 3 - 8. HTTPS Front Side Protocol HandlerAll of the defaults have been used with the exception of the following information.Name: chk-https-handler The name of the handler. This is the name that appears in the gateway configuration page.Local IP Address: 0000 This has been left at the default. The default indicates that this Handler will listen on the port number indicated for all configured IP addresses.Port Number: 3002 This was entered by hand. The system does not assign the next available number. This value must be unique throughout the device.3 - 10 Release 3.6
  • 142. Front Side Protocol Handlers Figure 3 - 9. SSL Proxy SettingSSL Proxy: SomeBanks The SSL Proxy Proflle SomeBanks is selected. The configuration of this Proxy is discussed in detail below.MQ Front Side Protocol Handler Figure 3 - 10. MQ Front Side Protocol HandlerAll of the defaults have been used with the exception of the following information.Name: SomeBank-MQ The name of the handler. This is the name that appears in the gateway configuration page.Queue Manager: ZippyBanker This is the name of a Websphere MQ Queue Manager object configured in the same application domain on the device. The configuration of this object is covered below.Get Queue: QUEUE1 This is the name of a queue available on the remote MQ Queue Manager. The Protocol Handler will constantly poll this queue for requests to process. This name must be provided by the local MQ administrator.Release 3.6 3 - 11
  • 143. Multi-Protocol GatewayPut Queue: QUEUE2 This is the name of a queue available on the remote MQ Queue Manager. The Protocol Handler will place responses on this queue. This name must be provided by the local MQ administrator.Websphere MQ Queue Manager Figure 3 - 11. Websphere MQ Queue Manager ConfigurationAll of the defaults have been used with the exception of the following information.Name: ZippyBanker The name of the Queue Manager object. This is the name that appears in the Protocol Handler configuration page.Host Name: 10.10.100.74(5558) The Remote Host running the remote MQ Queue Manager instance managing the queues. This takes the format address(port) in accordance with the MQ client specifications.3 - 12 Release 3.6
  • 144. Front Side Protocol HandlersQueue Manager Name: WAS_ip1_server1 The name of the remote Queue Manager to use for this connection. Multiple Queue Managers may be available on the host indicated. This name must match the remote name exactly. The Get and Put queues used by the Front Side Protocol Handler must be managed by this Queue Manager.Channel Name: SYSTEM.DEF.SVRCONN This is the default channel. The Queue Manager could use a different channel, if configured.User Name: mqm This is the user name the Protocol Handler will present to the Queue Manager when connecting to queues. This is optional.Convert Input: Off Normally, the Queue Manager will automatically convert messages to the native MQ format. Turning this off preserves the format of the submitted message.Release 3.6 3 - 13
  • 145. Multi-Protocol GatewayMulti-Protocol Gateway PolicyHere is the graphic representation of the gateway policy used for this implementation. Figure 3 - 12. SomeBankCheckServices Multi-Protocol Gateway 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.3 - 14 Release 3.6
  • 146. RulesRulesOverviewHere is an overview of the rules used in this policy.Rule 1 Request Rule Matching */SomeBank/services/checking This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Validate against the published schema for the service 2 Filter requests for valid values 3 Verify the WS-Security digital signature 4 Send to back end serviceRule 2 Response Rule Matching */SomeBank/services/checking This rule runs when the server sends the matching URL. This rule operates on the response from the server. The rule performs the following actions: 1 Validate server response against schema 2 Sign the response using a WS-Security signatureHere is an example of a message submitted to the gateway.<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header> <saml:Assertion AssertionID="ac980a79b0ee3d3f4824318155b790ec" IssueInstant="2004-04-15T21:48:03Z"Issuer="BankConsortium" MajorVersion="1" MinorVersion="1" xmlns="urn:oasis:names:tc:SAML:1.0:assertion"xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier>CN=Bob</saml:NameIdentifier> </saml:Subject> <saml:Attribute AttributeName="CheckingServices" AttributeNamespace="http://www.somebank.com"> <saml:AttributeValue>Query</saml:AttributeValue> <saml:AttributeValue>Request</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> <wsse:Security soapenv:mustUnderstand="1"> <wsu:Timestamp wsu:Id="Timestamp-5b766324-0c15-4ce7-8c3a-6d65eaf90c48"> <wsu:Created>2005-07-22T00:48:37Z</wsu:Created> <wsu:Expires>2005-07-22T00:53:37Z</wsu:Expires> </wsu:Timestamp> <wsse:BinarySecurityToken wsu:Id="SecurityToken-99d46647-a66c-419b-9257-146ee48fec7f" Encoding-Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" Value-Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509">MIICBjCCAW+gAwIBAgIBADANBgkqhkiG9w0BAQUFADAOMQwwCgYDVQQDEwNDVE8wHhcNMDUwNTI3MDAyMzM3WhcNMDYwNTI3MDAyMzM3WjAOMQwwCgYDVQQDEwNDVE8wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMvT9vYN8iULhSQUHJXpduB6gFKHebqoUog9a+an2lOG5tKm4sgPLF2EEMZPiMLPxfK8wYmKZ+L3hp4O4Rl3UDNfhTIBebQeS0OIUQUKdOu/DnvPuISgf1f1UJYuI/ovRoohfLLiIIUBrAnDzR2EMb7vfMgb+pf/JcOtzfvROJ8jAgMBAAGjdDByMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFLtFYCU8LH0ro2lqI0g1t3bSV8C3MDYGA1UdIwQvMC2AFLtFYCU8LH0ro2lqI0g1t3bSV8C3oRKkEDAOMQwwCgYDVQQDEwNDVE+CAQAwCwYDVR0PBAQDAgK8MA0GCSqGSIb3DQEBBQUAA4GBAD+MdbIDf7UPY71khyCwCIj9c/ggPraNWMI34b+upJM+O8tI7s55Release 3.6 3 - 15
  • 147. Multi-Protocol GatewayqUDyfdY1/ne1mh7yOPW6l8Gg3aXw2k1Pkpefs+Ol5vwUvtSu53sKM4lZZbBywa3JoYzFfsmVPbyXx58UsxAfajryHtHN7110/C/I0RuZRgVhyW4s6eBu1/qj</wsse:BinarySecurityToken> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#Body-2e12f754-09ec-47bd-9db0-a59e0461ebf2"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>D1VOiRZo3+90OIERsEzm9PYUcjw=</DigestValue> </Reference> <Reference URI="#Timestamp-5b766324-0c15-4ce7-8c3a-6d65eaf90c48"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>pMZucLpEEkJ8cF976C1GbWqQFjs=</DigestValue> </Reference> </SignedInfo><SignatureValue>F1mns6cSay4W1znuZ3W4Ao94bDFdhmeBN5MLpYZrMch9dUD5hL4AO6ApZdKpLHm623BXAr+oP54CJEs9OA9vpWYJYMXwDfFIuuu278g7sZyp56tIdQyE3V1PHLTnONhpjTTiiEfXZ89u8vmvBQYoj2r8/qRc8J7j8n1Ke5ZRkvY=</SignatureValue> <KeyInfo> <wsse:SecurityTokenReference xmlns=""> <wsse:Reference URI="#SecurityToken-99d46647-a66c-419b-9257-146ee48fec7f" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509"/> </wsse:SecurityTokenReference> </KeyInfo> </Signature> </wsse:Security> </soapenv:Header> <soap:Body wsu:Id="Body-2e12f754-09ec-47bd-9db0-a59e0461ebf2"> <bank:CheckRequestElement xmlns:bank="http://somebank.com"> <bank:PayorAccountName>Cartoon Studios</bank:PayorAccountName> <bank:PayorAccountID>8458jf8757275234</bank:PayorAccountID> <bank:CheckType>P</bank:CheckType> <bank:Payee>Elmer Fudd</bank:Payee> <bank:PayeeAddr>124 East Sunset Drive; Sunset, AL 64846</bank:PayeeAddr> <bank:PayeeRouteNo>03849032874908</bank:PayeeRouteNo> <bank:Amount>999.00</bank:Amount> </bank:CheckRequestElement> </soap:Body></soapenv:Envelope>3 - 16 Release 3.6
  • 148. RulesRule #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.This is the core processing rule of the policy. All messages must pass through this set ofvalidation, filter, and verification steps.Match Rule: CheckingA 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 3 - 13. Checking Match Rule ConfigurationThe client must use the URL */SomeBank/services/checking or this rule will not be applied to themessage. Note that the expression * means “any substring of any characters.”Implied Action 0: ValidateThe gateway automatically validates the inbound message against the SOAP schemas, to ensurethat 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.Consequently, the gateway may reject a message before any of the actions in the configured policyrun.Release 3.6 3 - 17
  • 149. Multi-Protocol GatewayAction 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 3 - 14. 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 specified schema URL. A URL must be provided that identifies the location of the schema file.Schema URL: local:///SomeBankCheckService.xsd This is set to local:///SomeBankCheckService.xsd. The custom schema file has been uploaded to the device and placed in the local: directory.Output: tempvar1 This is set to tempvar1. If the input is valid, the context will contain the validated message. If an error occurs (the message fails to validate, for example), the context is empty. Any subsequent actions can access the results by using tempvar1 as the input context.3 - 18 Release 3.6
  • 150. RulesHere is the schema file used for this action.<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:bank="http://somebank.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://somebank.com"elementFormDefault="qualified"> <xs:element name="CheckRequestElement" type="bank:CheckRequest"/> <xs:complexType name="CheckRequest"> <xs:sequence> <xs:element name="PayorAccountName" type="xs:string"/> <xs:element name="PayorAccountID" type="xs:string"/> <xs:element name="CheckType" type="xs:string"/> <xs:element name="Payee" type="xs:string"/> <xs:element name="PayeeAddr" type="xs:string" minOccurs="0"/> <xs:element name="PayeeRouteNo" type="xs:string" minOccurs="0"/> <xs:element name="Amount" type="xs:float"/> <xs:any namespace="##any" processContents="skip" minOccurs="0"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="skip"/> </xs:complexType> <xs:element name="CheckResponseElement" type="bank:CheckResponse"/> <xs:complexType name="CheckResponse"> <xs:sequence> <xs:element name="TransactionNum" type="xs:int"/> <xs:element name="CheckNum" type="xs:int"/> <xs:element name="CheckType" type="xs:string"/> <xs:element name="PayorAccountID" type="xs:string"/> <xs:element name="Payee" type="xs:string"/> <xs:element name="Amount" type="xs:float"/> <xs:any namespace="##any" processContents="skip" minOccurs="0"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="skip"/> </xs:complexType> <xs:element name="CheckRequestErrorElement" type="bank:CheckRequestError"/> <xs:complexType name="CheckRequestError"> <xs:sequence> <xs:element name="TransactionNum" type="xs:int"/> <xs:element name="ErrorNum" type="xs:int"/> <xs:element name="CheckType" type="xs:string"/> <xs:element name="PayorAccountID" type="xs:string"/> <xs:element name="Payee" type="xs:string"/> <xs:element name="ErrorMessage" type="xs:string"/> </xs:sequence> </xs:complexType></xs:schema>Release 3.6 3 - 19
  • 151. Multi-Protocol GatewayAction 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 3 - 15. Filter ConfigurationInput: tempvar1 This is set to tempvar1, the named context used by the preceeding action. Note that this could have been set to INPUT since this action would not execute if the validation before it failed. However, validation can sometimes change the message format, thus this action uses the result of the validation.Processing Control File: local:///SomeBankCheckService.xsl This is set to local:///SomeBankCheckService.xsl. The custom XSLT file has been uploaded to the device and placed in the local: directory.Output: (blank) 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 extension-element-prefixes="dp" version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP12="http://www.w3.org/2003/05/soap-envelope"xmlns:dp="http://www.datapower.com/extensions" xmlns:bank="http://somebank.com"> <xsl:template name="valid-operation"> <xsl:param name="op"/> <xsl:choose> <xsl:when test="$op=CheckRequestElement"> <xsl:choose> <xsl:when test="string-length(/SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:PayorAccoun-3 - 20 Release 3.6
  • 152. RulestID) != 0 and length(/SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:Payee) != 0 and /SOAP:Envelope/SOAP:Body/bank:CheckRequestElement/bank:Amount > 10"> <!-- <dp:accept/> --> <xsl:copy-of select="/"/> </xsl:when> <xsl:otherwise> <xsl:variable name="errtext" select="Invalid Input"/> <dp:xreject reason="$errtext"/> <xsl:message> <xsl:value-of select="$errtext"/> </xsl:message> </xsl:otherwise> </xsl:choose> <!-- <dp:accept/> <xsl:copy-of select="/"/> --> </xsl:when> <xsl:when test="$op=CheckResponseElement"> <dp:accept/> </xsl:when> <xsl:otherwise> <xsl:variable name="errtext" select="concat(Rejected illegal operation , $op)"/> <dp:xreject reason="$errtext"/> <xsl:message> <xsl:value-of select="$errtext"/> </xsl:message> </xsl:otherwise> </xsl:choose> </xsl:template> <xsl:template match="/"> <xsl:choose> <xsl:when test="dp:responding()"> <dp:accept/> </xsl:when> <xsl:otherwise> <xsl:choose> <xsl:when test="count(/SOAP:Envelope) > 0"> <xsl:call-template name="valid-operation"> <xsl:with-param name="op" select="local-name(/SOAP:Envelope/SOAP:Body/*)"/> </xsl:call-template> </xsl:when> <xsl:when test="count(/SOAP12:Envelope) > 0"> <xsl:call-template name="valid-operation"> <xsl:with-param name="op" select="local-name(/SOAP12:Envelope/SOAP12:Body/*)"/> </xsl:call-template> </xsl:when> <xsl:otherwise> <xsl:call-template name="valid-operation"> <xsl:with-param name="op" select="local-name(/*)"/> </xsl:call-template> </xsl:otherwise> </xsl:choose> </xsl:otherwise> </xsl:choose> </xsl:template></xsl:stylesheet>Release 3.6 3 - 21
  • 153. Multi-Protocol GatewayAction 3: VerifyThis action verifies the digital signature contained in the WS-Security header. It either accepts orrejects the message. Here is the configuration display for this action: Figure 3 - 16. Verify ConfigurationInput: tempvar1 This is set to tempvar1, the named context used by the preceeding action. Note that this could have been set to INPUT since this action would not execute if the validation before it failed. However, validation can sometimes change the message format, thus this action uses the result of the validation.Signer Certificate: (blank) This is left at the default (blank). The certificate will be retrieved from the message itself. If no certificate is included, verification will fail.Validation Credentials: SomeBanks This is set to the Validation Credential object SomeBanks. The validation credential object must have an exact copy of the certificate presented by the message or the verification will fail.Output: (blank) 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.3 - 22 Release 3.6
  • 154. RulesAction 5: 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 or verification. Here is the configuration page display for this action. Figure 3 - 17. Transform ConfigurationInput: tempvar4 This is set to tempvar4, 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: 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 OUTPUT This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is forwarded to the back end service. If none of the filters and authorization steps have rejected the message after it is validated, it is forwarded to the back end server.Release 3.6 3 - 23
  • 155. Multi-Protocol GatewayRule #2: Response RuleHere is an examination of the components of Rule #2. Note that this is a Response rule; it willonly handle messages sent by the server back to the client and will not handle messages sent to theservice by the client.This rule handles server responses to signed client messages. The response rule returns a signedmessage.Match Rule: CheckingA Match Rule examines the response message and determines whether or not the rule should berun against the message. In this case, the match rule examines the URL used by the server todetermine a match. As with the corresponding request rule, the response rule will not run unlessthe server submits the URL */SomeBank/services/checking.The gateway automatically validates the response message against the SOAP schemas, to insurethat no message that does not conform to the SOAP schemas will be sent to the calling client. ThisSOAP schema filtering is implied and no action needs to be created for it.Action 1: ValidateThe first custom action of Rule #2 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 3 - 18. Validate ConfigurationInput: INPUT This is set to INPUT, the special context representing the original message received by the service.3 - 24 Release 3.6
  • 156. RulesSchema 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:///SomeBankCheckService.xsd This is set to local:///SomeBankCheckService.xsd. The custom schema file has been uploaded to the device and placed in the local: directory.Output: (Blank) This is set to Blank. The system will automatically configure the correct output context.Action 3: SignThis action signs the response. The configuration display appears as follows. Figure 3 - 19. Sign Response ActionInput: INPUT This is the special INPUT context, containing the original message.Envelope Method: WS-Sec This method causes the signature to be placed in the SOAP header of the message, in accordance with the WS-Security specifications.Release 3.6 3 - 25
  • 157. Multi-Protocol GatewayMessage Type: SOAP The entire contents of the Body of the SOAP message will be signed.Key: SomeBanks The private cryptographic key contained in the SomeBanks key object will be used by the gateway to sign the message. The configuration of this object is covered below.Certificate: SomeBanks The public cryptographic certificate contained in the SomeBanks certificate object will be placed within the binary security token element. The configuration of this object is covered below.Output: OUTPUT This is the special OUTPUT context, sent back to the client.Here is an example response message.<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:bank="http://somebank.com"> <soapenv:Header> <wsse:Security soapenv:mustUnderstand="1"> <wsu:Timestamp wsu:Id="Timestamp-b4f998b3-6ed0-4b50-919b-9a15fd64d72d"> <wsu:Created>2005-07-22T00:49:11Z</wsu:Created> <wsu:Expires>2005-07-22T00:54:11Z</wsu:Expires> </wsu:Timestamp> <wsse:BinarySecurityToken wsu:Id="SecurityToken-579dc38e-8990-4b5f-a544-1c1cfb717d1d" Encoding-Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" Value-Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509">MIICBjCCAW+gAwIBAgIBADANBgkqhkiG9w0BAQUFADAOMQwwCgYDVQQDEwNDVE8wHhcNMDUwNTI3MDAyMzM3WhcNMDYwNTI3MDAyMzM3WjAOMQwwCgYDVQQDEwNDVE8wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMvT9vYN8iULhSQUHJXpduB6gFKHebqoUog9a+an2lOG5tKm4sgPLF2EEMZPiMLPxfK8wYmKZ+L3hp4O4Rl3UDNfhTIBebQeS0OIUQUKdOu/DnvPuISgf1f1UJYuI/ovRoohfLLiIIUBrAnDzR2EMb7vfMgb+pf/JcOtzfvROJ8jAgMBAAGjdDByMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFLtFYCU8LH0ro2lqI0g1t3bSV8C3MDYGA1UdIwQvMC2AFLtFYCU8LH0ro2lqI0g1t3bSV8C3oRKkEDAOMQwwCgYDVQQDEwNDVE+CAQAwCwYDVR0PBAQDAgK8MA0GCSqGSIb3DQEBBQUAA4GBAD+MdbIDf7UPY71khyCwCIj9c/ggPraNWMI34b+upJM+O8tI7s55qUDyfdY1/ne1mh7yOPW6l8Gg3aXw2k1Pkpefs+Ol5vwUvtSu53sKM4lZZbBywa3JoYzFfsmVPbyXx58UsxAfajryHtHN7110/C/I0RuZRgVhyW4s6eBu1/qj</wsse:BinarySecurityToken> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#Body-d4415997-3451-4f0c-bb03-c643f544f240"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>wWjxCIQokEOkVxBZ492DzLfDu3M=</DigestValue> </Reference> <Reference URI="#Timestamp-b4f998b3-6ed0-4b50-919b-9a15fd64d72d"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>+edo5TI4QIVN67wGXRSB4cbEB1Q=</DigestValue> </Reference> </SignedInfo>3 - 26 Release 3.6
  • 158. Rules<SignatureValue>ywkgMt9s038n3l1FYMZJkAjeuTaYnc+gyGLZobFnqqRsSrxEH+BhwoE77eZVHDQOKwvL21gF+RsT6Zs7A6VonMhE96E9beA3coBjBckwVIBmNH4QJYX1Wbd7DcfAOjpN8U4DlNvtxvmJApZ7uVqWbF85RBtYbq1CwtFiFDXfkF4=</SignatureValue> <KeyInfo> <wsse:SecurityTokenReference xmlns=""> <wsse:Reference URI="#SecurityToken-579dc38e-8990-4b5f-a544-1c1cfb717d1d" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509"/> </wsse:SecurityTokenReference> </KeyInfo> </Signature> </wsse:Security> </soapenv:Header> <soapenv:Body wsu:Id="Body-d4415997-3451-4f0c-bb03-c643f544f240"> <bank:CheckResponseElement> <bank:TransactionNum>74494</bank:TransactionNum> <bank:CheckNum>23423</bank:CheckNum> <bank:CheckType xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">P</bank:CheckType> <bank:PayorAccountID xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">8458jf8757275234</bank:PayorAccoun-tID> <bank:Payee xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Elmer Fudd</bank:Payee> <bank:Amount xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">999.00</bank:Amount> </bank:CheckResponseElement> </soapenv:Body></soapenv:Envelope>Release 3.6 3 - 27
  • 159. Multi-Protocol GatewayLoggingThis example employs a custom log target, which captures messages generated by the services(such as the Multi-Protocol Gateway, the assigned Processing Policy, and the Front Side ProtocolHandlers) handling the SomeBank Checking web services traffic. Here is the configurationdisplay of the custom Log Target object Main page: Figure 3 - 20. Log Target Main ConfigurationType: syslog This log target sends captured log messages to a syslog process elsewhere on the network..Local Identifier: DP The Local Identifier embedded in the syslog message. Syslog management tools can filter on this value.Remote Host Address: 10.10.100.3 This is the IP address of the remote syslog utility.Remote Port: 263 The syslog listens on port 263.Syslog Facility: user The log entries are sent to the syslog with this facility.Backup Log: default-log3 - 28 Release 3.6
  • 160. Logging In the event the syslog facility cannot be reached, this back up log will capture log messages.Note that when a device is rebooted (as opposed to the firmware reloaded), all temporary files onthe filesystem are erased. For this reason, log files are often moved off the device for storage.Using a remote logging utility is a common strategy.Object FiltersLog targets capture messages by Object Filters and Event Subscriptions. Object filters determinewhat messages will be captured according to source object. Figure 3 - 21. Log Target Object Filter ConfigurationOnly messages generated by the objects of the classes shown with the names shown are eligible forcapture.Release 3.6 3 - 29
  • 161. Multi-Protocol GatewayEvent SubscriptionsEvent Subscrptions determine at what level of priority messages are captured. Here is theconfiguration display for this example: Figure 3 - 22. 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.3 - 30 Release 3.6
  • 162. SSL CommunicationsSSL CommunicationsIn this scenario, the communication channels between the DataPower service and the requestingclient can use SSL to encrypt communications. The HTTPS Front Side Handler configurationpage shows the SSL Proxy used for communications. Figure 3 - 23. SSL Server Crypto Profile settingSSL Proxy ProfileHere is the configuration of the selected SSL Proxy Profile. Figure 3 - 24. SSL Proxy Profile ConfigurationDirection: reverse This indicates that this is server rather than a client profile. As such, only a Reverse (Server) Crypto Profile is required.Reverse (Server) Crypto Profile: SomeBanks The SomeBanks profile is selected. It is covered in detail in the next section.All other values are left at the default.Release 3.6 3 - 31
  • 163. Multi-Protocol GatewayCrypto ProfileHere is the configuration of the Crypto Profile: Figure 3 - 25. Crypto Profile ConfigurationIdentification Credentials: SomeBanks These credentials identify the private cryptographic key and public cryptographic certificate used by this service to identify itself to clients. A browser client connecting to this service will be given a copy of the certificate identified by these credentials for use in SSL communications.Validation Credentials: None This setting indicates that the service will not request a certificate of authority to identify the requesting clients.All other inputs are set to the default, requiring no configuration action. With SSL enabled, thebrowsers must use HTTPS rather than HTTP to communicate with the DataPower system.3 - 32 Release 3.6
  • 164. SSL CommunicationsCrypto Identification CredentialsThe SSL Crypto Profile relies upon the Crypto Identification Credential SomeBank. Here is theconfiguration of the Identification Credential object: Figure 3 - 26. Crypto Identification Credentials ConfigurationThe Key and Certificate objects identify the private key and public certificate used for securecommunications over an SSL channel. Both of those objects were generated automatically on theDataPower system using the Cryptographic Key tool. Those objects can also use private keys andcertificates uploaded to the device.Release 3.6 3 - 33
  • 165. Multi-Protocol GatewayCrypto KeyHere is the configuration of the Key object: Figure 3 - 27. Crypto Key ConfigurationThe object points at a key file stored in the encrypted cert: directory on the local flash filesystem.Files placed in the cert: directory can be read by the system, but cannot be copied or moved in anyway.Crypto CertificateHere is the configuration of the Certificate object: Figure 3 - 28. Crypto Certificate Configuration3 - 34 Release 3.6
  • 166. Validation CredentialThis object points to a certificate file stored on the local flash filesystem, in the encrypted cert:directory. Files placed in the cert: directory can be read by the system, but cannot be copied ormoved in any way.Validation CredentialThe Sign processing action employs a Validation Credential, to verify that the certificate presentedby the remote client is valid. Here is the configuration of the Validation Credential used. Figure 3 - 29. Validation Credential ConfigurationNote that this uses the same SomeBanks certificate object as is used in SSL communications. Thisis not often the case; the Validation Credential would use a different certificate.Release 3.6 3 - 35
  • 167. Multi-Protocol Gateway3 - 36 Release 3.6
  • 168. Chapter 4 Example Web Application FirewallThis example configuration implements a Web Application Firewall protecting a human resourcesweb portal benefits administration service, allowing employees to request services from humanresources through a web browser interface. Because the back end service also supports a WebServices endpoint (XML over HTTP), the Web Application Firewall also handles XML traffic.The Web Application Firewall service consists of the following component objects.Web Application Firewall The top level service that provides a range of proxy and security services to web-based applications. Web browser clients connect directly to this firewall, rather than the real back end service. References an Application Security Policy.Application Security Policy Establishes the security policy to enforce. References Web Request Profile, Web Response Profile and Error Policy.Error Policy Establishes a policy for handling errors. In this example, custom error messages are returned to the browser client.Web Request Profile Establishes a profile, or policy, providing content filtering, rate limiting, error handling and other security services for requests originating from Web clients. References Error Policy, Rate Limiter and Name-Value Profile objects.Web Response Profile Establishes a profile, or policy, providing filtering, error handling and other security services for responses originating from Web application servers. References Error Policy object.Session Management Policy Establishes session management. Not used in this example.Rate Limiter Limits request traffic rates.Name-Value Profile Enforces filters on URL-encoded name-value pairs, such as Query String parameters, URL-encoded HTTP Post body content, or HTTP headers. 4-1
  • 169. Example Web Application FirewallWeb Application FirewallThis Web Application Firewall offers: • Destination Service Proxy, masking back end resources • Rate Limiting, preventing Denial of Service attacks • URL-Encoded Name-Value Input Processing, protecting against malicious or spooked content posting • HTTP Protocol Filtering, removing unwanted or dangerous headers • Threat Protection, such as SQL Injection filtering, protecting the back end database system • Error Handling, returning a custom error message when needed • XML Content Processing and Dynamic Routing • SSL Termination and Instantiation Figure 4 - 1. Web Application Firewall Configuration (partial)Configuration ValuesName XycoHR This is a unique name for this object.SSL Proxy Profile XycoMultiSvc Communications with the back end server will employ SSL in accordance with the configured Profile. The profile specifies the Cryptographic Keys and Certificates used to negotiate SSL connections. If this field had been left4-2 Release 3.6
  • 170. Web Application Firewall blank, the Firewall would not use SSL to communicate with the back end service.XML Manager default An XML Manager manages the compilation and caching of XSL stylesheets, the caching of XML documents, and provides configuration constraints on the size and parsing depth of XML documents. A default Manager is used if you do not create one. Because this Web Application Firewall does handle XML traffic, the selection of an XML Manager could change the handling of XML requests. A Web Application Firewall that does not handle XML content would not be affected by the XML Manager selected.Error Policy none If any part of the Application Security Policy selected below is violated, the service will handle the violation, or error, in accordance with the rules set forth in the selected Error Policy. This is the default policy that will handle the response sent to the client. An Application Security Policy can also establish an Error Policy; the Error Policy established by the Application Security Policy overrides this default selection. In the case of this service, Error Handling policies are set within the Security Policy, for greater control of execution.Security Policy XycoHR This is the security policy enforced by this firewall. See Application Security Policy in this chapter for more information. Note that this is required.Back Side SettingsRemote Host 10.10.36.11 The name or IP address of the web application (backend) server. All requests handled by this service will be forwarded to this address, unless an error occurs or rate limiting policies do not allow forwarding. When XML traffic is submitted to this Web Application Firewall, the remote host is dynamically determined by the operation requsted.Remote Port 2085 The TCP port number of the web application (backend) server. All requests handled by this service will be forwarded to this port, unless an error occurs or rate limiting policies do not allow forwarding. When XML traffic is submitted to this Web Application Firewall, the remote port is dynamically determined by the operation requsted.Source AddressesLocal IP Address 0.0.0.0 The address on which the service listens. The default of 0.0.0.0 indicates that the service is active on all addresses.Port Number 3011 An integer (within the range 1 through 65535, with a default of 80) that specifies the port monitored by the Firewall.Release 3.6 4-3
  • 171. Example Web Application FirewallSSL On The service will act as an SSL server for client communications and employ the SSL Proxy Profile configured for the service to handle these communications. Note that the SSL Proxy Profile is configured to handle both Forward and Reverse SSL connections. Because of this, the entire end-to-end transaction is conducted with SSL protection.Application Security PolicyAn Application Security Policy establishes the rules used to enforce security for a WebApplication Firewall service. This policy employs Request Maps, Response Maps, and ErrorMaps. Each of these maps, in turn, matches a Web Request Profile, Web Response Profile, orError Policy, as the case may be, to client requests based on a set of matching criteria. The Profilesselected then provide the detailed security configuration. Figure 4 - 2. Application Security Policy Main Configuration PageInputsName XycoHR This is the name that appears in all Policy listings.Request MapsRequest Maps select Web Request Profiles to execute on client requests based on a set of matchingcriteria. If the client request meets the matching criteria, the corresponding Web Request Profileexecutes. At least one Request Map entry is required. This Security Policy employs two RequestProfiles, one for standard HTML forms input originating from a browser, and one for XML trafficsubmitted by a Web Services client.4-4 Release 3.6
  • 172. Application Security Policy Figure 4 - 3. Request Map configurationConfiguration ValuesMatch:Profile HTMLForms:Xyco-form-request The match rule HTMLForms selects requests for handling by the corresponding Xyco-form-request Web Request Profile. The HTMLForms Match Rule is configured as follows: Figure 4 - 4. HTMLForms Match Rule configuration All requests with the URI /forms will be handled by the Xyco-form-request Request map. The configuration of the Web Request Profile is covered in detail below.Match:Profile services:XycoHR-xml The match rule services selects requests for handling by the corresponding XycoHR-xml Web Request Profile. The services Match Rule is configured as follows:Release 3.6 4-5
  • 173. Example Web Application Firewall Figure 4 - 5. services Match Rule Configuration All requests with the URI /services will be handled by the XycoHR-xml Request Profile. The configuration of the Web Request Profile is covered in detail below.Response MapsResponse Maps select Web Response Profiles to execute on server responses based on a set ofmatching criteria. If the server response meets the matching criteria, the corresponding WebResponse Profile executes. At least one Response Map entry is required. In this case, allresponses are handled by a single Response Profile. Figure 4 - 6. Application Security Policy Response MapsInputsMatch:Profile Any:Xyco-form-response The match rule Any selects requests for handling by the corresponding Xyco- form-responseWeb Response Profile. The Any Match Rule is configured as follows:4-6 Release 3.6
  • 174. Application Security Policy Figure 4 - 7. Any Match Rule configuration All responses will be handled by the Xyco-form-response Response Profile. The configuration of the Web Response Profile is covered in detail below.Error MapsError Maps select a Processing Rule to execute on errors based on a set of matching criteria. If theerror meets the matching criteria, the corresponding Processing Rule executes. In this case, theSecurity Policy uses one Error Rule to handle HTML Forms submissions from a browser andanother rule to handle XML content submitted from a Web Services client. Figure 4 - 8. Error Map ConfigurationConfiguration ValuesMatch:Rule HTMLForms:WAFW-custom-error The HTMLForms Match rule (covered above) selects errors for processing by the WAFW-custom-error Processing Rule. Here is the configuration of the WAFW-custom-error Processing Rule.Release 3.6 4-7
  • 175. Example Web Application Firewall Figure 4 - 9. Processing Rule Configuration This rule executes two Actions. First the Rule executes the WAFW-error- headers action, which resets the HTTP Error Response code to 200, rather than 500. This causes the browser to display the custom error page, rather than the browser’s default 500 page. Figure 4 - 10. WAFW-error-headers Configuration4-8 Release 3.6
  • 176. Application Security Policy The second action constructs the HTML sent to the browser for display in the event of an error. Figure 4 - 11. wafw-error-return Action Configuration Here is the stylesheet used to generate the error message sent to the browser:<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig"> <xsl:output method="html" version="1.0"/> <xsl:template match="/"><html><head><title>Portal Error Encountered</title></head><body><p>The server has encountered some difficulty returning the requested page. If you are receiving this message, it is likelythat you:<ul><li>Mistyped the input</li><li>Let your session expire</li><li>Have not established the required SSL connection</li></ul></p> <!-- <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>Release 3.6 4-9
  • 177. Example Web Application Firewall </html> </xsl:template></xsl:stylesheet>Match:Rule services:WAFW-soap-fault The Match Rule services selects errors for processing by the WAFW-soap-fault Processing Rule. The Match Rule configuration is shown above. This URL is used by Web Services clients submitting XML requests to the portal. Here is the configuration of the Processing Rule: Figure 4 - 12. WAFW-soap-fault Processing Rule Configuration This rule executes one Action to create a custom error return to Web Services agents. Here is the configuraton of the WAFW-soap-fault action.4 - 10 Release 3.6
  • 178. Application Security Policy Figure 4 - 13. WAFW-soap-fault Action Configuration Here is the stylesheet executed by this Action to produce the error returned to the calling agent.<?xml version="1.0" encoding="utf-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig"> <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 web services submission. Please submit a valid request or notify yournetwork administrator of this error and reference the faultcode number.</env:faultstring> </env:Fault> </env:Body> </env:Envelope> </xsl:template></xsl:stylesheet>Release 3.6 4 - 11
  • 179. Example Web Application FirewallError PolicyA Web Application Firewall service can employ an Error Policy to handle errors returned by theback end service. An Error Policy can take action on the error, changing the error responsereceived by the requesting client. This Firewall uses no Error Policy at the Firewall level.Web Request ProfilesThis Web Application Firewall employs two Web Request Profiles to provide security. Each willbe examined in detail here.HTML Form RequestsThe WAFW-form-request Profile handles content posted from a form by a Web browser. Figure 4 - 14. Main Profile ConfigurationConfiguration ValuesStyle admission This is an admission style Profile. The requirements of this Profile must be met or the request does not pass through to the back end.4 - 12 Release 3.6
  • 180. Web Request Profiles Figure 4 - 15. Request Profile ConfigurationAllow SSL allow This Request Profile will allow SSL communications. Because the Source Addresses for the Web Application Firewall are set to require SSL, this value must be at least allow.AAA Policy none No Authentication and Authorization is enforced by this Firewall.Rate Limiting RateShaper The RateShaper Rate Limiting object is selected to provide rate limiting of requests to this Firewall. The configuration of the Rate Limiting object is covered in greater detail below.Access Control List none No restrictions by IP address are applied.Error Policy none No Error Policy is applied at this level. Note that the Application Security Policy does include Error Maps.Session Policy none This relatively simple Benefits service requires no session handling.Content-Type List various HTTP requests from browsers will be restricted to the two Content Types listed. Any other Content-Type will result in the rejection of the request by the Firewall.Release 3.6 4 - 13
  • 181. Example Web Application Firewall Figure 4 - 16. Request Profile HTTP Methods ConfigurationMethods Various The checkboxes establish the HTTP Methods allowed to pass to the back end service by this Firewall. The standard defaults (POST, GET, HEAD) are left in place.Versions Various Both HTTP/1.0 and HTTP/1.1 are supported by the back end service, so both are allowed by this Request Profile. This is the default. Figure 4 - 17. Name Value ConfigurationHeader Name Value Profile HeaderFilter The names and values of HTTP headers will be evaluated in accordance with the HeaderFilter Name Value Profile. This provides security for malicious HTTP headers. The configuration of the Name Value Profile is covered in detail under Name Value Profiles below.4 - 14 Release 3.6
  • 182. Web Request ProfilesURL-Encoded Body Name-Value Profile XycoPost The URL-Encoded Post body contents will be evaluated in accordance with the XycoPost Name Value Profile. This provides security for malicious body content. The configuration of the Name Value Profile is covered in detail under Name Value Profiles below.Allow Query String deny Query strings in the URL are not allowed. The presence of a Query String (something after a ? in the URL) will cause the entire request to be rejected. This is done to protect the back end system from attempting to consume a malicioius Query String. Figure 4 - 18. Cookie ConfigurationAllow Cookies deny Cookies will be rejected by this Profile. Requests containing cookies will be rejected completely, to protect the back end system from malicious content. Figure 4 - 19. Threat Protection ConfigurationRelease 3.6 4 - 15
  • 183. Example Web Application FirewallSQL Injection Filteron This value is set to on (rather than the default off) to cause the Firewall to scan all inbound values for SQL Injection threats (such as a form input that resembles the string ‘select * from table). All other default values are left in place, to provide the standard threat protection.XML-Based RequestsThe XycoHR-xml Profile handles XML content posted by a Web Services client. Figure 4 - 20. Main Profile ConfigurationConfiguration ValuesStyle admission This is an admission style Profile. The requirements of this Profile must be met or the request does not pass through to the back end. Figure 4 - 21. Request Profile Configuration4 - 16 Release 3.6
  • 184. Web Request ProfilesAllow SSL allow This Request Profile will allow SSL communications. Because the Source Addresses for the Web Application Firewall are set to require SSL, this value must be at least allow.AAA Policy none No Authentication and Authorization is enforced by this Firewall.Rate Limiting RateShaper The RateShaper Rate Limiting object is selected to provide rate limiting of requests to this Firewall. The configuration of the Rate Limiting object is covered in greater detail below.Access Control List none No restrictions by IP address are applied.Error Policy none No Error Policy is applied at this level. Note that the Application Security Policy does include Error Maps.Session Policy none This relatively simple Benefits service requires no session handling.Content-Type List text/xml Only requests with Content-Type of text/xml will be allowed. Any other Content-Type will result in the rejection of the request by the Firewall. This protects the Web Services endpoint from inadvertent (or malicious) posts from browsers and eliminates the possibility of attachments. Figure 4 - 22. Request Profile HTTP Methods ConfigurationMethods Various The checkboxes establish the HTTP Methods allowed to pass to the back end service by this Firewall. The standard defaults (POST, GET, HEAD) are left in place.Release 3.6 4 - 17
  • 185. Example Web Application FirewallVersions Various Both HTTP/1.0 and HTTP/1.1 are supported by the back end service, so both are allowed by this Request Profile. This is the default. Figure 4 - 23. Processing ConfigurationXML Processing Well Formed XML When the submission contains XML, the content will be checked for well- formedness. In addition, the XML Transformation Rule selected will run against the submitted request.XML Transformation Rule XycoHRWeb_Rule_0 This rule applies a series of filters and an Authentication and Authorization policy to the request content. See the section in this Guide entitled Rules in the Scenario A: Web Services section of the Human Resources Web Portal chapter of this Guide for more information about this Rule. Note that this is a fully featured standard Processing Rule using a number of actions to provide the kind of security that an XML Firewall might provide. Figure 4 - 24. Name Value ConfigurationHeader Name Value Profile HeaderFilter The names and values of HTTP headers will be evaluated in accordance with the HeaderFilter Name Value Profile. This provides security for malicious HTTP headers. The configuration of the Name Value Profile is covered in detail under Name Value Profiles below.4 - 18 Release 3.6
  • 186. Web Request ProfilesURL-Encoded Body Name-Value Profile none This Request Profile uses no Name Value Profile to evaluate HTTP Post body content, in large part because the body is XML and not URL-Encoded, because the content is not being posted by a browser.Allow Query String deny Query strings in the URL are not allowed. The presence of a Query String (something after a ? in the URL) will cause the entire request to be rejected. This is done to protect the back end system from attempting to consume a malicioius Query String. Figure 4 - 25. Cookie ConfigurationAllow Cookies deny Cookies will be rejected by this Profile. Requests containing cookies will be rejected completely, to protect the back end system from malicious content. Figure 4 - 26. Threat Protection ConfigurationSQL Injection Filteron This value is set to on (rather than the default off) to cause the Firewall to scan all inbound values for SQL Injection threats (such as a form input thatRelease 3.6 4 - 19
  • 187. Example Web Application Firewall resembles the string ‘select * from table). All other default values are left in place, to provide the standard threat protection.Web Response ProfileA Web Response Profile establishes the security policy applied to responses returned fromapplication servers. This Security Policy uses one Response Profile to handle all responses,regardless of calling client (browser or Web Services client). This Web Response Profile does thefollowing: • Filter HTTP Methods • Filter HTTP header values • Provide Service Threat Protection, by managing response sizesConfiguration ValuesName Xyco-form-response This name appears in the catalog listing and in all drop down lists of available Web Response Profiles.Style admission All responses must pass the evaluations applied by this Profile or the transaction will be aborted by the Firewall.4 - 20 Release 3.6
  • 188. Web Response Profile Figure 4 - 27. Response Profile ConfigurationError Policy none Errors generated by the Response are not handled by this profile. Any Error conditions sent by the back end services are passed through to the calling client.Content-Type List .* All Content-Types will be allowed by this Response Profile. This is done because the back end application generates known Types. Figure 4 - 28. Codes and Versions ConfigurationResponse Codes Defaults + Server ErrorRelease 3.6 4 - 21
  • 189. The ability to pass the Server Error (HTTP 500) Response Code is added to the default Response Codes allowed by the Firewall. Figure 4 - 29. Name Value ConfigurationHeader Name Value Profile Suppressor The Suppressor Name Value Profile is used to control HTTP Headers passed back to the calling client. The configuration of this Profile is covered in detail below. Figure 4 - 30. Threat Protection ConfigurationMin Max Sizes defaults The default values are used for Threat Protection. An empty response will not be passed to the calling client, nor a very large response.
  • 190. Rate LimiterRate LimiterA Rate Limiter object establishes policies used to control the rate at which requests are received bya Web Application Firewall. When the rate exceeds the limits set, the Limiter can reject requests,post notification or shape, or delay traffic to remain within the limits set. A Rate Limiter object isused by a Web Request Profile.InputsName RateShaper This is the name that appears in all catalog lists and Rate Limiter drop down lists.Rate 20 This Limiter will allow only 20 transactions per second from any single distinct user (determined by IP Address) Because the service is not used very often, and because browser clients should actually only use the service perhaps once a day, this number is set artificially low.Enforcement Style shape Delay requests as much as possible to lower the transaction rate to the configured limit. Once too many messages are buffered, creating a low memory state, transactions are rejected until rate drops. The ability to shape transactions is limited when concurrent connections are high.Concurrent Connections The number of simultaneous connections allowed per user. Set to 0 to disable this enforcement. A single client may not instantiate any concurrent connections. This is to prevent denial of service attacks.Release 3.6 4 - 23
  • 191. Example Web Application FirewallName Value ProfileWeb applications communicate with clients using the various mechanisms of the HTTP protocol.The protocol provides for HTTP headers, cookie values, url-encoded query strings, and url-encoded request messages. Each of these kinds of communication mechanisms operate using astring of name-value pairs (such as token=valueA&token1=valueB&broken=bomb). To provideintegrity and security for such an application, it is necessary to inspect and take action on thesenames and values. A Name Value Profile provides a means to implement this inspection andaction configuration.A Name Value Profile filters names, and for names that match a given expression, sets constraintson the corresponding values, again expressed as a match expression. The Name Value Profileworks by comparing each name in a Name Value pair to all entries in a configured Validation List.If a match is found, the corresponding value is compared to a corresponding match expression. Ifa match is found, the pair passes. If no match is found, one of several actions is taken.For example, given the URL-encoded string “token=valueA&token1=valueB&broken=bomb”,only names that contain the substring “token” will be accepted, and those that are accepted musthave a value that contains the string “value”. The Name Value Pair with a name of “broken” canoptionally be passed through, stripped from the string or replaced with a known value, or the entirestring can be rejected (in which case, the profile will fail to pass).This Web Application Firewall uses several Name Value Profiles to enforce security.HeaderFilter Profile Figure 4 - 31. HeaderFilter General ConfigurationConfiguration ValuesNo Match Policy Passthrough This Profile is configured to pass any unmatched Name Value pairs evaluated by this profile through to the back end service. This allows custom headers to pass through to the back end.4 - 24 Release 3.6
  • 192. Name Value Profile Figure 4 - 32. Name Value Profile Configuration Page Figure 4 - 33. Validation Entry ConfigurationName Expression ^X-(.*)$ Any Header Name that begins with the characters “X-”, followed by any string of characters, will be matched.Value Constraint ^[a-zA-Z0-9]+$ Headers that match the above expression must have a value that begins with either a capital or small letter alphabetic character or a number.Failure Policy strip If the Name Value pair does not match the Value Constraint, the pair is stripped from the request.Name Expression ^Y-(.*)$ Any Header Name that begins with the characters “Y-”, followed by any string of characters, will be matched.Value Constraint (.*)-(.*) Headers that match the above expression must have a value that includes a - character.Failure Policy setRelease 3.6 4 - 25
  • 193. Example Web Application Firewall If the Name Value pair does not match the Value Constraint, the value of the matching header is set to “BogieAlert”. The back end application knows that if this value appears in the headers that the request is bogus and a tracing process is set in motion.Suppressor Profile Figure 4 - 34. HeaderFilter General ConfigurationConfiguration ValuesNo Match Policy strip This Profile is configured to strip any unmatched Name Value pairs evaluated by this profile from the response from the back end service. This prevents man-in-the-middle hijacking of the client, leading to subsequent phishing attacks. Figure 4 - 35. Name Value Profile Configuration Page4 - 26 Release 3.6
  • 194. Name Value Profile Figure 4 - 36. Validation Entry ConfigurationName Expression Host Any Header Name that contains “Host” will be matched.Value Constraint unlikely Headers that match the above expression must contain the string “unlikely” or the failure policy is executed.Failure Policy strip If the Name Value pair does not match the Value Constraint, the pair is stripped from the request.Name Expression Server Any Header Name that contains “Server” will be matched.Value Constraint unlikely Headers that match the above expression must contain the string “unlikely” or the failure policy is executed.Failure Policy error If the Name Value pair does not match the Value Constraint, the Response Profile throws an error for consumption by the Security Policy.Name Expression Warning Any Header Name that contains “Warning” will be matched.Release 3.6 4 - 27
  • 195. Example Web Application FirewallValue Constraint unlikely Headers that match the above expression must contain the string “unlikely” or the failure policy is executed.Failure Policy strip If the Name Value pair does not match the Value Constraint, the pair is stripped from the request.XycoPost Profile Figure 4 - 37. XycoPost General ConfigurationConfiguration ValuesNo Match Policy strip This Profile is configured to strip any unmatched Name Value pairs evaluated by this profile from the response from the back end service. This prevents attempts to add fields to the inbound form. Figure 4 - 38. Name Value Profile Configuration Page4 - 28 Release 3.6
  • 196. Name Value ProfileName Expression Date Any Header Name that contains “Date” will be matched.Value Constraint ^d{1,2}(.*)d{1,2}1d{4}$ The values corresponding to the Name Expression must conform to the above date format expression or the failure policy is executed.Failure Policy error If the Name Value pair does not match the Value Constraint, an error is generated, to be handled by the Security Policy Error Map.Name Expression Department, ID and Password Header Names that contains the Name Expression will be matched.Value Constraint .* The value cannot be null (empty) or the failure policy will execute.Failure Policy error If the Name Value pair does not match the Value Constraint, an error is generated, to be handled by the Security Policy Error Map.Name Expressions Name and Service Header Names that contains the Name Expression will be matched.Value Constraint ^[a-zA-Z]+$ The value must begin with an alphabetic character (small or capital) or the failure policy will execute.Failure Policy error If the Name Value pair does not match the Value Constraint, an error is generated, to be handled by the Security Policy Error Map.Release 3.6 4 - 29
  • 197. Example Web Application Firewall4 - 30 Release 3.6
  • 198. Chapter 5 SOAP with AttachmentsThis example configuration demonstrates a number of different methods for handling SOAPmessages that include attachments (SwA). The Firewall service performs any one of the followingmanipulations on attachments: • Send stripped attachment to third party agent, return message without attachments. • Process root SOAP XML document using attached XSL • Return the binary attachment • Attach a requested file to the message and return SOAP with Attachment package • Sign a message with attachments • Verify signature of a signed message with attachments • Strip attachment, place in zip file, add external file to zip, return SOAP with zip attached • Extract and return a file from an attached zip file • Pass a DIME-formatted message through the firewallThe firewall service is configured as a loopback proxy; the service returns the results of themanipulation of the SwA message directly to the calling client without involving a back endserver. 5-1
  • 199. SOAP with AttachmentsXML FirewallThe XML Firewall Service configuration page appears as shown here. Figure 5 - 1. Web Services Firewall ConfigurationThese are the field values.Firewall Name: Attachments 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: Loopback proxy The firewall returns the result of any policy processing directly to the client. No back end server is involved.XML Manager: Default The default is left in place.Firewall Policy: Tache The custom policy built for this service, Tache, is selected. This policy is covered in detail below.URL Rewrite Policy: None The default is left in place. The URLs sent by the clients are not altered in any way.5-2 Release 3.6
  • 200. XML FirewallBack EndResponse 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: 2071 The automatically assigned value of 2071 is used. This could be altered to any value not used by another service on the current device. All traffic bound for this service must use port number 2071. The SOAP HTTP URL resembles http://10.10.13.35:2071/strip.SSL Server Crypto Profile: None Communication with the front end clients will not employ SSL.Request Type: SOAP 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 : Allow Attachments are allowed. This setting must be changed from the default (strip) or the firewall will remove the attachments to the message automatically.There are no monitors configured for this demonstration firewall.Release 3.6 5-3
  • 201. SOAP with AttachmentsFirewall PolicyHere is the graphic representation of the firewall policy used for this implementation. Figure 5 - 2. Tache 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.5-4 Release 3.6
  • 202. Firewall PolicyRulesOverviewHere is an overview of the rules used in this policy.Rule 1 Two Way Rule Matching */strip This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Fetch the binary attachment from the message 2 Send the attachment to a third party agent 3 Strip off attachments 4 Return the message without attachmentsRule 2 Two Way Rule Matching */procload This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Fetch the text attachment from the message 2 Strip off the attachment 3) Transform the root message with the XSL instructions captured from the attachment and return the transformed messageRule 3 Two Way Rule Matching */returnattach This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Fetch the binary attachment 2 Return the binary attachmentRule 4 Two Way Rule Matching */clipon This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Fetch an image file from an external location 2 Attach the image file to the submitted XML document 3 Return the original message with the attachmentRule 5 Two Way Rule Matching */sign This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Sign the message with attachments 2 Return the signed message with attachmentsRule 6 Two Way Rule Matching */verify This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Verify the signature of the signed message with attachments 2) Return the verified messageRelease 3.6 5-5
  • 203. SOAP with AttachmentsRule 7 Two Way Rule Matching */zipup This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Fetch the binary attachment from the message 2) Strip off the attachment 3)Insert the fetched attachment into a zip archive and attach it to the message 4)Fetch an additional binary file from an external source 5)Insert the fetched file into the zip archive created above 6)Return the message with the zip file attachedRule 8 Two Way Rule Matching */zipout This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Fetch a file from inside the zip archive attached to the message 2) Return the extracted file.Rule 9 Two Way Rule Matching */passdime This rule runs when the client sends the matching URL. The rule performs the following actions: 1 Set the value of the var://local/_extension/attachment-format variable to application/dime to enable pass through of DIME messages 2) Pass through the DIME message.5-6 Release 3.6
  • 204. Firewall PolicyRule #1: Two Way RuleThis rule relies upon the existence, in the submitted message, of an attachment with the Content-ID of bin. Here is an example message (docwsnd.swa) suited to this rule: --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <main> <?xml version=1.0 ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <sndt:soundtrack xmlns:sndt="http://schemas.sndpups.com/soundtracks"> <sndt:name>Madrid Race 5 announcer</sndt:name> <sndt:desc>BeneBene rounds the final turn and wins by one length</sndt:desc> </sndt:soundtrack> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: audio/mpeg Content-Transfer-Encoding: binary Content-ID: <bin> {binary content omitted} --MIME_boundary--Match Rule: stripA Match Rule examines the inbound message and determines whether or not the rule should be 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 5 - 3. strip Match Rule ConfigurationThe client must use the URL */strip or this rule will not be applied to the message. Note that theexpression * means “any substring of any characters.”Release 3.6 5-7
  • 205. SOAP with AttachmentsAction 0: Implied 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.Action 1: FetchThe first custom action of Rule 1 fetches the binary attachment from the SwA message. Here is theconfiguration of this action: Figure 5 - 4. Fetch ConfigurationSource: cid:bin A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL cid:bin indicates that the target of the fetch is the message attachment with the Content-ID of bin. Refer to the example message above.Output: fresult This is set to fresult. This context will contain the binary attachment.Action 2: Results AsynchThis action sends the contents of a named context (fresult) to a destination. The send isasynchronous; the rule does not wait for a result of the action to continue executing. Here is theconfiguration display for this action: Figure 5 - 5. Results Asynch Configuration5-8 Release 3.6
  • 206. Firewall PolicyInput: fresult This is set to fresult, the named context used by the preceeding action. This context contains the binary attachment data.Send Results Asynchronously: On This setting causes the system to send the contents of the named input context to the Destination given. Processing of the rule continues without waiting for any kind of result of this action. It can, for example, fail with no impact on the execution of the rule.Destination: http://myhost.mydomain.com:1111 The content will be send to the URL given.There is no Output context for this action because there is no result.Action 3: Strip AttachmentsThis action strips off all attachments from the message. Here is the configuration display for thisaction: Figure 5 - 6. Strip Attachment ConfigurationInput: INPUT This is set to INPUT, the special context that contains the original message.Attachment URI: blank This input is left blank. This indicates that all attachments are removed from the SwA message. Once removed, the attachments cannot be again retrieved.This action has no Output context because it returns nothing. It operates only on the Input context.Release 3.6 5-9
  • 207. SOAP with AttachmentsAction 4: TransformThis tranform action serves to connect the last context that contained the possibly altered messageto any actions that follow. The policy configuration page automatically created this action. Hereis the configuration page display for this action. Figure 5 - 7. Transform ConfigurationInput: INPUT This is set to INPUT, the special context containing the original message. Note that the Strip Attachments action has altered this message by removing the attachments.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 OUTPUT This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is returned to the client. In this case, it is the original message without attachments.5 - 10 Release 3.6
  • 208. Firewall PolicyRule #2: Two Way RuleThis rule relies upon the existence, in the submitted message, of an attachment with the Content-ID of xsl. The contents of the attachment are used to transform the root part of the message. Hereis an example message (orderform.swa) suited to this rule:--MIME_boundaryContent-type: text/xml; charset=UTF-8Transfer-Encoding: 8bitContent-ID: <order><?xml version=1.0 ?><SOAP-ENV:EnvelopeSOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><cbc:Order xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0"xmlns:cur="urn:oasis:names:specification:ubl:schema:xsd:CurrencyCode-1.0" xmlns:cac="urn:oasis:names:specifica-tion:ubl:schema:xsd:CommonAggregateComponents-1.0"> <cbc:BuyersID>20031234-1</cbc:BuyersID> <cbc:IssueDate>2003-01-23</cbc:IssueDate> <cbc:LineExtensionTotalAmount amountCurrencyCodeListVersionID="0.3" amountCurren-cyID="USD">438.50</cbc:LineExtensionTotalAmount> <cac:BuyerParty> {omitted content} </cac:BuyerParty> <cac:SellerParty> {omitted content} </cac:SellerParty> {omitted content} <cac:OrderLine> {omitted content} <cac:LineItem> <cac:BuyersID>7</cac:BuyersID> <cbc:Quantity quantityUnitCode="UNIT">12</cbc:Quantity> <cbc:LineExtensionAmount amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">6.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Description>Mousepad, blue</cbc:Description> <cac:SellersItemIdentification> <cac:ID>21457-3</cac:ID> </cac:SellersItemIdentification> <cac:BasePrice> <cbc:PriceAmount amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">.50</cbc:PriceAmount> </cac:BasePrice> </cac:Item> </cac:LineItem> </cac:OrderLine></cbc:Order></SOAP-ENV:Body></SOAP-ENV:Envelope>--MIME_boundaryContent-type: text/xml; charset=UTF-8Transfer-Encoding: 8bitContent-ID: <xsl><?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/Release 3.6 5 - 11
  • 209. SOAP with Attachmentsextensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig"> <xsl:output method="xml"/> <xsl:template match="/"><joe:Order xmlns:joe="http://schemas.joes.com/schemas"> <joe:OrderNo>25</joe:OrderNo> <joe:OrderDate> <xsl:value-of select="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=Order]/*[local-name()=IssueDate]"/> </joe:OrderDate> <joe:BuyerID> <xsl:value-of select="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=Order]/*[local-name()=BuyersID]"/> </joe:BuyerID> <xsl:apply-templates select="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=Order]/*[local-name()=BuyerParty]"/> <xsl:apply-templates select="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=Order]/*[local-name()=Delivery]"/> <joe:Items> <xsl:apply-templates select="/*[local-name()=Envelope]/*[local-name()=Body]/*[local-name()=Order]/*[local-name()=OrderLine]/*[local-name()=LineItem]"/> </joe:Items> </joe:Order> </xsl:template> {omitted content}</xsl:stylesheet>--MIME_boundary--Match Rule: procloadA Match Rule examines the inbound message and determines whether or not the rule should be 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 5 - 8. procload Match Rule ConfigurationThe client must use the URL */procload or this rule will not be applied to the message. Note that theexpression * means “any substring of any characters.”5 - 12 Release 3.6
  • 210. Firewall PolicyAction 0: Implied 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.Action 1: FetchThe first custom action of Rule #1 fetches the XSL attachment from the SwA message. Here is theconfiguration of this action: Figure 5 - 9. Fetch ConfigurationSource: cid:xsl A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL cid:bin indicates that the target of the fetch is the message attachment with the Content-ID of xsl. Refer to the example message above.Output: proc This is set to proc. This context will contain the XSL instructions for transforming the root part of the message.Action 3: Strip AttachmentsThis action strips off all attachments from the message. Here is the configuration display for thisaction: Figure 5 - 10. Strip Attachment ConfigurationRelease 3.6 5 - 13
  • 211. SOAP with AttachmentsInput: INPUT This is set to INPUT, the special context that contains the original message.Attachment URI: blank This input is left blank. This indicates that all attachments are removed from the SwA message. Once removed, the attachments cannot be again retrieved.This action has no Output context because it returns nothing. It operates only on the Input context.Action 4: TransformThis tranform action uses the XSL taken from the attachment and uses it to transform the root partof the message. Here is the configuration page display for this action. Figure 5 - 11. Transform ConfigurationInput: INPUT This is set to INPUT, the special context containing the original message. Note that the Strip Attachments action has altered this message by removing the attachments.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: proc This is set to proc, the name of the context that now contains the XSL instructions.Output OUTPUT This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT5 - 14 Release 3.6
  • 212. Firewall Policy context, which is returned to the client. In this case, it is the root part of the message after transformation by the attached XSL.Here is an example output:<?xml version="1.0" encoding="UTF-8"?><joe:Order xmlns:joe="http://schemas.joes.com/schemas"> <joe:OrderNo>25</joe:OrderNo> <joe:OrderDate>2003-01-23</joe:OrderDate> <joe:BuyerID>20031234-1</joe:BuyerID> <joe:BuyerName> Microdevices </joe:BuyerName> <joe:BuyerContact>George Tirebiter</joe:BuyerContact> <joe:ShipToAddress>413 N Spring St</joe:ShipToAddress> <joe:ShipToCity>Elgin</joe:ShipToCity> <joe:ShipToState>IL</joe:ShipToState> <joe:ShipToZip>60123</joe:ShipToZip> <joe:Items> <joe:Item> <joe:Qty>5</joe:Qty> <joe:ProdID>32145-12</joe:ProdID> <joe:ProdDesc>Pencils, box #2 red</joe:ProdDesc> <joe:ProdUnitPrice amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">2.50</joe:Pro-dUnitPrice> <joe:ItemTotal amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">12.50</joe:ItemTo-tal> </joe:Item> {content omitted} <joe:Item> <joe:Qty>5</joe:Qty> <joe:ProdID>091344-5</joe:ProdID> <joe:ProdDesc>Pens, box red felt tip </joe:ProdDesc> <joe:ProdUnitPrice amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">5.00</joe:Pro-dUnitPrice> <joe:ItemTotal amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">22.50</joe:ItemTo-tal> </joe:Item> <joe:Item> <joe:Qty>12</joe:Qty> <joe:ProdID>21457-3</joe:ProdID> <joe:ProdDesc>Mousepad, blue</joe:ProdDesc> <joe:ProdUnitPrice amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">.50</joe:ProdUn-itPrice> <joe:ItemTotal amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD">6.00</joe:ItemTotal> </joe:Item> </joe:Items></joe:Order>Release 3.6 5 - 15
  • 213. SOAP with AttachmentsRule #3: Two Way RuleThis rule relies upon the existence, in the submitted message, of an attachment with the Content-ID of bin. The contents of the attachment are returned to the client.Match Rule: ReturnAttachA Match Rule examines the inbound message and determines whether or not the rule should be 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 5 - 12. ReturnAttach Match Rule ConfigurationThe client must use the URL */returnattach or this rule will not be applied to the message. Note thatthe expression * means “any substring of any characters.”Action 0: Implied 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.Action 1: FetchThe first custom action of Rule #1 fetches the attachment from the SwA message. Here is theconfiguration of this action: Figure 5 - 13. Fetch Configuration5 - 16 Release 3.6
  • 214. Firewall PolicySource: cid:bin A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL cid:bin indicates that the target of the fetch is the message attachment with the Content-ID of bin.Output: tache This is set to tache. This context will contain the content of the attachment.Action 2: ResultThis action returns the contents of the tache context to the client. Here is the configuration displayfor this action: Figure 5 - 14. Result Action ConfigurationInput: tache This action takes the context tache as its input. This context contains the content of the attachment.Send Results Asynchronously: Off The processing of the rule will wait for this Result action to complete before continuing.Destination: (blank) Entering no value for the Destination indicates that the Result action should send the contents of the Input context to the Output context.Output: (blank) Entering no value allows the system to determine the appropriate Output context. As this is the last action of the rule, the system will automatically send the content of the Input context to the special OUTPUT context, which is what is sent on the wire back to the client.Release 3.6 5 - 17
  • 215. SOAP with AttachmentsRule #4: Two Way RuleThis rule fetches additional content from elsewhere and attaches this content to the message as anew attachment. A rule such as this might be used to return requested resources, such as in thisSOAP XML message requesting an image: <?xml version=1.0 ?> <SOAP-ENV:EnvelopeSOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <request>Declaration of Independence</request> </SOAP-ENV:Body> </SOAP-ENV:Envelope>The rule fetches an image of the Declaration of Independence and returns it to the client.Match Rule: cliponA Match Rule examines the inbound message and determines whether or not the rule should be 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 5 - 15. clipon Match Rule ConfigurationThe client must use the URL */clipon or this rule will not be applied to the message. Note that theexpression * means “any substring of any characters.”Action 0: Implied 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.5 - 18 Release 3.6
  • 216. Firewall PolicyAction 1: FetchThe first action fetches an external resource. Here is the configuration of this action: Figure 5 - 16. Fetch ConfigurationSource: local:///declaration.jpg A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL local:///declaration.jpg indicates that the target of the fetch is a file stored in the local directory system. This could easily be a URL such as http://www.archives.gov/national_archives_ experience/charters/declaration/ declaration.jpg.Output: image This is set to image. This context will contain the fetched resource.Action 2: ResultThis action attaches the contents of the image context to the message. Here is the configurationdisplay for this action: Figure 5 - 17. Result Action ConfigurationRelease 3.6 5 - 19
  • 217. SOAP with AttachmentsInput: image This action takes the context image as its input. This context contains the fetched information.Send Results Asynchronously: Off The processing of the rule will wait for this Result action to complete before continuing.Destination: attachment://INPUT/cid:bin This attaches the content of the Input context to the INPUT context (the original message)value creates the attachment with the Content-ID of <bin> and attaches.Output: (blank) When a Destination is provided, the Output context is ignored.Action 3: ResultThis action sends the Input context to the Output context. The Input context INPUT contains theoriginal message with the attachment added in the previous action. Here is the configurationdisplay for this action: Figure 5 - 18. Result Action ConfigurationInput: INPUT This action takes the special context INPUT as its input. This context contains the original message plus the attachment added in the previous action.Send Results Asynchronously: Off The processing of the rule will wait for this Result action to complete before continuing.Destination: (blank) Entering no value for the Destination indicates that the Result action should send the contents of the Input context to the Output context.Output: (blank) Entering no value allows the system to determine the appropriate Output context. As this is the last action of the rule, the system will automatically5 - 20 Release 3.6
  • 218. Firewall Policy send the content of the Input context to the special OUTPUT context, which is what is sent on the wire back to the client.Here is an example of the document returned by this rule: --67f8c5e9-0c96-4d41-b369-7f0a42d2b83c content-type: text/xml <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <request>Declaration of Independence</request> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --67f8c5e9-0c96-4d41-b369-7f0a42d2b83c Content-ID: <bin> Content-Transfer-Encoding: binary Content-Type: application/octet-stream ?JFIFs456h4t645hur8216y --67f8c5e9-0c96-4d41-b369-7f0a42d2b83c--Note that the DataPower system has created the MIME boundaries because there were none in theoriginal request. To control these boundary values, submit a SwA message with bounariesincluded. The DataPower system will use the extant MIME boundary values rather than values itcreates.Release 3.6 5 - 21
  • 219. SOAP with AttachmentsRule #5: Two Way RuleThis rule signs SOAP with Attachment messages.Match Rule: signA Match Rule examines the inbound message and determines whether or not the rule should be 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 5 - 19. sign Match Rule ConfigurationThe client must use the URL */sign or this rule will not be applied to the message. Note that theexpression * means “any substring of any characters.”Action 0: Implied 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.5 - 22 Release 3.6
  • 220. Firewall PolicyAction 1: SignThis action signs the encrypted response. The configuration display appears as follows. Figure 5 - 20. Sign Response ActionInput: INPUT This is the special INPUT context, containing the original SwA message.Envelope Method: WS-Sec This method causes the signature to be placed in the SOAP header of the message, in accordance with the WS-Security specifications.Message Type: SOAP with Attachments The message and its attachments will be signed.Key: Jefferson The private cryptographic key contained in the Jefferson key object will be used for the signature.Certificate: Jefferson The public cryptographic certificate contained in the Jefferson certificate object will be used for the signature.Output: OUTPUT This is the special OUTPUT context, sent back to the client.Release 3.6 5 - 23
  • 221. SOAP with AttachmentsRule #6: Two Way RuleThis rule verifies the signature on SOAP with Attachment messages.Match Rule: verifyA Match Rule examines the inbound message and determines whether or not the rule should be 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 5 - 21. sign Match Rule ConfigurationThe client must use the URL */verify or this rule will not be applied to the message. Note that theexpression * means “any substring of any characters.”Action 0: Implied 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.Action 1: VerifyA Verify action verifies the signature contained in the message. If the signature cannot be verified,the message is rejected. If the signature is valid, the message passes through the firewall.5 - 24 Release 3.6
  • 222. Firewall PolicyHere is the configuration of the Verify action: Figure 5 - 22. Verify Action ConfigurationInput: INPUT This is set to the special INPUT context, which contains the original message submission.Filter Method: Standard Filter The Standard Filter just checks the signature for validity.Signer Certificate: (Blank) This setting causes the system to use the certificate contained in the signature to verify the signature in the message. If this field had a value, it would need to point to the Crypto Certificate object that would be used for verification.Validation Credentials: None This setting indicates that the system will not perform certificate validation. If this field had a value, it would point to a Crypto Validation Credential object, that in turn would have to include the certificate included in the message to validate that certificate. Additional trust chain checking can also be performed by a Validation Credential object.Output: (Blank) This setting indicates that the system will automatically use the correct context in the following actions. A Verify action is a type of filter that only accepts or rejects the message and does not output the contents of the message.Release 3.6 5 - 25
  • 223. SOAP with AttachmentsAction 2: TransformThis tranform action serves to connect the last context that contained the possibly altered messageto any actions that follow. The policy configuration page automatically created this action. Hereis the configuration page display for this action. Figure 5 - 23. Transform ConfigurationInput: INPUT This is set to INPUT, the special context containing the original message.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 OUTPUT This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is returned to the client. In this case, it is the original message with attachments.5 - 26 Release 3.6
  • 224. Firewall PolicyRule #7: Two Way RuleThis rule strips off the binary attachment in the SwA message and creates a new attachmentcontaining a zip archive. The original attachment to the message is placed in this zip archive alongwith additional content fetched from elsewhere. This rule demonstrates the ability of theDataPower system to manipulate zip archives contained in attachments. A rule such as this mightbe used to create message archives.Match Rule: zipupA 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 5 - 24. zipup Match Rule ConfigurationThe client must use the URL */zipup or this rule will not be applied to the message. Note that theexpression * means “any substring of any characters.”Action 0: Implied 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.Release 3.6 5 - 27
  • 225. SOAP with AttachmentsAction 1: FetchThe first custom action fetches the attachment from the SwA message. Here is the configuration ofthis action: Figure 5 - 25. Fetch ConfigurationSource: cid:bin A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL cid:bin indicates that the target of the fetch is the message attachment with the Content-ID of bin.Output: fbin This is set to fbin. This context will contain the fetched resource.Action 2: Strip AttachmentsThis action strips off all attachments from the message. Here is the configuration display for thisaction: Figure 5 - 26. Strip Attachment ConfigurationInput: INPUT This is set to INPUT, the special context that contains the original message.Attachment URI: cid:bin This strips the attachment with the Content-ID of bin from the message. Once removed, the attachments cannot be again retrieved.This action has no Output context because it returns nothing. It operates only on the Input context.5 - 28 Release 3.6
  • 226. Firewall PolicyAction 3: ResultThis action creates a zip archive, inserts the contents of the fbin context into the archive and thenattaches the archive to the message. Here is the configuration display for this action: Figure 5 - 27. Result Action ConfigurationInput: fbin This action takes the context fbin as its input. This context contains the fetched information.Send Results Asynchronously: Off The processing of the rule will wait for this Result action to complete before continuing.Destination: attachment://INPUT/cid:bin?Archive=zip&Filename=order.pdf This creates the attachment with the Content-ID of <bin>. This attachment is formatted as a zip archive. The contents of the Input context are inserted into the archive as a file named order.pdf.Output Type: binary This explicitly declares the content sent by the action as binary (not xml).Output: (blank) When a Destination is provided, the Output context is ignored.Release 3.6 5 - 29
  • 227. SOAP with AttachmentsAction 4: FetchThis action fetches an additional resource from elsewhere (in this case, the image of a signature)and places it into a context for further use. Here is the configuration of this action: Figure 5 - 28. Fetch ConfigurationSource: local:///sig.gif A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL local:///sig.gif indicates that the target of the fetch is a file stored in the local directory system. This could easily be a URL such as http:// sigserver.domain.com/sigs/sig.gif.Output: fsig This is set to fsig. This context will contain the fetched resource.Action 5: ResultThis action inserts the contents of the Input context into the zip archive now contained in theattachment to the message. Here is the configuration display for this action: Figure 5 - 29. Result Action Configuration5 - 30 Release 3.6
  • 228. Firewall PolicyInput: fsig This action takes the context fbin as its input. This context contains the signature image fetched in the previous action.Send Results Asynchronously: Off The processing of the rule will wait for this Result action to complete before continuing.Destination: attachment://INPUT/cid:bin?Archive=zip&Filename=sig.gif The contents of the Input context are inserted into the archive as a file named sig.gif.Output Type: binary This explicitly declares the content sent by the action as binary (not xml).Output: (blank) When a Destination is provided, the Output context is ignored.Action 6: TransformThis tranform action serves to connect the last context that contained the possibly altered messageto any actions that follow. The policy configuration page automatically created this action. Hereis the configuration page display for this action. Figure 5 - 30. Transform ConfigurationInput: INPUT This is set to INPUT, the special context containing the original message.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.Release 3.6 5 - 31
  • 229. SOAP with AttachmentsProcessing 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 OUTPUT This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is returned to the client. In this case, it is the original message with the zip archive replacing the cid:bin attachment.Rule #8: Two Way RuleThis rule extracts a file from an attached zip archive and returns the file to the client.Match Rule: zipoutA Match Rule examines the inbound message and determines whether or not the rule should be 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 5 - 31. zipout Match Rule ConfigurationThe client must use the URL */zipout or this rule will not be applied to the message. Note that theexpression * means “any substring of any characters.”Action 0: Implied 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.5 - 32 Release 3.6
  • 230. Firewall PolicyAction 1: FetchThis action fetches a file from within the zip archive attached to the message. Here is theconfiguration of this action: Figure 5 - 32. Fetch ConfigurationSource: cid:bin?Archive=zip&Filename=order.pdf A Fetch is given only a Source since it does not operate on the submitted message. The Source identifies a URL that identifies the content to fetch. In this case, the URL cid:bin?Archive=zip&Filename=order.pdf indicates that the target of the fetch is a file stored within the zip archive attached to the message.Output: outfile This is set to outfile. This context will contain the fetched resource.Action 2: ResultThis action returns the file obtained from the zip archive attached to the original message. Here isthe configuration display for this action: Figure 5 - 33. Result Action ConfigurationInput: outfile This action takes the context outfile as its input. This context contains the file fetched in the previous action.Release 3.6 5 - 33
  • 231. SOAP with AttachmentsSend Results Asynchronously: Off The processing of the rule will wait for this Result action to complete before continuing.Destination: (blank The action will send the contents of the Input context to the Output context.Output: (blank) When the Output context is set to blank, the system automatically sends the message to the appropriate context. As this is this last action in the rule, the system sends the content to the OUTPUT context, which is sent back immediately to the client. Note that this is not wrapped in SOAP XML.Rule #9: Two Way RuleThis rule allows DIME messages to pass through the firewall. The firewall, by default, convertsDIME to MIME format unless action is taken. The rules demonstrates that action.Match Rule: passdimeA Match Rule examines the inbound message and determines whether or not the rule should be 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 5 - 34. sign Match Rule ConfigurationThe client must use the URL */passdime or this rule will not be applied to the message. Note thatthe expression * means “any substring of any characters.”Action 0: Implied 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.Action 1: SetvarA Setvar action sets the value of a variable, for use in subsequent processing. In this case, theaction sets the variable that keeps the message in DIME format.5 - 34 Release 3.6
  • 232. Firewall PolicyHere is the configuration of the Setvar action: Figure 5 - 35. Setvar Action ConfigurationInput: INPUT This is set to the special INPUT context, which contains the original message submission.Variable Name: var://local/_extension/attachment-format The action sets the value of the variable named var://local/_extension/attachment- format. This is a special variable maintained by the system for the purpose of determining the format of attachments.Variable Value: application/dime This setting causes the system to format the message according to the DIME protocol. Note that if the original message had been in MIME format, this setting would cause the message to be reformatted, in effect creating a gateway.Release 3.6 5 - 35
  • 233. SOAP with AttachmentsAction 2: TransformThis tranform action serves to connect the last context that contained the possibly altered messageto any actions that follow. The policy configuration page automatically created this action. Hereis the configuration page display for this action. Figure 5 - 36. Transform ConfigurationInput: INPUT This is set to INPUT, the special context containing the original message.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 OUTPUT This is set to OUTPUT. The policy configuration page automatically assigned this context name. This action connects the inbound message to the OUTPUT context, which is returned to the client. In this case, it is the original message with attachments.5 - 36 Release 3.6
  • 234. Additional CapabilitiesAdditional CapabilitiesAdditional capabilities for handling SOAP with Attachment messages are available in theDataPower system. These are: • Encode archives as Base64 • Decode base64-encoded archives • List all attachments • List contents of archives within attachments • Addressing DIME attachments using uuid:Each are covered in more detail here.Base64 EncodingAttachments containing archives can be base64 encoded or decoded using the Fetch action. Forexample, when extracting a file from a base64 encoded archive, the archive can first be decoded,allowing for the file extraction. The Destination property for the Fetch action would resemble thefollowing:cid:bin?Archive=zip&Filename=order.pdf?Decode=base64Similarly, archives that are not encoded can be base64 encoded using a Fetch Destination such asthe following:cid:bin?Archive=zip&Encode=base64Attachment ManifestIt is possible to access a manifest of all attachments in a given message. This manifest is a nodesetheld in the variable var://context/INPUT/attachment-manifest. Here is an example manifest:<?xml version="1.0" encoding="UTF-8"?><manifest> <package-headers/> <root-headers> <header> <name>Content-Type</name> <value>text/xml; charset=UTF-8</value> </header> <header> <name>Content-ID</name> <value><main></value> </header> <header> <name>Content-Transfer-Encoding</name> <value>binary</value> </header> </root-headers> <media-type> <value>multipart/related; type="text/xml"; boundary="MIME_boundary"</value> <type>multipart</type> <sub-type>related</sub-type> </media-type> <attachments> <attachment>Release 3.6 5 - 37
  • 235. SOAP with Attachments <uri>cid:bin</uri> <size>13044</size> <header> <name>Content-Type</name> <value>audio/mpeg</value> </header> <header> <name>Content-ID</name> <value><bin></value> </header> <header> <name>Content-Transfer-Encoding</name> <value>binary</value> </header> </attachment> </attachments></manifest>DIME Attachment AddressingDIME attachments can be addressed using the prefix uuid:, which is typically used in DIMEmessages. The same attachment may also be addressed using the cid: prefix. For example, both ofthe following expressions address the same DIME attachment. uuid:f1e8ef38-b4f6-4991-94fb-3a0b97922901 cid:f1e8ef38-b4f6-4991-94fb-3a0b979229015 - 38 Release 3.6
  • 236. NoticesThis 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 inyour area. Any reference to an IBM product, program, or service is not intended to state or imply thatonly 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 isthe users 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 licenseinquiries, in writing, to:IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.The following paragraph does not apply to the United Kingdom or any other country where suchprovisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINESCORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANYKIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR APARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties incertain transactions, therefore, this statement may not apply to you.This information could include technical inaccuracies or typographical errors. Changes are periodicallymade 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 thispublication at any time without notice.TrademarksIBM, DataPower, Domino, Lotus, Tivoli, and WebSphere are registered trademarks of the InternationalBusiness Machines Corporation in the United States and/or other countries.Internet Explorer, Microsoft, and Windows are trademarks of Microsoft Corporation in the United States,other countries, or both.Java and all Java-based trademarks and logos are trademarks or registered trademarks of SunMicrosystems, Inc. in the United States and other countries.Linux is a trademark of Linus Torvalds in the United States, other countries, or both.Other company, product, and service names may be trademarks or service marks of others. Notices-#
  • 237. IndexA DAAA Policy 2 - 16 DIME 5 - 34Action 1 Document Crypto Map 2 - 23 Transform 1 - 45, 1 - 48 Duration Monitor 1 - 20, 1 - 23, 2 - 42 Validate 1 - 59Action 2 E Filter 1 - 60 Setvar 1 - 49 Error Policy 4 - 12Action 3 Error Rule 1 - 18, 1 - 48 Route 1 - 61 Event Subscriptions 1 - 27 Validate 1 - 37Action 5 F Transform 1 - 40, 1 - 63Action 7 Firewall Policy 1 - 6, 1 - 32, 1 - 57, 2 - 7, Transform 1 - 44 5-4Allow Chunked Uploads 3 - 6 Follow Redirects 3 - 6Application Security Policy 4 - 4 Front Attachment Processing Format 3-4 Error Maps 4 - 7 Front Side Protocol 3 - 3 Request Maps 4 - 4 Response Maps 4 - 6 HApplication Security PolicyName 4 -4 HTTP Front Side Protocol Handler 3 - 9B HTTP Protocol Handler Local IP Address 4 - 3Back Attachment Processing Format 3-4 HTTPS Front Side Protocol Handler 3 - 10Back End URL 3 - 3 LC Log Target 1 - 25Count Monitor 2 - 42 Event Subscriptions 1 - 27, 2 - 47, 3 -Crypto Certificate 1 - 52, 2 - 51, 3 - 34 30Crypto Identification Credentials 1 - 51, 2 - Object Filters 1 - 26, 2 - 47, 3 - 2950, 3 - 33 Logging 1 - 25, 2 - 46, 3 - 28Crypto Key 1 - 51, 2 - 50, 3 - 34 Loop Detection 3 - 6Crypto Profile 2 - 49, 3 - 32 Index - 1
  • 238. M Setvar 5 - 34 Sign 2 - 33, 3 - 25, 5 - 23Match 4 - 5 Strip Attachments 5 - 9, 5 - 13, 5 - 28Match Rule 1 - 7, 1 - 33, 1 - 58, 1 - 64, 2 Transform 1 - 11, 1 - 13, 1 - 15, 1 -- 9, 2 - 21, 2 - 25, 2 - 31, 2 - 35, 2 - 39, 18, 1 - 34, 1 - 65, 2 - 20, 23 - 17, 3 - 24, 5 - 7, 5 - 12, 5 - 16, 5 - - 27, 2 - 40, 3 - 23, 5 - 10,18, 5 - 22, 5 - 24, 5 - 27, 5 - 32, 5 - 34 5 - 14, 5 - 26, 5 - 31, 5 - 36Message Filter Action 1 - 22 Validate 1 - 8, 2 - 10, 2 - 31, 2 - 36,Message Match 1 - 20 2 - 39, 3 - 18, 3 - 24Message Monitor 2 - 42 Verify 2 - 26, 3 - 22, 5 - 24Message Type 1 - 21 Processing Rules 1 - 7, 1 - 33, 1 - 58, 2 - 8,MIME 5 - 34 3 - 15, 5 - 5MMDOS 3 - 7Monitors 2 - 42 RMQ Front Side Protocol Handler 3 - 11Multi-Protocol Gateway 3 - 2 Rate LimiterMulti-Protocol Gateway Name 3 - 2 Concurrent Connections 4 - 23Multi-Protocol Gateway Policy 3 - 2, 3 - 14 Enforcement Style 4 - 23Multi-Protocol Gateway Type 3 - 2 Rejected Counter 2 - 19 RemoteAddress 4 - 3N Request Attachments 3 - 4 Request Type 3 - 4Name Value Profile 4 - 24 Response Attachments 3 - 4 Response Type 3 - 4O SObject Filters 1 - 26 SAML Attribute Assertion 2 - 16, 2 - 18P SAML Attributes 2 - 19 SAML Signature 2 - 17Port Number 4 - 3 SQL Injection Attack 2 - 14Processing Action SSL Client Crypto Profile 3 - 4 AAA 2 - 15 SSL Communications 2 - 49, 3 - 31 Call 1 - 67, 2 - 24 SSL Proxy Profile 3 - 31 Convert-http 1 - 34, 1 - 64 SSL Server Crypto Profile 1 - 50 Decrypt 2 - 21 Encrypt 2 - 32, 2 - 37 T Fetch 5 - 8, 5 - 13, 5 - 16, 5 - 19, 5 - 28, 5 - 30, 5 - 33 Threat Protection 2-6 Filter 1 - 9, 1 - 38, 2 - 12, 2 - 14, 3 - 20 U Result 5 - 17, 5 - 19, 5 - 20, 5 - 29, 5 - 30, 5 - 33 URL Rewrite Policy 3 - 2 Results Asynch 5 - 8 User Agent Settings 3 - 3 Route 1 - 12, 1 - 42Index - 2 Release 3.6
  • 239. X-Series Device Reference GuideVValidation Credential 3 - 35WWeb Application Firewall Error Policy 4 - 3 Local IP Address 4 - 3 Name 4 - 2 Port Number 4 - 3 Remote Host 4 - 3 RemotePort 4 - 3 Security Policy 4 - 3 SSL 4 - 4 SSLProxyProfile 4 - 2 XMLManager 4 - 3Web Request Profile 4 - 12 Name 4 - 20Web Response Profile Content-Type List 4 - 21 Error Policy 4 - 21WS-Security 2 - 32XXDOS 3 - 7XML Firewall 2 - 3, 5 - 2XML Firewall Service 1 - 3, 1 - 29, 1 - 54XML Manager 3 - 2XML Threat Protection 2 - 42, 3 - 6XPath Routing Map 1 - 12, 1 - 42, 1 - 62Zzip archive 5 - 27, 5 - 32Release 3.6 1-3
  • 240. 1-4 Release 3.6