Last year, I was on a project where I designed a solution with an XBAP and an IIS hosted WCF data service. The problem came out because the WCF service was secured with Windows integrated authentication and the XBAP, being a partial trust application, did not have the appropriate privileges needed to call the necessary CLR methods needed to package and issue a call to the secured WCF service.
The first hint of the problem came out when I got a security exception from calling the WCF service from inside the XBAP. The security exception was because the WCF service proxy was trying to set the HttpWebRequest.UnsafeAuthenticatedConnectionSharing property. However, unrestricted web permission is required to set that property and the XBAP, which was running with the Intranet zone privleleges, did not have that permission. Here is the stack trace of the exception:
I opened a ticket with Microsoft concerning this problem and after a few days, received hotfix 959546 which was supposed to address this problem:
This hotfix did address the problem and allowed the code to proceed past the point of setting the HttpWebRequest.UnsafeAuthenticatedConnectionSharing property but a new exception was thrown higher in the callstack:
It took quite a bit of time after I first opened the ticket, worked throught he hotfix, and before Microsoft was able to clearly address this issue and by this time in my ticket lifecycle, I was working with an escalation engineer. After reporting the above problem to him, I received the below email email in which he indicating that this bug was to be fixed in .Net 4.0:
So at this point, I’m left with a problem: I can’t use the WCF service proxy to call a secured WCF service so what should I do? Should I re-implement the WCF data service as a 2.0 web service? ~~SHIVER!!~~. Grasping at straws, I decided to try using a 2.0 web service proxy to call my secured WCF data service and see what would happen. What happened was that it worked! So I released this project as an XBAP, a secure WCF data service, and a 2.0 web service proxy inside the XBAP to call the secure data service.
And that brings us to today. As you can see from the dates in the email chain above, this all happened last summer and today the .Net framework release 4.0 is in RC mode so I decided to see if this problem was fixed in 4.0. To try out this fix, I setup two quick hyper-v VMs:
- Win7 + Visual Studio 2010 RC
- 2008 R2 + IIS 7.5
To model the environment of last year’s project, I wrote a quick WCF service and an XBAP to call the service. I ran the XBAP and sure enough, everything worked just fine in 4.0, the XBAP was able to call the WCF service which was being hosted on IIS 7.5 using Windows Integrated Authentication. Just for kicks, I regressed the build’s target framework back to .Net 3.5 and ran it again just to see what would happen. What happened was I got the same exception I did last summer, so that proved to me there were no shenanigans going and that nogthing had crept in to my problem domain (you never know after a year long wait) as the outcome of my proofs were what I expected.
After going through this test with 4.0, I became curious about how exactly Microsoft fixed this problem. To satisfy this curiosity, I’ve decided to write a second part of this post and take a look at the version 3.5 CLR code using Reflector to see what exactly the code looks like that was causing this problem. And then I’ll take look at the 4.0 CLR code to see how the problem was fixed.