Using OASIS Username Token profile in WCF

WCF is set to follow the OASIS Web Services security standards (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf). However, it adds some restrictions to the implementation of the standard that renders useless the interoperability with other in-place systems that follow the standards.

Problem is that OASIS has two different password types #PasswordText and #PasswordDigest. WCF only supports the former arguing, correctly, that the later is not secure enough and can be easily broken by a hacker with a dictionary attack.

The UserName token is implemented as a tag in the header that consist in the following (see the OASIS standard for more detailed information):

<Security xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> 
<wsse:UsernameToken xmlns:wsu='http://docs.oasis-…-1.0.xsd'> 
<wsse:Username>vortex</wsse:Username> 
<wsse:Password Type='http://docs.oasis-…#PasswordText'> 
ajadex12345 
</wsse:Password> 
</wsse:UsernameToken> 
</Security>

and when using #PasswordDigest it could look like this:

<Security xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> 
<wsse:UsernameToken xmlns:wsu='http://docs.oasis-…-1.0.xsd'> 
<wsse:Username>vortex</wsse:Username> 
<wsse:Password Type='http://docs.oasis-…#PasswordText'> 
ajadex12345 
</wsse:Password> 
<wsse:Nonce EncodingType='http://docs.oasis-#Base64Binary'> 
P92CaT6ncSUnjYUiado6Yh1= 
</wsse:Nonce> 
<wsu:Created>2010-05-17T23:05:07.944Z</wsu:Created> 
</wsse:UsernameToken> 
</Security> 

In order to communicate with an existing Web Service that uses #PasswordDigest and requires the additional parameters of Nonce and Created in the Security Header we need to use the extensibility features of WCF because the current implementation will not generate this header.

We have two options here: implement a Custom Security Token (http://msdn.microsoft.com/en-us/library/ms731872.aspx and http://msdn.microsoft.com/en-us/library/ms751517.aspx) or intercept the request and attach the Security Header. I had no luck with the first option and couldn’t find a proper example on Internet. With the second choice however, I was able to get things working as I made an implementation attaching the Security Header. That I would be writing in the next post.