Blasphemy ...

It is finally published. After many, many, and I mean, many months of paying the process tax for this piece, it is finally LIVE !

I started this piece with the first ever March 2005 CTP of Windows Communication Foundation (WCF, previously - Indigo) and I went through so many port demos and edit document cycles its so unbelievably painful ...

But it is really good to see this in online form and shape.

I started with this idea even though MSFT Corp has explicity stated that it will not support any form of interoperability between WSE 2.0 and WCF, even though it is "theoretically possible to develop Web services using WSE 2.0 in such a way that they can interoperate with WSE 3.0 (and WCF) by using only a reduced set of specifications"

More importantly, the main reason for the motivation to write such a piece is written in the article itself and I quote:

[BEGIN QUOTE]

---

...WSE 2.0 has seen 3 service pack releases since its official launch in 2004. It implemented the OASIS Web Services Security 1.0 specification which was the widely accepted interoperability standard protocols between secured web services as well as the implementations of WS-Addressing, WS-SecureConversation and WS-Trust. It was integrated very nicely into Visual Studio 2003. Even BizTalk Server 2004 carries with it a WSE 2.0 adapter for securing of Web Services. Thus, it would be fair to assume that there is more than its fair share of implementations in the market today.

 

Depending on timing, budget, complexity and a whole host of other requirements, some of these applications will need to be moved and migrated to WSE3.0 and some to WCF. Aaron Skonnard has provided a great resource in his “Service Station” column on MSDN on a brief overview on the migration of WSE 2.0 applications to WSE 3.0 ones. However, as stated in his article, there are some major changes in the programming model and architecture in WSE 3.0 and migrating them from WSE 2.0 may not be trivial.

Another very important factor to take note is while WinFX, and therefore WCF, is available downstream from Windows Vista to Windows 2003 and Windows XP. That is as far down as it goes. There still exists a huge installed base of Windows 2000 Servers out there running on server and data farms and if you need to implement the advanced Web Services stacks on those servers, WSE is still a very important strategy you cannot ignore.

As noted in the above guidelines, even though Microsoft will not guarantee interoperability between WSE 2.0 and WCF, the good news is that there are a few WSE 2.0 common scenarios, which can allow wire-interoperability with WCF. I will illustrate them in the next section...

---

[END QUOTE]

 

So, this article will outlined WHAT that reduced set of specifications are and HOW to go about using them.

Many Special Thanks go to Kirill, the Interop PM on WCF, who gave me a couple of tips to get over the port-over humps I had thoughout this piece since last year. And of course, I cannot forget Clemens, who is the catalyst to making this publication happen when he came onboard.

I hope this helps at least someone out there. Enjoy !

Not quite as complicated as it may sound.

Web Services Enhancements (WSE) 3.0 allows that re-usability element aspect. Say I am writing a ASMX 2.0 service with an intent to host it in another [internal ?] process via another transport (TCP, SMTP, MSMQ), I can easily do so.

The *.asmx file that contains

<%@ WebService Class="SomeSWMNamespace.SomeSWMService"%> is equivalent to WSE 3.0's

Protected Overrides Sub OnStart(ByVal args() As String)
    Dim address As Uri = New Uri("soap.tcp://swm/someSWMwindowsservice")
    SoapReceivers.Add(New EndpointReference(address), GetType(SomeSWMStockService))
End Sub

that is hosted via a Windows Service Process. Of course, the architecture of ASP.NET and IIS specifies the vDir and the physical *.asmx file as the physical endpoint address while you get to specify your own if you host it via another process.

In other words, the IHTTPHandler class for asmx endpoints and the Winows Service are different processes accessible via different transports (Http and Tcp) but hosting the same codebase. Incidentally, this codebase is a .NET Class Library with all the fanciful attribute decorations:

<WebServiceBinding(Name:="SomeSWMService", _
   Namespace:="urn:ns.softwaremaker.net-someService", _
   ConformsTo:=WsiProfiles.BasicProfile1_1, EmitConformanceClaims:=True)> ...

<WebService(Namespace:="urn:ns.softwaremaker.net-someService")> _
<Policy("SWMTracePolicy")> ...

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.

I have been back fiddling at the Web Services Enhancements (WSE) 3.0 technology space for the past few weeks and I am now grokking into the plumbings since there are quite a few forums, blogs, posts out there focusing on the higher-level abstract programming model.

I am very pleased that WSE 3.0 has implemented WS-Security Specifications 1.1 at its very core, so much so that it is the de-facto security standard to be used in most of the Turnkey Security Assertions that comes with the product.

One of the things that I have always been asking for through my contacts and channels in the OASIS WS-Security Technical Committee is the ability to sign my document snippets with a symmetric key instead. Since XML-Encryption already utilized symmetric key encryption via the [xenc:EncryptedKey] [1] for performance and throughput reasons, there is no reason why XML-Digital Signature cannot do the same. While the improvements in throughput may be slight due to the fact that in digital signatures, messages are already hashed before encryption, it is still a viable option that should be made available.

In WS-Security 1.0, this is what is commonly seen in the Digital Signature Parts:

---

...
[wsse:BinarySecurityToken ValueType="...oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="...oasis-200401-wss-soap-message-security-1.0#Base64Binary"
wsu:Id="SecurityToken-7b5d..."]MIIBxDCCAW...[/wsse:BinarySecurityToken]
 
  [Signature xmlns="http://www.w3.org/2000/09/xmldsig#"]
  [SignedInfo]
  [CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /]
  [SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /]
  [Reference URI="#Id-f7e1..."]
  [Transforms]
  [Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /]
  [/Transforms]
  [DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /]
  [DigestValue]avMezj5NhZwNerXidi5oBmjqi/g=[/DigestValue]
  [/Reference]
  ...
  [/SignedInfo]

[SignatureValue]SJfnqZeDHboWDI2n2gWHqTJO5hXvZOFQw8UtDdajktzR40H+W6D
prs5CW/l9A5TF3xcFfyryA3hz7c+0vdlZSnaA+cBn2qPxt7/YmwaAx5Ave
awuach6YPYI123I4I3f58eSMUgPsx6/uuFQFcJltEMw1nWLE6Wb6CPg5OdtXLs=[/SignatureValue]
  [KeyInfo]
  [wsse:SecurityTokenReference]
  [wsse:Reference URI="#SecurityToken-7b5d..."
ValueType="...oasis-200401-wss-x509-token-profile-1.0#X509v3" /]
  [/wsse:SecurityTokenReference]
  [/KeyInfo]
  [/Signature]

---

Now in WS-Security 1.1 via WSE 3.0, I can do this:

---

[xenc:EncryptedKey Id="SecurityToken-32e4..." xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"]
  ...
  [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]n6PnkIWb+QsIeOPehLdtQQKYZn202uGqhN+ShCWyBaCf20rmVcta
Bw2MhB1fv9pE0hOLpAxMMT5ffk4/hnwZ/ef2XcZediF6ySfpse14TI2TGy
cp9XErpeYlZNn1wSchHlOEz2gVYfViZoEOIwn8qR7EofLN3U3Mc5Zp2qG2coI=[/xenc:CipherValue]
  [/xenc:CipherData]
  [xenc:ReferenceList]
  [xenc:DataReference URI="#Enc-0914..." /]
  [xenc:DataReference URI="#Enc-3aab..." /]
  [/xenc:ReferenceList]
  [/xenc:EncryptedKey]
  [xenc:EncryptedData Id="Enc-0914..." Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"]
  [xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /]
  [xenc:CipherData]  [xenc:CipherValue]RLASn...[/xenc:CipherValue]
  [/xenc:CipherData]
  [/xenc:EncryptedData]

[Signature xmlns="http://www.w3.org/2000/09/xmldsig#"]
  [SignedInfo]
  ...
  [SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" /]
  [Reference URI="#SecurityToken-d217..."]
  [Transforms]
  [Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /]
  [/Transforms]
  [DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /]
  [DigestValue]A0K7OVwZN3vP4rIXfbTZYy+f+ck=[/DigestValue]
  [/Reference]
  [Reference URI="#Timestamp-6f12..."]
  ...
  [/Reference]
  [/SignedInfo]
  [SignatureValue]d8KmXpfspmKiEOZ1eBVY7mk05Wo=[/SignatureValue]
  [KeyInfo]
  [wsse:SecurityTokenReference]
  [wsse:Reference URI="#SecurityToken-32e4..."
ValueType="...oasis-wss-soap-message-security-1.1#EncryptedKey" /]
  [/wsse:SecurityTokenReference]
  [/KeyInfo]
[/Signature]

---

Note the fonts in RED. There is a new URI: http://docs.oasisopen.org/wss/oasiswss-soap-messagesecurity-1.1#EncryptedKey which ties to a ValueType: A token type of an [xenc:EncryptedKey]

... and more importantly ...

the [SignatureValue] contents is slightly shorter now because it is actually encrypted with a symmetric key now. I know I may be picking here BUT hey, even a single byte in reduction means a lot in throughput performance in terms of wire transfer of documents. .

There are other improvements WS-Security 1.1 brings over its predecessor 1.0, which I will blog more about as I go along.

[1] Just a note to defuse any confusion if it crops up: Asymmetric (Public-Private) key technologies are still very much used in WS-Security and other document-related security specifications today. I dont think it will be dropped anytime soon unless Quantum Cryptography takes off mainstream in a big way or the subtle effects of this reverberates adversely through the security space. Having said that, Symmetric (Master/Session) key technologies have a huge place in the security specifications world too, just by the fact that it is a 1000x faster than much-secure asymmetric ones. Therefore, both technologies co-exist and work very well together in the document security space. To put it simply, a symmetric key (KeyA) is randomly-generated (key-length can be specified by the application - the longer, the better) and then used to encrypt/decrypt messages (MsgA). Once that is done - KeyA is then subsequently encrypted by an asymmetric key (KeyB) and then transmitted through the message. Only the holder of the Private-Key pair of KeyB will be able to decrypt KeyA which can then decrypt/encrypt MsgA.

In Web Services Enhancements (WSE) 2.0, one could exercise some control over what one xml element/fragments wants to encrypt within a soap:Body. Therefore, if I wanted to encrypt the account string in my credit card type, I could do something like this:

[At your Service Side]

---

Public Class SecuredCreditCard
  <XmlElement(ElementName:="CreditCardType")> _
  Public Type As String
  <XmlElement(ElementName:="CreditCardAccount")> _
  Public Account As SecuredString
End Class

Public Class SecuredString
  'Set the Oasis Id that our security reference will point to
  <XmlAttributeAttribute("Id", _
Namespace:=".../2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd")> _
  Public ID As String
  <XmlText()> _
  Public Data As String
End Class

[At your Calling side]

---

Dim a As localhost.IndexWse = New localhost.IndexWse
Dim b As localhost.SecuredCreditCard = New localhost.SecuredCreditCard
Dim z As localhost.SecuredString = New localhost.SecuredString

Dim c As SoapContext = a.RequestSoapContext

b.CreditCardType = "VISA"
z.Id = "uri:demoId.softwaremaker.net" 'or some guid
z.Value = "123-456-789"
b.CreditCardAccount = z

c.Security.Elements.Add(New EncryptedData(tok, "#uri:demoId.softwaremaker.net"))

Note: To reduce headache-inducing typo bugs, you may want to use some WSE Constants such as
WSUtility.Prefix
WSUtility.AttributeNames.Id
WSUtility.NamespaceURI

The end result of this is a soap:Body on the wire looks like this:

---

<SecureCreditCard>
 <CreditCardType>VISA</CreditCardType>
 <CreditCardAccount d4p1:Id="uri:demoId.softwaremaker.net" xmlns:d4p1=".../2004/01/oasis- 200401-wss-wssecurity-utility-1.0.xsd">
  <xenc:EncryptedData Id="EncryptedContent-3d793117-f020-4236-a0a0-0ed545d9bf1a" Type=".../2001/04/  xmlenc#Content" xmlns:xenc=".../2001/04/xmlenc#">
  <xenc:EncryptionMethod Algorithm=".../2001/04/xmlenc#aes128-cbc" />
  <xenc:CipherData>
  <xenc:CipherValue>FRFCiq...+0W5oS4</xenc:CipherValue>
  </xenc:CipherData>
  </xenc:EncryptedData>
 </CreditCardAccount>
</SecureCreditCard>

While I dont know how much of performance benefits this has over one that has the entire SecureCreditCard encrypted (since it is an symmetric-key encryption at its core), I think in terms of latency and throughput, it does offer some benefits especially with a sizable payload (>20-30 kb, for instance ?)

Windows Communication Foundation (WCF, previously - Indigo) does not currently have that feature build in at the moment (Sept05-CTP or known as the PDC-bits). In other words, in WCF today, you encrypt the entire contents of the soap:Body, lock-stock-barrel. I would still love that WSE feature in there: To be able to exercise finer grain control over what I want to or not to encrypt within a soap:Body.

Would really like to find out if I am the only odd one out there. Any users using that existing WSE feature out there that would love to see the same in WCF or do you have other better ideas ? Leave a comment or email me via the contact link on the side. Thank you.

BTW: Whether you encrypt certain elements of the contents or encrypt the entire contents of the soap:Body, both are WS-Security Specifications compliant.
 

Web Services Enhancements (WSE) 3.0 CTP is released.

Here it is. The runtime is here. The notes for the CTP are here. The HOLs are here and here. Go geek out !