What’s New in Silverlight 5? – Elevated-Trust Changes

Introduction

In this article, we’ll have a brief discussion of the new features in elevated-trust applications in Silverlight 5.

Overview

Elevated-trust applications have undergone few changes in Silverlight 5:

In-Browser Support

Multiple Windows Support

File System Access

Platform Invocation

Let’s see those changes in details.

In-Browser Support

Unlike previous versions, in Silverlight 5 you don’t have to run your application as OOB to get elevated-trust features, you can now run elevated-trust applications in the browser and get all the features you need.

There’re two security considerations to be taken in order to run your elevated-trust application in browser:

You must enable running your application in browser via either the Client Access Policy file or the Windows Registry. Using the policy file allows your application to run in a private network. Using the Windows Registry approach allows your application to run on a single machine. In either approaches, you cannot deploy in-browser elevated-trust applications to everyone on the web.

In addition, your XAP must be signed with a trusted certificate e.g. X.509 certificate) available in the Trusted Publisher Certificate store.

Without any of those requirements, you won’t be able to run your elevated-trust application in browser. But wait, there’s a catch!

In your development machine you can run elevated-trust applications in browser only on whitelisted domains. For example, by default, localhost is whitelisted, so you can easily run an elevated-trust application in the browser in localhost. If you change to another domain, ensure that you add this name to the whitelist, or you won’t be able to run the application. More comes about this later.

The last thing to keep in mind is that in the Beta version, in-browser elevated-trust applications are supported in Windows only. Other platforms are going to be available in the final version.

Client Access Policy Approach

If you want your application to be available in a private network, you need to do some changes to the client access policy file in order to allow it to run in browser as elevated-trust. The changes are as the following; just set the ElevatedPermissions property of SecuritySettings to Required:

Windows Registry Approach

The other approach you have is to use the Windows Registry to enable in-browser elevated-trust applications to run on a particular machine. To do this, go to HKEY_LOCAL_MACHINESOFTWAREMicrosoftSilverlight. In this registry key, you have several values related to elevated-trust applications:

AllowInstallOfElevatedTrustApps:Set to TRUE to enable installation of elevated-trust applications to the PC (i.e. OOB.)

AllowLaunchOfElevatedTrustApps:
Set to TRUE to enable launching elevated-trust applications (in-browser or OOB.)

Example

To run an elevated-trust application in browser you need first to enable OOB and elevated-trust features from project properties. After that, create a Web application and link it to the Silverlight application to host it. If you didn’t do this, your Silverlight application will run as OOB. Your application is able now to run as elevated-trust in browser. To ensure this, you can check for the Application.HasElevatedPermissions property:

As you see, the application works as expected, and has all the elevated-trust features as OOB applications.

Now let’s try changing the domain from localhost to another domain. Go to Web application project properties, switch to the Web tab, then go to Server settings and change the server from Visual Studio Development Server to Local IIS Web Server and use your machine name as the domain and save the settings. (You might be asked to confirm virtual directory creation, it’s because you have changed to another domain and used another virtual directory.)

Now try to run the application. The application won’t be able to run and you’ll get a security exception, that’s because the new domain is not whitelisted like localhost.

Multiple Windows Support

Multiple Windows Support or Ad-hoc Windows is a feature that enables elevated-trust OOB applications in Silverlight 5 to have windows other than the main window. The feature is available through the Window class which is now instantiable. You use the Window class to create another window and set its contents through the Content property and show it using the Visibility property.

The following code creates a Window that’s 400 pixels wide and 300 pixels long, and has just a button in the interface:

Notice that if you don’t have elevated-trust features, you won’t be able to spawn other windows. And if you tried to, you’ll get a security exception.

File System Access

Unlike elevated-trust applications in Silverlight 4 which have access to only My Documents folder, Silverlight 5 elevated-trust applications (in-browser and out-of-browser) have full access to the file system. But keep in mind that although you have full access to the file system, you still restricted by the rights of the user running your application. If the user doesn’t have access to a specific file or folder, then you don’t have access to that file or folder.

To test this feature, try reading contents from a file in the system folder (for instance):

By default, if you’re running Windows Vista or Windows 7, your user wouldn’t have administrator privileges as long as he doesn’t launch Visual Studio (or your application) in elevated mode. So if you don’t have admin privileges and tries to gain the write access to the same file your application would fail, that’s because your application is restricted by user rights and the user don’t have write access to that file:

File.AppendAllText
(@"C:WindowsSystem32Driversetchosts",
"nfoo");

Same results when trying to write to the system drive without elevated permissions for the user:

File.WriteAllText(@"C:test.txt", "Foo");

Platform Invocation

Silverlight 4 has introduced support for automation and COM components. Silverlight 5 has added support for Platform Invocation (or P/Invoke.) Platform Invocation allows you to call native code (e.g. DLLs and Windows API) from your Silverlight application. This is a great improvement of course. It uses the same mechanism as other WinForms applications. Unfortunately, this feature is currently not available in the Beta.

Summary

The following changes have been happened to elevated-trust applications in Silverlight 5:

In-Browser Support:
You can now run elevated-trust applications in Silverlight 5 in browser. Must be enabled via client access policy file or Windows Registry, and XAP must be signed with a trusted certificate.

Multiple Windows Support:
Allows elevated-trust OOB applications to span windows other than the main window.

File System Access:
Allows you to have full access to the file system with the rights of the current user.

Platform Invocation:
Allows you to call native code like DLLs and Windows API from your Silverlight application. Not available in Beta.

Share this:

Like this:

LikeLoading...

Related

Pete Brown
6:59 AM on October 26, 2011

The ClientAccessPolicy bit here is incorrect (even for the beta). However, I’ve seen it all over the web. First: CAP can’t be used to control in-browser elevated trust. Second: the settings shown are actually part of the out-of-browser settings file. Hope that helps someone who uses this article.