Silverlight 5 Tidbits–Trusted applications

Edit 2011-12-11: This article is compatible with the final version of Silverlight 5 (5.0.61118.0).

This post is part of a mini series about Silverlight 5:

• Implicit Data Templates
• Multi-Column Layouts
• Markup Extensions
• Multiple Windows
• Trusted applications
• Incremental Search
• Data Binding

One of the interesting features for enterprise use of Silverlight 5 is the possibility to have trusted applications running in browser. This further simplifies distribution and maintenance of Silverlight applications without giving up the option to use "trusted-only" features. In this article we'll also see what has changed for trusted applications in general compared to Silverlight 4.

The situation so far

Trusted applications are already available in Silverlight, and they add the possibility to do things that weren't possible due to security restrictions before. Features like COM Automation also enable a whole new field of scenarios, for example to interact with legacy or native applications and local hardware.

However trusted applications require that Silverlight runs out of browser, and even if the user confirmed the trust request, there were several restrictions in place, for example regarding file system access. Oddly enough, some of these restrictions only were applied to the managed API but could be worked around using COM Automation.

What's new in Silverlight 5

For the next release of Silverlight, Microsoft has straightened some of the remaining restrictions for trusted applications, and it's also possible to run trusted applications in the browser now. We'll see how this works in a second.

In-browser trusted apps

One thing to understand first is that this feature obviously is not meant for random internet applications. It requires signed XAPs, locally installed certificates and a certain registry key to be set, which e.g. can be managed through Group Policy. This makes it pretty difficult to use for applications outside a closed environment like an enterprise.

The first thing to do to use this feature is to enable in-browser elevated trust support in the project settings, an option that is new for Silverlight 5 applications.

Now add some code that tries to do something that requires elevated trust, for example writing to the file system without user consent:

private void WriteFileButton_Click(object sender, RoutedEventArgs e)
{
    // check if we can actually do this
    if (!Application.Current.HasElevatedPermissions)
    {
        MessageBox.Show("Application requires elevated trust for this!");
        return;
    }

    // create a directory if necessary
    var tempDirectory = @"c:\temp";
    if (!Directory.Exists(tempDirectory))
    {
        Directory.CreateDirectory(tempDirectory);
    }

    // build the full filename
    var filename = string.Format("tempFile-{0}.txt", _rnd.Next(0, 65536));
    var fullPath = Path.Combine(tempDirectory, filename);

    // write a new file
    using (FileStream fs = File.Create(fullPath))
    using (StreamWriter sr = new StreamWriter(fs, Encoding.UTF8))
    {
        sr.WriteLine("Hallo from a trusted app!");
    }

    // Notify the user
    MessageBox.Show("File has been created.");
}

Interestingly, if you run your application and click the button, a file is actually written to the c:\temp folder! But we didn't even set any registry key, let alone sign the XAP? The reason it works is that none of this is required when the application is started from a "localhost" url :-). This simplifies testing in your development environment without the need to change your system settings. If you try to access the same page e.g. through the machine name, "HasElevatedPermissions" will return false, or you will receive a security exception (operation not permitted) if you don't do this check.

Note: to enable access to your application other than through "localhost", you may need to host it in IIS or add a binding for that to the configuration of IIS Express.

Ok, now we know the background, but how do we actually set up the application to work from other locations than "localhost"?

Adding the required registry setting

Information about the registry setting in question can be found here. In particular, you need to add the following information:

• Value name: AllowElevatedTrustAppsInBrowser
• Value type: DWORD
• Possible values: 0x00000000 (disabled) or 0x00000001 (enabled)

The path to that value depends on the operating system and is different for 32-bit and 64-bit:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Silverlight\ (for 32-bit) or
• HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Silverlight (for 64-bit)

Signing your XAP file

The next requirement is that you sign your XAP file. You can do that directly from Visual Studio and select an existing certificate from a file or store as well as issuing a test certificate (which I did in the screenshot below):

Deploying the certificate

Once again, for testing you can do this directly from Visual Studio. Normally this is something that would be set up by an enterprise/company administrator for the users.

Click on "More Details..." on the "Signing" tab of your project settings (see screenshot above). There you can install the certificate locally:

In the next step, select the store manually and choose "Trusted Publishers":

Repeat the same process and this time choose "Trusted Root Certification Authorities" if necessary, for example when you're working with a self-signed test certificate.

Once both deployment steps are finished, recompile your application and run it, using the machine name to access the page. This time you will successfully be able to create the files:

Troubleshooting

One thing to keep in mind is that even if your application runs as trusted in-browser app, it is still subject to the security restrictions the browser itself imposes. That means that its possibilities may be much more restricted than if they ran out of browser, for example by Internet Explorer's Protected Mode. In addition, the Silverlight runtime itself restricts use of certain features for in-browser trusted apps, for example you cannot use the Window class and/or create additional windows when you're running in the browser.

If none of the above applies to you and you still run into problems, one thing to do is check whether your certificate(s) have been installed correctly. There's a snap-in for the management console for this. Here is an article that describes how to get there (note that you should add a snap-in for your user account, not the computer account as in this description).

You can also check whether your registry key is actually and successfully queried, for example by using a tool like Process Monitor from the Sysinternals Suite. Watch for operations of type "ReqQueryValue" of your browser executable that access the key we created above, and make sure the Result is "SUCCESS".

Further information about trusted apps in Silverlight 5 can be found here, particular information about enabling in-browser trusted apps here.

Further improvements

The above sample already shows one improvement of trusted applications in Silverlight 5: we were able to write to an arbitrary folder on the hard disk, which would have failed in Silverlight 4 even for trusted applications. In detail, the improvements are:

• "Full" access to the file system. The documentation says "unlimited access to the local file system", however this is only half the truth. You can still not write to certain system folders (like the Windows folder), and in-browser trusted apps are in addition restricted by browser security settings (see above).
• Some full-screen mode improvements are added. Particularly interesting is that in-browser trusted apps can use the full screen mode without limitations (all keys etc.).
• User consent and initiation. Trusted apps can now freely trigger certain actions which previously required user consent or had to be user-initiated. An exception to that is the use of the microphone and camera, for example.
• Relaxed cross-domain access restrictions: Networking and socket communication has been changed so trusted apps are not subject to cross-domain and/or cross-schema restrictions anymore. Some people will be very pleased to learn that in addition, the destination ports of TCP connections are not restricted to a certain range any longer.
• Trusted in-browser apps can now use the web browser control to show HTML content, and in addition also notification windows.

Limitations

The obvious limitation is that in-browser trusted apps require quite some work to be set up (signed XAP, locally installed certificate, registry settings). But taken into consideration that this is meant to be an enterprise feature this doesn't come as a surprise; also, with the additional easing of restrictions for trusted apps and the fact that trusted in-browser apps are updated silently just like normal ones, it's important that it's not too easy for malicious apps to achieve this trust level (think simple confirmation dialog).

One major issue with in-browser trusted apps at the moment is that the use of the web browser control is restricted to Internet Explorer only. When you try to run the application in a different browser, you'll receive the following message:

WebBrowser is enabled only for Out-of-Browser applications and applications running with elevated permissions in Internet Explorer.

I suspect that this will cause disappointment for some people; However, after speaking with Nick Kramer at MIX about this, I understand the problems here, and I hope that people will be fair and understand this is not solely an issue with Microsoft but a general problem with the different browser architectures and prerequisites.

Most of the other annoying or hard to justify restrictions for elevated trust applications of Silverlight 4 will be removed in version 5, and with features like P/Invoke even more possibilities will be added. At the moment I cannot see any huge obstacles that are still in effect to create sophisticated business applications in Silverlight 5, from a trust level point of view.