BizTalk ... WCF ... ProtectionLevel - a joust to the death (Part 1) - A world apart from the everday ...

A world apart from the everday ...

Assert.IsTrue(Entries.Count == 0);

BizTalk ... WCF ... ProtectionLevel - a joust to the death (Part 1)

BizTalk Server 2006 R2 has brilliant support for WCF out of the box; in fact I use it’s WCF based adapters almost exclusively now, unless I have a specific line of business system, like S.A.P / Microsoft Dynamics to connect to.

It is really painless to both host your orchestration (publish schemas actually) as WCF services, and equally easy to consume a WCF from within your business processes.

Up until now everything that I have been able to do with WCF when consuming a service in a regular .NET client I have been able to do with BizTalk. The WCF-Custom adapter gives you so much control with option after option after option allowing you to build up your regular app.config with a relatively intuitive GUI …

So, if it’s all that easy and straight forward then why the purpose of this post? Well … as you probably gathered from the title not everything is as peachy as it first appears.

On a project I am currently working on; [can’t tell it’s top secret :P] we have written a number of WCF services and are using BizTalk as the glue that ties everything together (amongst other things of course). We’re using certificates for signing each service call. In some deployments of this product we’d also want to use certificates for encrypting the message payload as well, in addition to offering transport level security like Https etc. Yes, the data that is being moved around is very very sensitive data! On other deployments where all the services operate within the boundaries of a protected and secured environment we want to be able to remove encryption to get rid of the additional overhead associated with encryption / decryption of every single service call.

In WCF you can set the ProtectionLevel on your service contract

   1: [ServiceContract(
   2:     Namespace = "http://ws_test1", 
   3:     Name = "ServiceContract", 
   4:     ProtectionLevel = ProtectionLevel.Sign 
   5: )]
   6: public partial interface IServiceContract
   7: {
   8:     ...
   9: }

Nice.

So for the first round of development and testing we were running with EncryptAndSign;  and everything worked real nice! Until one of the developers used Sign only. When he did this suddenly BizTalk complained.

“Message body part was not encrypted.”

This was found on the receive shape of the two way send port talking to the service. I checked all the logs on the service and it was definitely called and it built up the response and sent it out fine. For some reason BizTalk was expecting the response to be encrypted!?!?! But Why?

I hunted through piles and piles and piles of different options in the config of the WCF-Custom adapter. Checked behaviours, bindings, everything we could think of and nothing seemed to work.

With the same BizTalk config if we just redecorated the service to EncryptAndSign … presto BizTalk was happy. Fiddler and WCF diagnostics confirmed that the service was encrypting the response and obviously BizTalk was happy with this.

Am I the only person in the world thus far to try this?

I Google’d and found two posts that were about the same thing, so clearly others have tried but failed …

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4022638&SiteID=1

&

http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=1935360&SiteID=1

but sadly on closer inspection these posts cross-reference each other, both saying to check out the other one for a solution.

I posted many requests to the BizTalk newsgroups and forums

http://groups.google.com/group/microsoft.public.biztalk.general/browse_thread/thread/76557fd301851c9a/de1bd9974a056fb5?lnk=gst&q=EncryptAndSign#de1bd9974a056fb5

&

http://groups.google.com/group/microsoft.public.biztalk.server/browse_thread/thread/5699ce6a8ed0ee31/a5a118bc3cf1a03c?lnk=gst&q=EncryptAndSign#a5a118bc3cf1a03c

But no useful response from anybody on the forums.

This can’t be!

Stayed tuned for more … because a solution has been found and I busy writing this up and will post here once it is done and tested.

Posted: Dec 06 2008, 10:01 PM by Ryan CrawCour | with 2 comment(s)
Filed under:

Comments

Thiago Almeida said:

Really getting into the trenches huh? I wonder if it has anything to do with extending a binding element and the supported protection levels. Looking forward to part 2!

# December 7, 2008 9:09 PM

A world apart from the everday ... said:

In my previous post ( Part 1 ) I introduced the problem and the fact that there didn’t appear to be a

# December 8, 2008 8:09 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: