With regards to my post here, I thought I expand on one of many enhancements that WS-Security Specifications 1.1 brings.
"MutualCertificate11Security" assertion is one of the few security turnkey assertions in Web Services Enhancements (WSE) 3.0 and what basically it is is that the client and server are authenticated using X.509 certificates (X509SecurityToken). Message-level security is implemented using X509SecurityToken security tokens. This turnkey security assertion requires WS-Security 1.1
Once that is configured and implemented properly, it is rather interesting to see what transcends on the wire. Here is a brief snippet:
[wsse:Security soap:mustUnderstand="1"]
...
[wsse:BinarySecurityToken ValueType="...oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="...wss-soap-message-security-1.0#Base64Binary" wsu:Id="
SecurityToken-76ae..."]MIIBvD...[/wsse:BinarySecurityToken]
[xenc:EncryptedKey Id="SecurityToken-6ec8..." xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"]
[xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"]
[ds:DigestMethod xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /]
[/xenc:EncryptionMethod]
[KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"]
[wsse:SecurityTokenReference]
[wsse:KeyIdentifier ValueType="...oasis-wss-soap-message-security-1.1#ThumbprintSHA1" EncodingType="...oasis-200401-wss-soap-message-security-1.0#Base64Binary"]qRTA40Xfk6w1Os3mgpgy8UgwR/Y=[/wsse:KeyIdentifier]
[/wsse:SecurityTokenReference]
[/KeyInfo]
[xenc:CipherData]
[xenc:CipherValue]hBfCfVmg...[/xenc:CipherValue]
[/xenc:CipherData]
[xenc:ReferenceList]
...
[/xenc:ReferenceList]
[/xenc:EncryptedKey]
[Signature Id="Sig-b679..." xmlns="http://www.w3.org/2000/09/xmldsig#"]
[SignedInfo]
[ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" /]
[SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" /]
[Reference URI="#Id-5cdc..."]
...
[/Reference]
[/SignedInfo]
[SignatureValue]O/PdsVMS4PTIBtrx8eyFNzbTnjc=[/SignatureValue]
[KeyInfo]
[wsse:SecurityTokenReference]
[wsse:Reference URI="#SecurityToken-6ec8..." ValueType="...oasis-wss-soap-message-security-1.1#EncryptedKey" /]
[/wsse:SecurityTokenReference]
[/KeyInfo]
[/Signature]
[Signature xmlns="http://www.w3.org/2000/09/xmldsig#"]
[SignedInfo]
[ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" /]
[SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /]
[Reference URI="#Sig-b679..."]
...
[/Reference]
[/SignedInfo]
[SignatureValue]PDm4wS+3hzmXugHL1wcTWZXHcaGKkODVHU48XvVNC6catxiOr25
xq9AGN8u8CgYo1JlnoEf2tuCUl86krKiUBSnMR/towfAs2doGg6a+vtjIl9F54c/VZtTPgwn
QdZtJ28E8+ep5MIS2i+9Tamnui6qpX16IS3J1FcMjVBHQpMs=
[/SignatureValue]
[KeyInfo]
[wsse:SecurityTokenReference]
[wsse:Reference URI="#SecurityToken-76ae..." ValueType="...wss-x509-token-profile-1.0#X509v3" /]
[/wsse:SecurityTokenReference]
[/KeyInfo]
[/Signature]
...
One thing that you will noticed is that there are 2 Digital Signatures generated.
The first one has a ReferenceID, which hints that it will be subject to encryption/signatures later on, and it is signed by a EncryptedKey type (which I talked about in my earlier post). Because it is encrypted by a symmetric key "#SecurityToken-6ec8", the [SignatureValue] is rather short and this signature basically signs the soap:Body with an URI of "#Id-5cdc..." The [EncryptedKey] value can be decrypted and derived by the server's private key
The second signature basically signs the first signature (#Sig-b679...) and it signs it with the Client's Private Key that only the corresponding Public Key Pair can decrypt. The Public Key, together with the client's cert is sent over the wire via a [wsse:BinarySecurityToken] (#SecurityToken-76ae...). Because an asymmetric key is utilized here, the [SignatureValue] is relatively longer than the first signature.
As we can see from here, the first signature signs the soap:Body and the second signature signs the first signature. These are generally known as "Supporting Tokens". These additional tokens may be specified to augment the claims provided by the token associated with the “message signature” provided by the Security Binding. Supporting tokens may be specified at a different scope than the binding assertion which provides support for securing the exchange.
There are four properties related to supporting token requirements which may be referenced by a Security Binding: [Supporting Tokens], [Signed Supporting Tokens], [Endorsing Supporting Tokens] and [Signed Endorsing Supporting Tokens]. Four assertions are then defined to populate those properties: SupportingTokens, SignedSupportingTokens, EndorsingSupportingTokens, and SignedEndorsingSupportingTokens.
What I have shown above is known as the [EndorsingSupportingTokens].
The [SignedEndorsingSupportingTokens] is a combination of [SignedSupportingToken] and [EndorsingSupportingToken] and I will talk about that in a future post.