TEC Workbook - IBM
TEC Workbook - IBM TEC Workbook - IBM
IBM Software The policy will now protect against malicious SQL injection threats. The file sqlThreat.xml contains a SOAP message with an SQL Injection Threat in it. The contents of the element contain the threat: XI50 DataPower' or '1'='1 {omitted} Security;Integration;Performance __6. In the soapUI request window, load the request from c:\labs\requests\sqlThreat.xml. __7. Click the green submit button to POST the message to ProductServiceProxy. The request should fail due to “Message contains restricted content (from client)”. 2.6 Transforming with XSL and XPath At the heart of WebSphere DataPower SOA Appliances is a high speed XSL compiler and execution engine. In fact, most built-in functionality is engineered using XSL. Some of the built-in stylesheets can be found in the store directory. XSL developers can easily copy and modify the IBM provided stylesheets to create new functionality or support emerging standards before IBM makes them available. When a stylesheet is referenced for the first time, it is compiled using a patented optimizing XSL compiler for execution on specialized WebSphere DataPower hardware, then cached in memory for high-speed recall and execution. IBM has augmented XSL with a rich set of extension functions that enable you to easily add complex processing functionality to your processing rules. For example, there are extension functions for performing base-64 encoding and decoding, encryption and decryption, and date/time functions. There are also functions for communicating with off-box web services as well as LDAP servers. In this section, you’ll be introduced to how XSL templates are used within processing rules. You’ll also get a chance to see the decode() extension function for decoding base-64 encoded text. In the following steps, you’ll add a transform action to the response (server to client) rule instead of the request rule. Since the transform action will modify the overall structure of the message, it won’t match the schema that the backend service is expecting, therefore the request will fail. To avoid this, you’ll modify the response which is destined back to soapUI. __1. In the policy editor, towards the bottom, click on the Server to Client rule to make it the active rule in the editor. Page 46 WebSphere Lab Jam
__2. Click and drag a transform action and drop it after the match action. __3. Double click the yellow outlined transform action to expose its configuration settings. For this transform, the stylesheet will be located on a remote HTTP server rather than in your local: directory. __4. In the Transform field: __a. In the top dropdown, select http://. __b. In the lower text box, type: demoserver/files/productTransform.xsl __5. Click the Done button to save the transform action. __6. Click the Apply Policy button to apply the changes to the overall policy. __7. Click the Close Window link to dismiss the policy editor. __8. Click the Apply button in the Configure Multi-Protocol Gateway form. IBM Software You’re now ready to run another transaction through your multi-protocol gateway service. Before you do that, let’s take a look at what the XSL template will do to the message. Here’s the SOAP body of the response message. Notice the tag contains base- 64 encoded text (some of it has been omitted). XI50 WebSphere DataPower SUJNIFdlYlNw {omitted} Security;Integration;Performance Lab 2 - Working with XML Page 47
- Page 1 and 2: WebSphere Lab Jam Connectivity WebS
- Page 3 and 4: Contents IBM Software CONNECTION PA
- Page 5 and 6: Connection Parameters Spreadsheet I
- Page 7 and 8: 1.4 Introduction to WebSphere DataP
- Page 9 and 10: IBM Software You’re now ready to
- Page 11 and 12: There are several areas in the WebG
- Page 13 and 14: 1.10 WebSphere DataPower Services I
- Page 15 and 16: IBM Software Gateway supports WebSp
- Page 17 and 18: cert: Directory Usage IBM Software
- Page 19 and 20: __7. Click on the small plus sign t
- Page 21 and 22: 1.13 Logging IBM Software WebSphere
- Page 23 and 24: ● Trigger a set of actions to occ
- Page 25 and 26: 1.13.4 Appliance management IBM Sof
- Page 27 and 28: 1.13.8 Configuration Comparison, Ch
- Page 29 and 30: Lab 2 Working with XML Prerequisite
- Page 31 and 32: 2.1.5 WebSphere DataPower Configura
- Page 33 and 34: IBM Software It’s also possible t
- Page 35 and 36: Match Rule - evaluate statements us
- Page 37 and 38: IBM Software __18. In the Configure
- Page 39 and 40: IBM Software __2. Expand the policy
- Page 41 and 42: IBM Software __12. In soapUI, click
- Page 43 and 44: IBM Software __3. Click the green s
- Page 45: The SQL statement would become: SEL
- Page 49 and 50: 2.7 Stylesheet Caching IBM Software
- Page 51 and 52: 2.8.3 Virus Scanning IBM Software V
- Page 53 and 54: Lab 3 Securing XML Message Content
- Page 55 and 56: 3.2.2 Create the Crypto Key and Cer
- Page 57 and 58: 3.2.7 Verifying the request signatu
- Page 59 and 60: __8. Click the Close Window link to
- Page 61 and 62: __12. Click on the small [+] to sho
- Page 63 and 64: IBM Software __3. Click on the last
- Page 65 and 66: IBM Software __6. In the list of co
- Page 67 and 68: __11. Click the Done button in the
- Page 69 and 70: Lab 4 Access Control Framework Prer
- Page 71 and 72: __3. Double click the yellow outlin
- Page 73 and 74: Appendix A. Notices This informatio
- Page 75 and 76: Appendix B. Trademarks and copyrigh
- Page 77 and 78: NOTES
<strong>IBM</strong> Software<br />
The policy will now protect against malicious SQL injection threats. The file sqlThreat.xml contains a<br />
SOAP message with an SQL Injection Threat in it. The contents of the element contain the<br />
threat:<br />
<br />
XI50<br />
DataPower' or '1'='1<br />
{omitted}<br />
Security;Integration;Performance<br />
<br />
__6. In the soapUI request window, load the request from c:\labs\requests\sqlThreat.xml.<br />
__7. Click the green submit button to POST the message to ProductServiceProxy. The request<br />
should fail due to “Message contains restricted content (from client)”.<br />
2.6 Transforming with XSL and XPath<br />
At the heart of WebSphere DataPower SOA Appliances is a high speed XSL compiler and execution<br />
engine. In fact, most built-in functionality is engineered using XSL. Some of the built-in stylesheets can<br />
be found in the store directory. XSL developers can easily copy and modify the <strong>IBM</strong> provided stylesheets<br />
to create new functionality or support emerging standards before <strong>IBM</strong> makes them available.<br />
When a stylesheet is referenced for the first time, it is compiled using a patented optimizing XSL compiler<br />
for execution on specialized WebSphere DataPower hardware, then cached in memory for high-speed<br />
recall and execution.<br />
<strong>IBM</strong> has augmented XSL with a rich set of extension functions that enable you to easily add complex<br />
processing functionality to your processing rules. For example, there are extension functions for<br />
performing base-64 encoding and decoding, encryption and decryption, and date/time functions. There<br />
are also functions for communicating with off-box web services as well as LDAP servers.<br />
In this section, you’ll be introduced to how XSL templates are used within processing rules. You’ll also<br />
get a chance to see the decode() extension function for decoding base-64 encoded text.<br />
In the following steps, you’ll add a transform action to the response (server to client) rule instead of the<br />
request rule. Since the transform action will modify the overall structure of the message, it won’t match<br />
the schema that the backend service is expecting, therefore the request will fail. To avoid this, you’ll<br />
modify the response which is destined back to soapUI.<br />
__1. In the policy editor, towards the bottom, click on the Server to Client rule to make it the active<br />
rule in the editor.<br />
Page 46 WebSphere Lab Jam