Restricting Access to Your Application
In some scenarios, you may want only certain users to be able access your application. Silverlight XAP files are easy to decompile, which may be a cause for concern if your application contains sensitive algorithms or assets. By letting anybody download your application, you are also allowing them to gain access to its contents.
As described in Chapter 1, a XAP file is simply a ZIP file with a different extension. Changing the extension to ZIP or simply opening the XAP file directly in a compression utility enables you to get access to all the assemblies and assets in your application. Then, using .NET Reflector from Red Gate Software, or a free alternative such as JustDecompile from Telerik or dotPeek from JetBrains, you can decompile the assemblies back into readable code.
Alternatively, Silverlight Spy, a commercial tool from First Floor Software, allows you to navigate to a URL hosting a Silverlight application, which it will display the contents of and run. It then allows you to browse to an assembly within the XAP file, decompile it by using .NET Reflector, and view its code.
Therefore, always assume everything within your application is accessible publicly. This includes the address and structure of your services, any encryption keys, any assemblies and algorithms contained therein, and any assets such as graphics and other resources. Anything that is sensitive (generally in the form of intellectual property) should not be used in a Silverlight project. While this is the simplest solution to this problem, it is not always viable. Therefore, you need to look for other alternatives.
Ideally, for best protection, sensitive algorithms should be placed on the server and called via service calls when required. Of course, depending on the nature of the application—for example, if it's being run in disconnected mode or is used to perform complex simulations—this solution is not always viable either. Therefore, you might consider using an obfuscator. Obfuscators modify your compiled binary, changing the names of variables, methods, classes, and so on, so they cannot be easily read and are no longer descriptive of their purpose. Generally, obfuscation doesn't stop your application from being decompiled, but it does make the results very difficult to read and follow. The strategy of obfuscators is “security through obscurity.” They aren't perfect solutions for preventing reverse-engineering of your application, but they do provide a significant impediment to those attempting to do so. A number of free and commercial obfuscation tools are available that will obfuscate Silverlight XAP files, and a quick web search will turn up several of them. For example, Eazfuscator.NET (http://www.eazfuscator.net) is a free obfuscation tool, and CodeFort (http://codefort.org) has both free and commercial editions. When choosing an obfuscation tool, be sure to check that they support obfuscating Silverlight XAP files first, however, as not all obfuscation tools do.
Note To make obfuscation effective, you need to mark as many classes, methods, and properties as internal or private as possible within your project. The external (public) interface needs to remain the same so that the obfuscator can't change it. But the internal or private definitions can be safely changed; the obfuscator can modify all their references accordingly, knowing that nothing externally will be affected.
To protect assets used by your application, you may wish to consider downloading them on demand from the server rather than including them within your XAP file (a topic covered in Chapter 17). This means that you can restrict access to them by specifying the rules in a web.config file that you place into a folder where restricted assets are located. These rules can be used to restrict the assets in that folder from being downloaded unless the user is authenticated or assigned to a particular role, and you can even control access at the user-name level if you wish. This strategy integrates with the ASP.NET Membership security, meaning that all you need to do is to configure the access rules in the web.config file, with the authentication and authorization handled by the ASP.NET Membership providers. You can create the web.config files yourself—each folder requiring file restrictions needs to have a web.config file in it, containing the rules that apply to it—and manually configure the security settings, but the easiest way to configure the access rules is to use the ASP.NET Configuration tool for the Web project. Click the Security tab, and then click the “Create access rules” hyperlink in the Access Rules group on this page. You can use the user interface shown in Figure 8-5 to create the access rules, without needing to learn the syntax.
Figure 8-5. Configuring access rules in the ASP.NET Configuration tool
For example, limiting access to a folder in the Web project to authenticated users only will create a web.config file in that folder with the following contents:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
You can download the assets from your Silverlight application once the user is logged in, using the techniques demonstrated in Chapter 5.
You may also wish to use this technique to restrict access to your Silverlight application itself. You can restrict access in the same manner to the ClientBin folder in your web project, so the users can't download the application unless they are already logged in. This can reduce the importance of protecting your application in the other ways described, but it does raise the issue of how the user will log into the application in the first place. There are a number of strategies that you might choose to implement:
- Because the authentication mechanism in RIA Services is exactly the same as the one used in ASP.NET projects, you could create an HTML–based login page that the user can use to log in to the system, which then loads the Silverlight application once the user has successfully been authenticated.
- Using some of the techniques described in Chapter 17, you could partition your application into a number of parts and load them on demand—protecting and loading the more sensitive parts only once the user is logged in.
- Implement a bootstrapper. Similar to the previous scenario, this will download and run a small Silverlight project—which you could use to provide a simple login screen and then continue to download the (protected) remainder of the application. The Silverlight Extensions project provides a bootstrapper that you can use to help you; it's available at
http://slextensions.codeplex.com.
Note Dynamically loading parts of your application on demand isn't possible with applications that are being run in OOB mode.
You may even want to use this method to restrict access to any standard WCF web services that you use in your application. You can restrict access to their SVC files until the user is logged in, providing another degree of security. Note, however, that adding or updating these service references will not work if you have these restrictions in place while developing the application—implement these restrictions on the production server only.