 | 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.
| |
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.
 |
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.
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.
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.
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
- 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.
- Click the Crypto Tools link under the Miscellaneous header.
- On the Generate a Key tab, fill in the Common Name (CN) and File
Name fields.
- Make sure the Export Private Key, Generate Self-Signed
Certificate, and Export Self-Signed Certificate options are all set
to on.
- 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
- Click the Generate Key button. A pop-up window appears asking you to
confirm the key and certificate generation.
- 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
- Click Close.
Now you need to retrieve the private key and public certificate that were
generated.
- Click the File Management link under the Administration tab on the left
side of the screen (located under the Main header).
- Expand the temporary folder to reveal the three exported files from
your key- and certificate-generation process.
- 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:
- 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
|
- 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.
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.
Listing 3. Example crypto.properties file
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.
Listing 4. Compile SignEnvelope.java using javac
$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.
Listing 5. Running SignEnvelope
$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.
Listing 6. Running SignEnvelope in verbose mode
$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.
Listing 7.
Ensuring the document was 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>
|
|
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.
- From the DP control panel in the WebGUI, click Keys and Certs
Management.
- Choose Certificates, and click Add.
- Give the Certificate object a name (I used
pubcert).
- 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.
- Enter the password twice for the certificate. Your screen should look similar
to Figure 4.
Figure 4. Configure Crypto
Certificate object
- Click Apply.
- Click the Control Panel link on the left side of the WebGUI.
- From the DP control panel in the WebGUI, click Keys and Certs
Management.
- Choose Validation Credentials, and click Add.
- Enter a name for the Validation Credentials object, such as
sampleVC.
- 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
- Click Apply.
- From the DP control panel in the WebGUI, click XML Firewall.
- Click Add Advanced.
- Give the XML Firewall object a name.
- 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
- Click the + button next to Firewall Policy to create a new firewall
policy.
- Give the firewall policy a name.
- Configure the match rule for this rule as desired.
- 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
- Choose the Validation Credentials object created in steps 7-11 from the
drop-down list (see Figure 8).
- Click Done.
Figure 8. Configure Verify
Action object
- Drag a Results action onto the rule, double-click it, and click
Done to accept the defaults.
- Change the rule direction to Client to Server.
- 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
- Click Close at the top of the policy configuration window. Your XML
Firewall configuration should appear similar to Figure 10.
- To create the XML Firewall, click Apply at the top of the XML Firewall
configuration window.
Figure 10. Configure XML
Firewall object
|
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.
Listing 9. Testing the verification process on the WebSphere DataPower Integration Appliance XI50
# 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).
Listing 10. Verifying that signature verification succeeded
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).
Listing 11. Changing the SOAP body
<?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.
Listing 12. Changing the SOAP body
# 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).
Listing 13. Checking the log messages on the WebSphere DataPower Integration Appliance XI50
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!
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.
Download | Description | Name | Size | Download method |
|---|
| Sample Java and XML files for this article | wss4jExample.zip | 9KB | HTTP |
|---|
Resources Learn
Get products and technologies
- Download the following:
- Innovate your next
development project with
IBM trial software,
available for download or on DVD.
Discuss
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. |
Rate this page
| |
