XBAP & Trust Levels

XAML Browser Applications (XBAPs) in this version are promptless in-browser experiences. 

This has many implications:

1. clean experience when navigating to an XBAP.  (There is no Information Bar or security warning before launching the app.) 
2. cached (not installed) on the user’s machine.
3. security sandbox.

Sandboxed Applications

The third bullet above is especially important for XBAP developers.   XBAPs obey the security contract of being in the browser: they are sandboxed according to their deployment zone.  Today, there is no way to seamlessly “elevate” and prompt the user for additional permissions.  (This is an often-requested feature and something we are investigating for future versions.)  The sandboxed restriction also means that XBAP developers need to be conscious of the bounds of the security sandbox as they develop their app.  (See previous post.)

Note: By default, all XBAPs request the Internet Zone permission set in their application manifest.  In V1, there is no significant difference between the Internet & Intranet permission sets.

“I want my XBAP to run with full trust.  I heard there are workarounds..?”

Given the sandbox restrictions and the wide range of experiences desired in the browser, this is not surprisingly a frequently asked question about XBAPs. 

If you want full trust, you should first consider building a standalone installed WPF application.  These by default run in full trust and can be deployed using ClickOnce, giving many of the deployment benefits of a browser application.

If your scenario requires that you’re an XBAP, there is no built-in way for XBAPs to prompt and request more permissions. That being said, XBAPs are ClickOnce applications behind the scenes.  That means it is possible to use ClickOnce-based methods to gain access to trusted actions.  There are two main options:

1. Install an AllowPartiallyTrustedCallersAttribute’d (APTCA)assembly in to the client’s Global Assembly Cache (GAC).  Use this full trust assembly to proxy calls for the XBAP.
2. Install a certificate in to the user’s trusted publisher’s store.  Use ClickOnce trusted application deployment by signing the XBAP with the certificate.

Neither of these workarounds are ideal from a security standpoint, but we believe the latter is the better option.

GAC’d APTCA assemblies are accessible to ALL partial trust callers and therefore are susceptible to repurposing by 3^rd parties.  There are ways to mitigate this exposure – for instance, one could use the [InternalsVisibleTo] attribute to only expose methods to specific “friend” XBAP assemblies.  However, mistakes or incomplete usage of this mitigation could potentially open wide security holes.  In addition, the management of installed APTCA assemblies is very end-user unfriendly.

For intranet XBAPs, pushing out a trusted publisher certificate through group policy is a fine way of enabling LOB scenarios. 

However, for consumer scenarios, trusted deployment via trusted publisher certs has its drawbacks.  This is because it affects more than just XBAP deployment:  many trust decisions prompts are bypassed for trusted publishers.  Still, this workaround has the advantage of being scoped to the specific publisher.

For V1 consumer XBAPs, we make the following recommendations:

1. Be sure your app needs to be an XBAP.  (Can it be a full trust standalone ClickOnce application?)
2. Trusted app deployment is preferred of the two workarounds.
3. Use a separate cert to sign each XBAP group.  Otherwise, a user who decides to trust one set of XBAP will implicitly agree to trust all XBAPs (& ActiveX controls, etc) signed with that certificate.  This scopes the security impact (and responsibility) of any particular certificate.
4. Use an MSI to install the cert.  This ensures installation is consistent with the configured security installation settings on the client machine (e.g. requiring Admin rights).
5. Install the cert into the user’s trusted publisher store, not the machine’s.  This reduces the machine decisions that the trusted publisher cert can impact.
6. Clearly notify the user at installation that they are changing the user’s trusted publisher store. 
7. Provide clear installation instructions on the page containing the XBAP.  If the cert is not installed and the XBAP requests full trust, a “Trust Not Granted” error is shown.

Please use the above method with extreme care. We’re exploring changing XBAP elevation to work better in future versions.  Your feedback in this area, as always, is appreciated.

Other FAQs

How did you implement the sandbox?

The XBAP sandbox is based on the .NET Framework security model: Code Access Security.  In this model, permissions gate the actions that a particular app can do (i.e.  FileIOPermission controls file system access).  What permissions are granted depends on what deployment zone an application is deployed from.  A detailed explanation on our implementation strategy can be found in the WPF Sandbox Whitepaper.

When will you be expanding the sandbox?

We’ve had a lot of requests for specific features to be brought in to the Internet sandbox.  Currently, we’re exploring plans for our next version.  We would love feedback if there is a non-sandboxed feature that is blocking you.  Please leave comments on this blog post or send requests to wpfsec at microsoft dot com.