Silver light 5 elevated trust

Sunday, 3 August 2014

Silver light 5 elevated trust


 Microsoft has straightened some of the remaining restrictions for trusted applications in silverlight 5, 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.
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: 0×00000000 (disabled) or 0×00000001 (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 below):
right click on the silverlight project , click on property tab one window will open ,select signing tab on the opening windows .Now check sign the xap file and click on the button create test certificate
After doing all the task click on more details tab , one new window 'certificate' will open now click on the install certificate button then 'Certificate Import Wizard' window will open click on next button
now click on the radio button 'Place all the certificate following store' and select on browse button 'Select certificate store'.Now  select 'Trusted Publishers' click next.Now click finish.

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.