# Friday, May 28, 2010

When you're using signing or encryption on your SOAP requests, WCF exepects the response to be signed/encrypted too. When the response is not signed/encrypted the message encoder throws a MessageSecurityException. This is perfectly fine behavior, but in interop scenario's can really bug you, because some WS-* implementations don't sign/encrypt Fault messages. Now, because the message encoder throws the exception, you can't get to the underlying SOAP fault. This means that you have no clue why you received a fault in the first place.

To fix this, Microsoft has provided a hotfix. With this hotfix in place you can specify enableUnsecuredResponse="true" in the binding configuration to allow unsecured responses. Unfortunately this means that also valid responses don't have to be signed/encrypted, defeating the purpose of signing and encryption altogether!

As an alternative, you can implement your own message encoder that wraps the encoder that is actually used. In the wrapper you can either store the received XML for use higher up in the call stack, or retrieve the fault and throw a FaultException<>. Without jumping through hoops the latter option does require your wrapper to know about the fault types it needs to handle. With the former option you can handle the exception higher up in the call stack by catching the MessageSecurityException and throwing a new exception with the XML of the message as a property.

Friday, May 28, 2010 3:09:27 PM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, April 02, 2010

If you've ever tried svcutil.exe to import WSDL which has doesn't have <sp:OnlySignEntireHeadersAndBody> specified in the security policy, you'll know that this doens't fly. SvcUtil will tell you the the security policy is not supported. So why is this? I assume this has something to do with the a statement in paragraph 6.6 in the WS-SecurityPolicy specification, which states:

Setting the value of this property to 'true' mitigates against some possible re-writing attacks.

So apparently Microsoft decided that setting it to false is not a good idea, and decided not to support setting it to false (omitting the element).

 

Friday, April 02, 2010 2:01:07 PM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 

Talking to a non-WCF webservice is like a box of chocolates... you never know what you're going to get. After solving the issue mentioned in my previous blog post, I had another problem. For some reason the service didn't expect a <wsa:ReplyTo> element if the value was anonymous. Later on the other party adjusted the service so it actually worked as expected from WCF, but in the mean time I did write a message inspector to solve the problem. Besides solving the problem it also is a nice little example of a message inspector.

public class RemoveAnonymousReplyToMessageInspector : IClientMessageInspector
{
    private const string ReplyToNode = "ReplyTo";
    private const string WSAddressingNamespace = "http://www.w3.org/2005/08/addressing";

    public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
    {} // Not used for this scenario.

    public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel)
    {        // This method is called before the request is sent. You can read/manipulate the message here.        // If you're using signing or encryption, that is done after this, this is the        // unencrypted/unsigned mesage.
        request = RemoveAnonymousReplyTo(request);
        return null;
    }

    private Message RemoveAnonymousReplyTo(Message message)
    {
        if (message.Headers.ReplyTo.IsAnonymous == true)
        {
            int index = message.Headers.FindHeader(ReplyToNode, WSAddressingNamespace);
            message.Headers.RemoveAt(index);
        }
        return message;
    }
}

To use this, you'll need to create a class implementing the IEndpoint behavior and add the MessageInspector in ApplyClientBehavior, as follows:

public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
{
    RemoveAnonymousReplyToMessageInspector inspector = new RemoveAnonymousReplyToMessageInspector();
    clientRuntime.MessageInspectors.Add(inspector);
}
Friday, April 02, 2010 1:52:50 PM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 

Recently I found myself trying to talk to a webservice using signing. It was a WCF calling a Java webservice using a certificate to sign messages. I kept getting the following exception message:

The incoming message was signed with a token which was different from what used to encrypt the body. This was not expected.

After a wild goose chase we finally figured out that the certificate was corrupted. Just installing the certificate again solved the issue.

Friday, April 02, 2010 1:40:56 PM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, December 16, 2009

We're doing a project where were talking to non-.NET web services and this means that sometimes we have to see what the exact message looks like. In case you ever need to do this: a MessageInspector will not (always) be suitable for this. This is particularly the case where you're using a certificate to sign the message. Signing happens after the MessageInspector is invoked, so it will just show you the unsigned message. One thing you can do is setup a URL you can post to that logs the incoming message as is. We have a "service" like that available to all developers, because it is a quick and easy solution that doesn't require installing additional tooling or modify code. Another option is to configure message logging (see the MSDN article Recommended Settings for Tracing and Message Logging).

Wednesday, December 16, 2009 2:36:14 PM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, April 02, 2009

I'm delighted to be speaking again at VSLive in June. This time at the Venetian hotel in Las Vegas. I'll being doing two sessions on Monday, June 8:

  • Understanding Transactions in WCF, which deals with why, how, and when to use transactions in WCF.
  • Advanced Access Control with WCF, which deals with claims based authorization and the Geneva Framework.

Over lunch I will be available for 1-on-1 Q&A, but if you run into me at other times outside my sessions I'm open for questions too.

Checkout the full conference agenda for all the great sessions and speakers at VSLive, Las Vegas. I can really recommend going there, because the sessions are great and the speakers very accessible. I also think the Venetian will be a great venue (I have never stayed at the Venetian, but I have been inside and it is definitly something to see).

English | Events | WCF
Thursday, April 02, 2009 10:44:20 PM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, March 02, 2009

Thank you for all who attended my sessions in San Francisco. Below are the slides and samples for my sessions.

VTH4 - Understanding Transactions in WCF Slides (561.73 KB) | Samples (540.1 KB)

VTH16 - Supporting POX/REST with WCF Slides (369.58 KB) | Samples (302.82 KB)

VTH25 - Simplify WebPart (and Control) Development with WebPart Skinning Slides (359.85 KB) | Samples (447.66 KB)

The VTH25 samples include the full installer. However, be sure to change the uploadskinfeature.bat to point to the correct server. You can read more about the VirtualPathProvider I mentioned in VTH25 session here.

.NET | ASP.NET | English | Events | SharePoint | WCF
Monday, March 02, 2009 11:25:30 PM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, January 07, 2009

The wonderful folks at VSLive! have invited me again to do three sessions at their San Francisco event from February 23 to February 27, 2009. These are the sessions I'll do (all on Thursday 26):

  • Understanding Transactions in WCF
  • Supporting POX/REST with WCF
  • Simplify WebPart (and Control) Development with WepPart Skinning

The first two are obviously about WCF. The last talk is primarily about SharePoint, but the discussed techniques will work with ASP.NET WebParts and WebControls as well.

I really like VSLive! because they have some great content and top tier speakers. The speakers (myself included of course) are also very accessible, because the event is not as huge as some of the other conferences these days. So if you intend to go to a conference this year, VSLive! is going to be worth your money.

.NET | ASP.NET | English | Events | SharePoint | WCF
Wednesday, January 07, 2009 10:52:13 PM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, December 22, 2008

Have you ever wondered if/when a transaction in WCF upgrades to the DTC? There two simple ways to check this:

  1. Open Performance Monitor and add a new counter. Get the counter Active Transactions from the Distributed Transaction Coordinator section.
  2. Open Component Services and go to My Computer in COM+. There is a folder for Distributed Transaction Coordinator, through which you can view the DTC statistics.

In both cases, you'll see the active transactions jump from 0 to 1 when a transaction upgrades to DTC. This happens when you cross a service boundary. If you just use a transaction within the service, WCF will stick to the Lightweight Transaction Manager as long as you stay within you AppDomain or access a single database (SQL Server 2005 and up).

English | WCF
Monday, December 22, 2008 11:16:52 AM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 

For those of you that attended my sessions in Dallas, here are the demo's for

If you attended the latter, you'll remember that I wrecked my prepared demo (note to self: never change configs just before a session). I finally figured out what was wrong. I changed some configuration on the server side and I thought I did the same on the client. Apparently I did not, because when I updated the service reference on the client it worked.

English | Events | WCF
Monday, December 22, 2008 11:11:49 AM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  |