• Feeds

    Subscribe in a reader

  • Ads

Partial Trust support for WCF in Orcas

In order to get WCF out the door on time, we had to make a few really painful cuts. Such things are a necessary part of shipping software, but they're never fun. Setting [AllowPartiallyTrustedCallers] on System.ServiceModel.dll to enable the use WCF in Partial Trust was definitely one of those.

Relatively speaking, we made this cut pretty early on in V1 (before WCF Beta 1). Setting APTCA is not something you do lightly, and it was pretty clear that if we ever wanted to test this thing before it went out the door,  we'd have to put Partial Trust on the chopping block. So we screwed up our courage, cut the feature, and shipped V1 on time.

Now, when we did that we knew that we were making life difficult for a couple of key scenarios that we really wanted to have a good story for long-term:

  1. Shared hosting. Multi-tenancy (running multiple unrelated apps in different AppDomains within the same process) is standard operating procedure for shared hosting environments (think GoDaddy.com). ASP.NET's  Medium Trust level was designed specifically for this scenario, and an increasing number of mass hosting providers are adopting Medium Trust as a way of keeping individual AppDomains within a process from stepping on each others toes.
  2. Smart Clients. It's possible to use ClickOnce technology to deploy fully trusted smart clients that can make full usage of WCF, the process requires signing your assemblies and adding the signing certificate to the Trusted Publishers store. Admittedly, it's something of a pain in the ass -- which is why in V1, many customers end up using the ASMX client stack in their ClickOnce or XBAP clients to talk to services implemented with WCF.

These two broad classes of scenarios were front an center when we were looking at the subset of WCF feature to enable in Partial Trust in Orcas.

What permission sets are we requiring?

The permission sets needed to run WCF flow directly from the scenarios I mentioned above. On the server, the price of entry is ASP.NET Medium Trust permission set. On the client, you need InternetZone permissions + WebPermission to connect back to the application's origin server (this is granted by default by both ClickOnce and XBAP).

What V1 Features work in Partial Trust?

The major V1 features supported in partial trust are the following:

  • BasicHttpBinding + HTTP transport security
  • TextEncoding
  • Serialization with XmlSerializer
  • Serialization with DataContractSerializer
  • And all the min-bar stuff you'd expect from the Service Model, like the [ServiceContract]/[OperationContract] programming model, configuration, WSDL generation, etc.

Broadly speaking, we enabled the ASMX-equivalent WCF feature set + the data contract serializer. 

What Orcas features work in Partial Trust?

System.ServiceModel.Web is APTCA-enabled, so everything we're doing in here works in partial trust including:

  • The WebHttpBinding
  • The core HTTP/POX programming model
  • RSS + Atom
  • JSON and ASP.NET AJAX integration

Hey Steve, why isn't (Feature X) supported?!?

As much as I would wish otherwise, the Orcas release does not come with infinite resources so we had to prioritize based on the features that were most important to the scenarios we're targeting in this release. This is an area where it would be great to get some feedback from the community about whether we've made the right calls here.

Next time around, I'll talk about the HTTP Programming Model work.

#1 Oran on 3.03.2007 at 11:51 PM

Will we be able to build a lightweight partial trust queueing solution with Orcas WCF and isolated storage?The cherry on top would be a Microsoft-provided partial trust queueing solution that speaks a standardized queuing protocol.I realize isolated storage isn't a WCF feature, but do you happen to know if it will support Vista's transacted file system from partial trust in Orcas?This seems to be a prerequisite for partial trust durable reliable messaging.

#2 dominick on 3.04.2007 at 1:41 AM

Hey Steve, good start!cheersdominick

#3 Steve Maine on 3.04.2007 at 11:40 AM

Oran -- those are some very interesting questions.To be honest, I think it would be hard to build what you're asking for inside of a partially trusted assembly. It might be more feasible to build a fully-trusted APTCA assembly to house your channel, which you could then expose to partial trust callers. It would require that your channel (not necessarily its callers) be signed and GAC'd. Would that work?The transactions team did do the work to integrate with the transactional file system (see http://pluralsight.com/blogs/jimjohn/archive/2006/08/31/36819.aspx), but I think you have to P/Invoke down to CreateFileEx() to do so. That requires unmanaged code permission, which you'd have to assert from fully trusted code.Dominick -- thanks.-steve

#4 Oran on 3.05.2007 at 12:12 AM

Putting an APTCA queueing channel assembly in the GAC would only do the trick if it was installed by the .NET Framework.It seems like queued messaging is such a core smart client feature that there would be a partial trust implementation of it from Microsoft.There are several attempts at this from the patterns & practices team, but when you dig into the details, they're not queueing messages, they're queueing method parameters and pointers to request/response client proxies.There are a number of issues with this technique, but my biggest concern is safely flowing different user identities on a per-message basis.Reliable queueing in partial trust could be done without TxNTFS if there were a way to _really_ flush an isolated storage stream without a P/Invoke, but unfortunately there's not.One way or another, a P/Invoke is required.To me, this says that Microsoft needs to step in with an APTCA implementation.Until the .NET Framework ships with support for partial trust queued messaging, occasionally connected smart clients on the Microsoft platform are either flakey toys or they aren't delivering on the no-touch deployment promise.Despite my ranting, the Orcas features are awesome, especially the first class POX/REST support and ASP.NET AJAX integration.I'm just a bit frustrated at all the missing features from different teams that need to come together to truly enable the occasionally connected smart client scenario.

#5 Steve Maine on 3.06.2007 at 12:54 AM

Jay -- really quickly:1) We're looking at CardSpace. It's going to be tough because it brings in all of WS-Security in order to do it right. However we're looking at supporting the passive profile used in the browser. 2) MBRO will be the story for x-appdomain comms for the time being. I'll post more on this.