Level: Advanced

Bob Callaway (rcallawa@us.ibm.com), Software Engineer, IBM　

01 Nov 2007

With the increasing adoption of Web services and Service-Oriented Architectures (SOAs), ensuring the authenticity, integrity, and nonrepudiability of XML messages has become an essential component of secure and robust messaging infrastructures. Using a sample scenario, this article walks you through how to use Apache WSS4J and IBM® WebSphere® DataPower® SOA Appliances together to enable the signing and verification of XML documents.

Introduction

Part of the Web Services Security (WS-Security) standard, XML signatures let you add authentication, data integrity, and nonrepudiation to portions of XML documents. The Apache WSS4J project was created to provide a Java™-based library that can be used to both sign XML documents and verify signatures. However, cryptographical operations, such as signing, validation, and verification, are computationally expensive on general-purpose hardware.

To address these issues, the suite of purpose-built WebSphere DataPower SOA Appliances is custom tailored to perform cryptographical, XML, and Web services functions in a highly optimized manner. The WebSphere DataPower XML Security Gateway XS40 and WebSphere DataPower Integration Appliance XI50 both leverage this capability in acting as a security-enforcement point for XML traffic to provide encryption and decryption of data, firewall filtering, schema validation, and XML-based access control. The goal of this work is to leverage the XML and security capabilities of the WebSphere DataPower SOA Appliances to verify signatures in incoming XML requests to authenticate the sender, ensure the integrity of the document, and provide nonrepudiation of the origin of the request. You achieve this by configuring the WebSphere DataPower SOA Appliances to use a provided public certificate to validate the signer of the document and verify that the signature is correct. Due to the highly optimized cryptographical and XML engines of the WebSphere DataPower SOA Appliances, you can access this functionality with almost negligible impact on end-to-end latency. This article presents a sample scenario that demonstrates this functionality.

Related content Learn more about IBM WebSphere DataPower SOA Appliances Tip: Write XML documents with StAX Enable XML awareness in WebSphere Extended Deployment with WebSphere DataPower SOA Appliances Course list: WebSphere DataPower Understanding Web Services specifications, Part 4: WS-Security

XML digital signatures

As an integral part of the WS-Security standard, XML digital signatures provide a way to ensure the authenticity, integrity, and nonrepudiability of SOAP messages:

• Authenticity confirms the identity of the sender of the message.
• Integrity ensures that the content that was signed hasn't been altered.
• Nonrepudiability establishes the fact that the sender did, in fact, originate the message.

The WS-Security standard allows multiple signatures and signature formats to be attached to a message, each referencing different, even overlapping parts of the message. To create a digital signature, a hash value is computed over the desired parts of the message; this value is completely dependent on the exact value of the data over which it was computed. Integrity is ensured, because the recipient computes the same hash value over the specified data, and if the value computed differs from the value contained in the signature, then the integrity of the data is known to have been compromised. This hash value is then encrypted using the sender's private key. When the message is received, the sender's public key is used to decrypt the signature. If the decryption is successful, then the authenticity of the message has been proven, because only the sender's public key can decrypt signatures that were encrypted using the sender's private key. Nonrepudiation is also proven in this step, because only the sender can have the private key used to encrypt the signature; therefore, the sender can't deny sending the document.

Back to top

Apache WSS4J

Apache WSS4J is an open source implementation of the WS-Security standard. WSS4J is a Java-based library that can be used to both sign and verify SOAP messages with WS-Security information. While it can be used as a library simply to sign parts of or entire SOAP messages, WSS4J can also leverage the power of the Apache Axis and XML Security projects. It's also interoperable with Java API for XML-based RPC (JAX-RPC) and Microsoft® .NET-based servers and clients. The WSS4J project provides a simple and straightforward API for adding WS-Security functionality into Web services clients to enable the authenticity, integrity, and nonrepudiability provided by XML digital signatures.

Back to top

WebSphere DataPower SOA Appliances

This section provides an overview of the features and architecture of the WebSphere DataPower SOA Appliances and a quick summary of the approach taken to use and deploy the appliances. The WebSphere DataPower SOA Appliances family consists of three appliances with increasing model numbers. Appliances with higher model numbers are supersets of lower-numbered appliances. All appliances share a common engine and management and monitoring interfaces. The basic management mechanism of WebSphere DataPower SOA Appliances is a purpose-built command line interpreter (CLI) that lets the user perform administrative actions on the box. It's similar to the Internetworking Operating System (IOS) CLI provided by Cisco. The appliances provide console (serial) and Secure SHell (SSH) access to this CLI. A WebGUI interface provides a graphical interface to all WebSphere DataPower SOA Appliances. All management actions that can be done via the CLI can also be performed using the more intuitive WebGUI. An example showing the building of a processing flow using the WebGUI is shown in the next section. WebSphere DataPower SOA Appliances also support a SOAP (WS-) management interface that enables programmatic access to the configuration of the appliance. An Eclipse plug-in, included with the appliances, leverages this interface and provides IDE support. In addition, all WebSphere DataPower SOA Appliances come with vast support for monitoring, event logging, and alerting. Supporting a wide variety of event levels and criteria (IP, TCP, HTTP, XML, SOAP), output can be directed to a number of targets, including file systems, Simple Network Management Protocol (SNMP), SOAP endpoints, Common Base Event, the IBM Tivoli® Composite Application Manager for SOA, the console, or a system cache.

WebSphere DataPower XML Accelerator XA35

The most basic of the WebSphere DataPower SOA Appliances, the IBM WebSphere DataPower XML Accelerator XA35, delivers a number of routing and transformation features. It supports routing based on IP, TCP, HTTP, XML, and SOAP criteria. You can define (or query) routing tables to determine the appropriate routing action. Load balancing algorithms, such as least-used and round-robin, are also available. Additionally, the XA35 can throttle or adjust request rates based on routing criteria to employ traffic shaping. From a transformation perspective, the XA35 provides a high-performance Extensible Stylesheet Language Transformation (XSLT) processing engine. Built on the underlying premise of all WebSphere DataPower SOA Appliances, purposed hardware converts one XML schema into another at wire speed. XSLT 1.0 and XPath 1.0 support (with some 2.0 support) is available. The appliance can use and apply internal and external schemas.

WebSphere DataPower XML Security Gateway XS40

Building on the XA35, the XS40 adds security capabilities to WebSphere DataPower SOA Appliances by enabling XML encryption and XML digital signature processing. Supporting WS-Security 1.0, WS-Trust, and WS-SecureConversation, the XS40 is the foundation upon which WS-Security can be deployed in an enterprise. Support exists for authorization (access) checking to offboard entities, such as the IBM Tivoli Access Manager, RSA Access Manager, Netegrity, Oblix, and more. There is partial Security Assertion Markup Language (SAML) 2.0 support and the ability to extract and use security credentials from Lightweight Directory Access Protocol (LDAP), Remote Authentication Dial-In User Service (RADIUS), and XML Key Management Specification (XKMS). But perhaps the most significant security feature of the XS40 is its firewalling capabilities. In addition to filtering input traffic (as is done in the XA35 routing capabilities), the firewall feature of the XS40 enables XML denial-of-service protection. Used in conjunction with schema validation and well-formedness checking, the XS40 is an integral part of the network security within an enterprise.

WebSphere DataPower Integration Appliance XI50

Finally, the XI50 adds integration capabilities to the WebSphere DataPower SOA Appliances family. It enables a key concept of any-to-any transformation where data can be received in any format over any protocol and be converted to any other format over any other protocol using WebSphere DataPower SOA Appliances core transformation technology. Supported protocols include HTTP, HTTPS, FTP, Java Message Service (JMS), and MQ. SOAP/XML is natively supported out of the box, and support for arbitrary formats, such as electronic data interchange (EDI), CICS Cobol Copybook, Common Object Request Broker Architecture (CORBA), ISO 8583, comma separated values (CSV), ASN.1, electronic business XML (ebXML), and others can be implemented using DataGlue technology.

Back to top

Example scenario

In this scenario, you use the WebSphere DataPower Integration Appliance XI50 to verify an WS-Security signature in an XML document that was signed by an WSS4J-based application. The steps below assume that a Java Development Kit (JDK) is installed and the environment variable JAVA_HOME is set to where the JDK is installed. You need the latest version of the Apache WSS4J, Apache Commons CLI, Apache Commons Logging, and Apache XML Security libraries to follow these steps.

Back to top

Generate keys and certificates

To sign a portion of an XML document, you need a private key along with a public certificate. Note: If you already have a private key and public certificate that you want to use, skip ahead to the Create a Java keystore with your private key and public certificate section. Otherwise, continue by creating a new self-signed key and certificate for use in this example in the following section.

Use the Crypto Tools provided in the WebSphere DataPower Integration Appliance XI50 to create a key/certificate pair

1. Assuming you're logged in to the WebGUI of your WebSphere DataPower SOA Appliances, click the Administration tab on the left side of the screen.
2. Click the Crypto Tools link under the Miscellaneous header.
3. On the Generate a Key tab, fill in the Common Name (CN) and File Name fields.
4. Make sure the Export Private Key, Generate Self-Signed Certificate, and Export Self-Signed Certificate options are all set to on.
5. Set the Password Alias and Generate Key and Certificate Objects options to off. When you're done, the form should appear as shown in Figure 1.
   
   Figure 1. Using the Crypto Tools Wizard to generate a key/certificate pair
   
   
   
6. Click the Generate Key button. A pop-up window appears asking you to confirm the key and certificate generation.
7. Click Confirm to proceed. A confirmation window appears with the location of the exported key and certificate (see Figure 2).
   
   Figure 2. Locations of generated key and certificate
   
   
   
8. Click Close.

Now you need to retrieve the private key and public certificate that were generated.

9. Click the File Management link under the Administration tab on the left side of the screen (located under the Main header).
10. Expand the temporary folder to reveal the three exported files from your key- and certificate-generation process.
11. Now you need to download the private key and the self-signed public certificate, which in this case are named sample-privkey.pem and sample-sscert.pem. To download these files, right-click each link (sample-privkey.pem and sample-sscert.pem), choose Save Target As..., and save the two files to your local system.
    
    Figure 3. Downloading the private key and public certificate
    
    
    

Create a Java keystore with your private key and public certificate

If you already have your private key and public certificate stored together in a Java keystore, skip to the Sign an XML document section. Otherwise, assuming you have a private key (example file name is sample-privkey.pem) and a public certificate (example file name is sample-sscert.pem), either previously created or just created using the steps in the section above, you begin by doing the following:

1. Use openssl to convert your private key and public certificate into a Distinguished Encoding Rules (DER) format (see Listing 1).
   
   Listing 1. Convert your existing key and certificate into a DER format
   

   openssl pkcs8 -topk8 -nocrypt -in sample-privkey.pem -inform PEM -out sample-privkey.der \ -outform DER openssl x509 -inform PEM -outform DER -in sample-sscert.pem -out sample-sscert.der

   
   
2. Now put the key and certificate into a Java keystore using the Java program OpenSSLToJKS included in this article. Listing 2 shows you how.
   
   Listing 2. Import your existing key and certificate (in DER format) into a Java keystore using OpenSSLToJKS
   

   $JAVA_HOME/bin/javac -cp commons-cli-1.1.jar:. OpenSSLToJKS.java $JAVA_HOME/bin/java -cp commons-cli-1.1.jar:. OpenSSLToJKS -alias sample -key \ sample-privkey.der -keypass password -cert sample-sscert.der -storefile sample.jks \ -storepass password

   
   

Now you have a Java keystore that you can use with WSS4J to sign an XML document.

Back to top

Sign an XML document

Before you can sign the XML document, you must configure your application to use the keystore (either the one you created or a preexisting one) that contains your private key and public certificate. You accomplish this by editing the crypto.properties file so that the properties shown in Listing 3 are appropriately set.

                
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.file=sample.jks
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=password
      

Compile SignEnvelope

To compile SignEnvelope.java, issue the command shown in Listing 4. Note: If you're using a Sun JDK, you also need to get Xalan-J from Apache and include the four .jar files—serializer.jar, xalan.jar, xercesImpl.jar, and xml-apis.jar—in the class path in the commands shown in Listing 4, Listing 5, and Listing 6.

                
$JAVA_HOME/bin/javac -cp \
wss4j-1.5.2.jar:xmlsec-1.4.1.jar:commons-logging-1.1.jar:commons-cli-1.1.jar:. \
SignEnvelope.java

Run SignEnvelope

Now you're ready to sign the document! The Java program you use inserts the signature into the SOAP header of the example XML document, which is, by default, computed over the entire SOAP body. You can specify which parts of the XML document to sign by using the signer.setParts() from the WSS4J API. In this example, you use the default setting and compute the signature over the entire SOAP body. You start your SignEnvelope application, specifying:

• The input XML document you want to sign.
• Where you want the signed output XML to be written.
• The WSS4J crypto.properties file that defines the keystore to search.
• The alias of the entry in your keystore.
• The password for the private key.

                
$JAVA_HOME/bin/java -cp \
wss4j-1.5.2.jar:xmlsec-1.4.1.jar:commons-logging-1.1.jar:commons-cli-1.1.jar:. \
SignEnvelope -in unsigned.xml -out signed.xml -prop crypto.properties -alias sample \
-keypass password

If you don't specify a -v or --verbose flag when running SignEnvelope, the program quietly returns without printing anything to the console. If you're curious to see the steps that occur during the execution process, or if the program is failing and you need help debugging it, add the -v or --verbose flag to the end of the argument list. Sample output from the program with this flag added is shown in Listing 6.

                
$JAVA_HOME/bin/java -cp \
wss4j-1.5.2.jar:xmlsec-1.4.1.jar:commons-logging-1.1.jar:commons-cli-1.1.jar:. \
SignEnvelope -in unsigned.xml -out signed.xml -prop crypto.properties-v -alias sample \
-keypass password
Parsing command line arguments...
 will load input XML from unsigned.xml ...
 will output signed XML to signed.xml ...
 will load crypto properties from crypto.properties ...
 will use the entry with alias 'sample' ...
 will use the key password 'password' ...
Parsing input XML file ...
Signing XML document ...
 Creating Signature object ...
 Creating WS-Security Header object ...
 Creating Crypto object from crypto.properties ...
 Writing Signature to WS-Security Header ...
Writing signed XML to signed.xml ...
Complete!
      

Now you can inspect the document that was written by SignEnvelope to verify that the SOAP envelope in signed.xml has been signed.

                
# cat signed.xml

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<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#X509v3" 
wsu:Id="CertId-1828792" xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
MIICFTCCAX6gAwIBAgIEaYxAxzANBgkqhkiG9w0BAQUFADARMQ8wDQYDVQQDEwZzYW1wbGUwHhcNMDcwODMxMTI1OD
U0WhcNMDgwODMwMTI1ODU0WjARMQ8wDQYDVQQDEwZzYW1wbGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK4C
eWss1Fi4sUwMaPZ5Fkd1tcaNW+fMYLz4o1L9DpQqCarlaOeRhYc2PzLAmi6Qu04L17RksZov4Ioq57D9ZpWJDOvJ4e
JXlzDuRq3yAv8D0jD38CUJiyd2AuDYH2naYF575KDqo4JM23upQ9X3n72QP1uMXeWPdGXrQWGw72ufAgMBAAGjejB4
MAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFA875O56gj3t1LTy5Z9VUGRwh858MDwGA1UdIwQ1MDOAFA875O56gj3t1L
Ty5Z9VUGRwh858oRWkEzARMQ8wDQYDVQQDEwZzYW1wbGWCBGmMQMcwCwYDVR0PBAQDAgK8MA0GCSqGSIb3DQEBBQUA
A4GBAIx2GglkdhoJ7HUaCZx1Ggl0dRoJxHAaCexwGgn8dBoJbHMaCfRyGgmMcRoJRHMaCcxyGglkcRoJhHQaCTR0Gg
mccBoJFHEaCQAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAABhbgAA
</wsse:BinarySecurityToken>
<ds:Signature Id="Signature-653534964" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-1367626116">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>lnfpDFV71XKNSFzG562nx+SzNrA=</ds:DigestValue>

</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
Vtx5MScOPZNxjr9hq511Oy+8oAuZSMQhQgaNxMM/a+ud8g6eNYLfybCXhTbjpvNBwuWEXJhCP+i0BIVroHJSM6HYYb
7IMJha0zTG0RLhKLAlrbgQAtQ5qAwG2M/i1X0biqErLmCokMab/aUhDjMIuSCr5CZhqxI4F3E3Sp1HII0=
</ds:SignatureValue>
<ds:KeyInfo Id="KeyId-1493981452">
<wsse:SecurityTokenReference wsu:Id="STRId-308417122" xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Reference URI="#CertId-1828792" ValueType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>

</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soapenv:Header>
<soapenv:Body wsu:Id="id-1367626116" xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <books>
      <book>
        <title>War and Peace</title>

        <author>Leo Tolstoy</author>
      </book>
      <book>
        <title>The Catcher in the Rye</title>
        <author>J. D. Salinger</author>

      </book>
    </books>
  </soapenv:Body>
</soapenv:Envelope>

Back to top

Configure WebSphere DataPower Integration Appliance XI50

Note: All screen shots and configuration steps in this article use the WebSphere DataPower Integration Appliance XI50 firmware version 3.6.0.19; other firmware versions (and appliances) may have slightly different steps, but should be very similar to those provided below.

1. From the DP control panel in the WebGUI, click Keys and Certs Management.
2. Choose Certificates, and click Add.
3. Give the Certificate object a name (I used pubcert).
4. Click Upload.
• If you have the certificate in Privacy Enhanced Mail (PEM) format, use the file upload method: Browse to the PEM certificate file, and click Upload.
• If you only have the certificate in the Java keystore, use the Java keystore method: Browse to the keystore file, enter the keystore password, select the public certificate from the drop-down list, and enter the password for it. Then click Upload.
5. Enter the password twice for the certificate. Your screen should look similar to Figure 4.
   
   Figure 4. Configure Crypto Certificate object
   
   
   
6. Click Apply.
7. Click the Control Panel link on the left side of the WebGUI.
8. From the DP control panel in the WebGUI, click Keys and Certs Management.
9. Choose Validation Credentials, and click Add.
10. Enter a name for the Validation Credentials object, such as sampleVC.
11. Associate the Certificate object created in steps 3-5 with the Validation Credentials object by selecting it from the drop down box, then click Add. At this point, the form should appear similar to Figure 5.
    
    Figure 5. Configure Crypto Validation Credentials object
    
    
    
12. Click Apply.
13. From the DP control panel in the WebGUI, click XML Firewall.
14. Click Add Advanced.
15. Give the XML Firewall object a name.
16. Choose loopback-proxy for Firewall Type, and verify that the port number is valid. After this, the form should appear similar to Figure 6.
    
    Figure 6. Configure XML Firewall object
    
    
    
17. Click the + button next to Firewall Policy to create a new firewall policy.
18. Give the firewall policy a name.
19. Configure the match rule for this rule as desired.
20. Drag a Verify action onto the rule, as shown in Figure 7. Double-click it to bring up the Verify Action configuration screen.
    
    Figure 7. Configure XML Firewall policy
    
    
    
21. Choose the Validation Credentials object created in steps 7-11 from the drop-down list (see Figure 8).
22. Click Done.
    
    Figure 8. Configure Verify Action object
    
    
    
23. Drag a Results action onto the rule, double-click it, and click Done to accept the defaults.
24. Change the rule direction to Client to Server.
25. Verify that your Policy is the same as shown in Figure 9, and click Apply next to Rule Actions.
    
    Figure 9. Configure XML Firewall policy
    
    
    
26. Click Close at the top of the policy configuration window. Your XML Firewall configuration should appear similar to Figure 10.
27. To create the XML Firewall, click Apply at the top of the XML Firewall configuration window.
    
    Figure 10. Configure XML Firewall object
    
    
    

Back to top

Test the implementation

Use the wget application to post the signed XML file to the WebSphere DataPower Integration Appliance XI50. In the output in Listing 9, you can see that the signed document was successfully echoed back to the client; this means that the verification of the signature succeeded.

                
# wget -q -O - -S --post-file=signed.xml http://xi50b:2063/sign
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<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#X509v3" 
wsu:Id="CertId-1828792" xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
MIICFTCCAX6gAwIBAgIEaYxAxzANBgkqhkiG9w0BAQUFADARMQ8wDQYDVQQDEwZzYW1wbGUwHhcNMDcwODMxMTI1OD
U0WhcNMDgwODMwMTI1ODU0WjARMQ8wDQYDVQQDEwZzYW1wbGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK4C
eWss1Fi4sUwMaPZ5Fkd1tcaNW+fMYLz4o1L9DpQqCarlaOeRhYc2PzLAmi6Qu04L17RksZov4Ioq57D9ZpWJDOvJ4e
JXlzDuRq3yAv8D0jD38CUJiyd2AuDYH2naYF575KDqo4JM23upQ9X3n72QP1uMXeWPdGXrQWGw72ufAgMBAAGjejB4
MAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFA875O56gj3t1LTy5Z9VUGRwh858MDwGA1UdIwQ1MDOAFA875O56gj3t1L
Ty5Z9VUGRwh858oRWkEzARMQ8wDQYDVQQDEwZzYW1wbGWCBGmMQMcwCwYDVR0PBAQDAgK8MA0GCSqGSIb3DQEBBQUA
A4GBAIx2GglkdhoJ7HUaCZx1Ggl0dRoJxHAaCexwGgn8dBoJbHMaCfRyGgmMcRoJRHMaCcxyGglkcRoJhHQaCTR0Gg
mccBoJFHEaCQAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAABhbgAA
</wsse:BinarySecurityToken>

<ds:Signature Id="Signature-653534964" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-1367626116">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>lnfpDFV71XKNSFzG562nx+SzNrA=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
Vtx5MScOPZNxjr9hq511Oy+8oAuZSMQhQgaNxMM/a+ud8g6eNYLfybCXhTbjpvNBwuWEXJhCP+i0BIVroHJSM6HYYb
7IMJha0zTG0RLhKLAlrbgQAtQ5qAwG2M/i1X0biqErLmCokMab/aUhDjMIuSCr5CZhqxI4F3E3Sp1HII0=
</ds:SignatureValue>
<ds:KeyInfo Id="KeyId-1493981452">
<wsse:SecurityTokenReference wsu:Id="STRId-308417122" xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

<wsse:Reference URI="#CertId-1828792" ValueType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soapenv:Header>
<soapenv:Body wsu:Id="id-1367626116" xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <books>

      <book>
        <title>War and Peace</title>
        <author>Leo Tolstoy</author>
      </book>
      <book>

        <title>The Catcher in the Rye</title>
        <author>J. D. Salinger</author>
      </book>
    </books>
  </soapenv:Body>

</soapenv:Envelope>

You can also check the logs on the XI50 appliance to see that the signature was in fact verified (see Listing 10).

                
xmlfirewall(verifyDocuments): tid(79808)[request][9.37.211.146]: 
New transaction(conn use=1): POST http://xi50b:2063/ from 9.37.211.146
xmlfirewall(verifyDocuments): tid(79808)[request][9.37.211.146]: 
rule (verifyDocPolicy_Rule_0): selected via match 'AllURLs' from processing policy 
'verifyDocPolicy'
xmlfirewall(verifyDocuments): tid(79808)[request][9.37.211.146]: Multistep Probe enabled
xmlfirewall(verifyDocuments): tid(79808)[request][9.37.211.146]: Accept set
xmlfirewall(verifyDocuments): tid(79808)[request][9.37.211.146]: Accept set
xmlfirewall(verifyDocuments): tid(79808)[request][9.37.211.146]:
                Signature verification succeeded
xmlfirewall(verifyDocuments): tid(79808)[request][9.37.211.146]: 
rule (verifyDocPolicy_Rule_0): #1 filter: 'INPUT store:///verify.xsl' completed ok.
xmlfirewall(verifyDocuments): tid(79808)[request][9.37.211.146]: 
rule (verifyDocPolicy_Rule_0): #2 results: 'generated from INPUT' completed ok.
xmlfirewall(verifyDocuments): tid(79808)[9.37.211.146]: Latency:   
0   0   0   0  44  36   1  44   0   0   0  44   0   0   0   0 [http://xi50b:2063/]

Now let's make a small change to the body of the SOAP envelope. This should invalidate the signature, and the verification should fail (see Listing 11).

                
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<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#X509v3" 
wsu:Id="CertId-1828792" xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

MIICFTCCAX6gAwIBAgIEaYxAxzANBgkqhkiG9w0BAQUFADARMQ8wDQYDVQQDEwZzYW1wbGUwHhcNMDcwODMxMTI1OD
U0WhcNMDgwODMwMTI1ODU0WjARMQ8wDQYDVQQDEwZzYW1wbGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK4C
eWss1Fi4sUwMaPZ5Fkd1tcaNW+fMYLz4o1L9DpQqCarlaOeRhYc2PzLAmi6Qu04L17RksZov4Ioq57D9ZpWJDOvJ4e
JXlzDuRq3yAv8D0jD38CUJiyd2AuDYH2naYF575KDqo4JM23upQ9X3n72QP1uMXeWPdGXrQWGw72ufAgMBAAGjejB4
MAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFA875O56gj3t1LTy5Z9VUGRwh858MDwGA1UdIwQ1MDOAFA875O56gj3t1L
Ty5Z9VUGRwh858oRWkEzARMQ8wDQYDVQQDEwZzYW1wbGWCBGmMQMcwCwYDVR0PBAQDAgK8MA0GCSqGSIb3DQEBBQUA
A4GBAIx2GglkdhoJ7HUaCZx1Ggl0dRoJxHAaCexwGgn8dBoJbHMaCfRyGgmMcRoJRHMaCcxyGglkcRoJhHQaCTR0Gg
mccBoJFHEaCQAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAABhbgAA
</wsse:BinarySecurityToken><ds:Signature Id="Signature-653534964" 
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo> 
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-1367626116">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>lnfpDFV71XKNSFzG562nx+SzNrA=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
Vtx5MScOPZNxjr9hq511Oy+8oAuZSMQhQgaNxMM/a+ud8g6eNYLfybCXhTbjpvNBwuWEXJhCP+i0BIVroHJSM6HYYb
7IMJha0zTG0RLhKLAlrbgQAtQ5qAwG2M/i1X0biqErLmCokMab/aUhDjMIuSCr5CZhqxI4F3E3Sp1HII0=
</ds:SignatureValue>
<ds:KeyInfo Id="KeyId-1493981452">

<wsse:SecurityTokenReference wsu:Id="STRId-308417122" xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Reference URI="#CertId-1828792" ValueType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soapenv:Header>
<soapenv:Body wsu:Id="id-1367626116" xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <books>

      <book>
        <title>War and Peace</title>
	<author>John Grisham</author>
      </book>
      <book>

        <title>The Catcher in the Rye</title>
        <author>J. D. Salinger</author>
      </book>
    </books>
  </soapenv:Body>

</soapenv:Envelope>

Use the wget application to post the (altered) signed XML file to the WebSphere DataPower Integration Appliance XI50. In the output in Listing 12 you can see that there was an error during the processing of the document, which is indicated by the HTTP 500 error.

                
# wget -O - -S --post-file=signed2.xml http://xi50b:2063/
http://xi50b:2063/ => `-'
Resolving xi50b... 9.42.131.159
Connecting to xi50b|9.42.131.159|:2063... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 500 Internal Server Error
  Connection: close
  Content-Type: text/xml; charset="utf-8"
10:15:47 ERROR 500: Internal Server Error.

Now you can check the logs on the XI50 appliance to see that the invalid signature was in fact the cause of the error (see Listing 13).

                
xmlfirewall(verifyDocuments): tid(79606)[request][9.37.211.146]: 
New transaction(conn use=1): POST http://xi50b:2063/ from 9.37.211.146
xmlfirewall(verifyDocuments): tid(79606)[request][9.37.211.146]: 
rule (verifyDocPolicy_Rule_0): selected via match 'AllURLs' from processing policy 
'verifyDocPolicy'
xmlfirewall(verifyDocuments): tid(79606)[request][9.37.211.146]: Multistep Probe enabled
xmlfirewall(verifyDocuments): tid(79606)[request][9.37.211.146]: Accept set
xmlfirewall(verifyDocuments): tid(79606)[request][9.37.211.146]: Accept set
xmlfirewall(verifyDocuments): tid(79606)[request][9.37.211.146]:
                Reject set: Hash values do not match
                xmlfirewall(verifyDocuments): tid(79606)[request][9.37.211.146]:
                Execution of 'store:///verify.xsl' aborted: Hash values do not match.

xmlfirewall(verifyDocuments): tid(79606)[request][9.37.211.146]: 
request verifyDocPolicy_Rule_0 #1 filter: 'INPUT store:///verify.xsl' failed: Hash values 
do not match.
xmlfirewall(verifyDocuments): tid(79606)[request][9.37.211.146]: 
rule (verifyDocPolicy_Rule_0): #1 results: 'generated from INPUT' completed ok.
xmlfirewall(verifyDocuments): tid(79606)[9.37.211.146]: 
Rejected by filter; SOAP fault sent
xmlfirewall(verifyDocuments): tid(79606)[9.37.211.146]: 
Generated error on URL 'http://xi50b:2063/': 
<?xml version="1.0" encoding="UTF-8"?><env:Envelope 
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body>
<env:Fault>
<faultcode>env:Client</faultcode>
<faultstring>Hash values do not match. (from client)</faultstring>
</env:Fault>

</env:Body>
</env:Envelope>
xmlfirewall(verifyDocuments): tid(79606)[error][9.37.211.146]: 
Rejected by filter; SOAP fault sent
xmlfirewall(verifyDocuments): tid(79606)[error][9.37.211.146]: 
No match from processing policy 'verifyDocPolicy' for code '0x00d30003'

As shown in Listing 13, the verification of the signature failed because the hash values didn't match. This is expected because you altered the content of the message after it was signed!

Share this... Digg this story Post to del.icio.us Slashdot it!

Summary

This article showed you how to use the IBM WebSphere DataPower SOA Appliances suite together with the Apache WSS4J library to sign XML documents and verify the authenticity, integrity, and nonrepudiability of the document. You got a brief review of XML signatures and the Apache WSS4J library, as well as an overview of WebSphere DataPower SOA Appliances. The article walked you through a sample scenario that leveraged the efficient and extensible XML and cryptographic processing capabilities of the WebSphere DataPower SOA Appliances to verify an XML signature that was added to the document by a Java program, which used the WSS4J library.

Back to top

Download

	Information about download methods

Resources

• Get more information on the suite of IBM WebSphere DataPower SOA Appliances.
  
  
• Learn more about XML signatures and the WS-Security specification.
  
  
• The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  
• Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
  
  
• The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
  
  
• Stay current with developerWorks technical events and webcasts. Check out the following SOA and Web services tech briefings in particular:
  • Get started on SOA with WebSphere's proven, flexible entry points
  • Building SOA solutions and managing the service lifecycle
  • SCA/SDO: To drive the next generation of SOA
  • SOA reuse and connectivity
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  
• Check out a quick Web services on demand demo.

• Download the following:
  • Apache WSS4J
  • Apache Commons CLI
  • Apache Commons Logging
  • Apache XML Security
  • Apache Xalan-J
  • A copy of the GNU tool wget, a command line HTTP/HTTPS/FTP tool
  
  
• Innovate your next development project with IBM trial software, available for download or on DVD.
  
  

• Participate in the discussion forum.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs, including the following SOA and Web services-related blogs:
  • Service Oriented Architecture -- Off the Record with Sandy Carter
  • Best Practices in Service-Oriented Architecture with Ali Arsanjani
  • WebSphere SOA and J2EE in Practice with Bobby Woolf
  • Building SOA applications with patterns with Dr. Eoin Lane
  • Client Insights, Concerns and Perspectives on SOA with Kerrie Holley
  • Service-Oriented Architecture and Business-Level Tooling with Simon Johnston
  • SOA, ESB and Beyond with Sanjay Bose
  • SOA, Innovations, Technologies, Trends...and a little fun with Mark Colan
  
  

About the author

		Bob Callaway is a software engineer with the WebSphere Technology Institute. He participates in research and development in the integration of middleware and application-aware networking technologies. Before joining the WSTI, he worked with the IBM xSeries® xPert Team on IBM BladeCenter® opportunities. He holds three degrees from North Carolina State University: a Bachelor of Science in electrical engineering, a Bachelor of Science in computer engineering, and a Master of Science in computer networking. He is currently a candidate for the PhD degree in computer engineering at North Carolina State University with a concentration on service-oriented networking. He was awarded the prestigious IBM PhD Fellowship for the 2007-2008 academic year.

原文链接: http://www.ibm.com/developerworks/webservices/library/ws-soa-verifyxml/?S_TACT=105AGX54&S_CMP=A1109&ca=dnw-843