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 3rd 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.

13 comments

  1. Can I purchase a cert from Verisign and use it to sign my app? Thereby skipping the step where I need to install a trusted cert in the user’s personal store?

  2. Brian,

    No – VeriSign is a trusted root certification authority. That means that a user trusts that a cert from VeriSign actually represents the person it says it does. (Bob gets a cert from VeriSign. User trusts that the cert is actually Bob’s cert, because it trusts Verisign who issued the cert.)

    A user still need to install the cert in to the trusted publishers store for the user in order to trust that publisher.

    Hope that made sense!
    Karen

  3. Hi,

    I have a full trust xbap that will run fine. It will throw an exception as soon as it hits code that will modify the registry. I would have thought that having full trust would fix that. ( this if for a corporate intranet application).

    Could you give a hint about where to look?

    Kind regards,
    Ruurd Boeke

  4. I would like my xbap to write back to the browser accessing the DOM model and Javascript. Reason: My app would now be able to chain events from the XBAP to the browser. Note, this is possible today using managed user controls and the appropriate interfaces so the feature release would not open any hole.

  5. Hi Karen,

    Thanks for the great post. I have a related question. I have already put a lot of time into coding a Windows Forms control which is hosted in a webpage via the tag. But I recently wanted to upgrade it with a WPF control so I tried to add an instance of ElementHost to my control. But the ElementHost’s constructor fails with a “Request failed.” exception. I have given my control FullTrust.

    Do you know if this is possible? Do I have to assert a security permission? Or must I rewrite the control from scratch as an XBAP?

    Thanks!

  6. Hi Karen
    Excellent post! Can you please elaborate in the first workaround?

    “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.”

    I am working with an xbap application in Visual Studio 2008. I installed an APTCA assembly in the client’s GAC like you indicated but when I try to run my code I get the following exception:

    System.Security.SecurityException: Request for the permission of type ‘System.Security.Permissions.FileIOPermission

    Thanks in advance

  7. Hi

    I cant get the full trust XBAP to work,I have tried everything,I created the certificate and installed it,but still no luck,I have been struggling with this for over a week now.

Leave a Reply

Your email address will not be published. Required fields are marked *