Code through the pain Ladislav Mrnka's professional blog about software development


Last week I had to prepare simple security configuration for WCF service - I needed to configure a test service and a client using mutual HTTPS to achieve secure transport and X.509 Binary Token to authenticate requests. Requests should contain only a message data and a security token and no other security headers like a timestamp were allowed. This proved to be more challenging and frustrating than I expected. I started with the simplest possible configuration using CertificateOverTransport authentication mode but it failed with the exception:

System.InvalidOperationException: Signing without primary signature requires timestamp

I found that I'm not the first one who dealt with this problem. MS Connect contains related  "bug" where I expected to find a solution or workaround because WCF is API designed for interoperability with other platforms, isn't it? Surprisingly I didn't find a solution but instead some very odd answer describing that behaviour is "by design". Well, in the context of the used configuration it is really by design as I will describe in this post but the point of the bug was how to do it and Microsoft representative completely failed to answer the question and marked the problem as fixed because of "by design". This really made me furious so I even wrote my own question to MSDN forum. The rest of this article describes the whole route to the working solution as well as description why initial solution didn't work.

Posted on August 31, 2011 by Ladislav Mrnka
Filed under: WCF
Continue reading

Last week I was working on some SOAP message preprocessing in our current project. We needed to extract raw information about security tokens used in SOAP message and because of that we decided to use WSSecurityTokenSerializer class from System.ServiceModel.Security namespace. This class provides public method ReadKeyIdentifierClause inherited from SecurityTokenSerializer. The method was working fine until we used it to read EncryptedKey token with included ReferenceList. In this scenario the pair method CanReadKeyIdentifierClause returns true, but ReadKeyIdentifierClause is throwing an unexpected XmlException because the method implementation expects the end element for EncryptedKey instead of the start element for ReferenceList. I asked related question on MSDN but I haven't got any answer yet. I think this is a bug.

Using ReferenceList in EncryptedKey is allowed by both WS-Security 1.0 and WS-Security 1.1 specifications and moreover it is result of many security configurations in WCF including BasicHttpBinding with security mode set to BasicHttpSecurityMode.Message and client credentials set to BasicHttpMessageCredential.Certificate. This configuration creates mutual certificate asymmetric security binding which uses exactly that problematic token. The rest of the article shows the test fixture to reproduce the issue.

Posted on April 13, 2011 by Ladislav Mrnka
Filed under: WCF
Continue reading