This post continues exploring the use of XML Digital Signature; this time we look at WS-Security Integrity (use of XML Digital Signatures with WS-Security). Our examples show a digital signature and a timestamp in a WS-Security <Security> SOAP Header.
For this example, we will use the SOAP Web Service that was introduced in this DataPower tutorial. The typical SOAP Response for this Web Service will look something like:
<soapenv:Envelope xmlns:ws="http://ws.rcbj.com/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ws:sumResponse>
<return>9</return>
</ws:sumResponse>
</soapenv:Body>
</soapenv:Envelope>
If we add a digital signature and timestamp using WS-Security to this response, the message will look something like this. I tried to fit the full message on this screen, but the formatting wasn’t working. So, I’ll add snippets as appropriate in the following discussion.
The first thing to notice between the original SOAP Message and Message with the timestamp and digital signature added is the size increase. The original message is 317 bytes in length; the message with digital signature and timestamp is 4358 bytes in length. That is almost 14X larger. Of course, in the real world, soap responses for services doing real work will probably be longer than 317 bytes. Nevertheless, criticism surrounding WS-Security having bloated messages and overhead is not unfounded. Of course, any effective security solution that satisfies the same requirements will have similar characteristics.
WS-Security places all security meta-data in a SOAP Header called <Security>. In this example, with the namespace, the SOAP Security header is called <wsse:Security>. Notice that the soapenv:MustUnderstand property is set to ‘1’. This means that any SOAP Actor that encounters this messagae (Service Consumer and Service Provider) must be able to understand the <Security> header. The wsse namespace is defined as xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" per the WS-Security 1.0 spec. The DataPower Sign Action that generated this signature was configured to follow Strict WS-Security Security Header Layout.
<wsu:Timestamp wsu:Id="." xmlns:wsu=".">
<wsu:Created>2012-12-31T23:50:43Z</wsu:Created>
<wsu:Expires>2012-12-31T23:55:43Z</wsu:Expires>
</wsu:Timestamp>
The first child element of the <Security> element is a <Timestamp> element. The timestamp defines the creation time of the service and how long the message is considered valid. Notice that an Id property is defined that gives the <Timestamp> element a unique name. This will be used later in the <Signature> element to reference the <Timestamp> element (the timestamp is included in the digital signature).
<wsse:BinarySecurityToken wsu:Id="." EncodingType=".” xmlns:wsu="">
MIIDOjCCAqOgAwIBAgIEdOq6L.
</wsse:BinarySecurityToken>
The next child element of the <Security> element is the <BinarySecurityToken> element. This contains the base-64 encoded X509v3 public signer certificate that corresponds to the private key that was used to generate the digital signature. If we add ‘\n’ characters every ?? characters, and add the Header and Footer lines, you will have a PEM file. Check out this post explaining how to accomplish this conversion. I always recommend including the public signer certificate in the message(Direct Reference).
The last child element of the <Security> element is the <Signature> element that contains the digital signature. We’ve seen a previous example that was similar to this signature. The notable differences are:
- There are now two <Reference> elements in <SignatureInfo> element. Notice that one points at the message body of the SOAP Message and the other points at the timestamp that was described previously.
- The other difference is the <KeyInfo> element contains a <SecurityTokenReference> that points at the <BinarySecurityToken> element described above.
The rest of the <Signature> element is described here.
The various specifications that are used in this example are listed here.