Deploying a Silverlight Application and WCF Service to IIS

While deploying a Silverlight application on IIS today, I learned several new things. Let me express my observations; This post is going to describe the security settings for WCF service in web.config. To start, I assume that you are using either Windows or Forms authentication and denying all the anonymous users as described in a previous post.

First, make sure to remove the mexHttpBinding endpoint as this requires you to enable anonymous access to the website in IIS. The mexHttpBinding endpoint will look something like:

<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>

 
BasicHttpBinding

Typically, in your application, you will also be using some custom basicHttpBinding configuration for your WCF service endpoint, like this one:

<endpoint address="" binding="basicHttpBinding"
 contract="SilverlightApplication.Web.WCFService"
 bindingConfiguration="myCustomBasicHttpBinding" />

Using a custom binding allows you to configure buffers and quotas as described in this post. The definition of this custom binding will look something like:

<bindings>
 <basicHttpBinding>
  <binding name="myCustomBasicHttpBinding">
  <security mode="TransportCredentialOnly">
   <transport clientCredentialType="None"/>
  </security>
  </binding>
 </basicHttpBinding>
</bindings>

The <transport clientCredentialType=”None”/> is the main point of interest here. If you are using Forms Authentication, you need to allow anonymous access through IIS and set the clientCredentialType to None. If you want to run your application under Windows Authentication, you should use clientCredentialType="xxxx" where xxxx is the corresponding IIS authentication type. So, to work with Integrated Windows/Basic/Digest/NTLM Authentication, the xxxx should be replaced by Windows/Basic/Digest/Ntlm respectively.

 

Update: Custom Binary Binding

Similar change is required for custom binary binding:

<customBinding>
 <binding name="myCustomBinaryBinding">
  <binaryMessageEncoding >
   <readerQuotas ... />
  </binaryMessageEncoding>
  <httpTransport authenticationScheme="Anonymous" ... />
 </binding>
</customBinding>

Again, the point of interest is the authenticationScheme attribute in the httpTransport element that needs to match the IIS authentication setting (e.g. Anonymous for Forms Authentication, Ntlm/Basic/Digest for Windows Authentication).

This way, the WCF service should work without any problems.

Securing Silverlight Application and WCF Service using ASP.NET Authentication Techniques

Security is an issue that experts are discussing since the birth of Silverlight. A typical enterprise Silverlight application will consist of one or more Silverlight pages communicating with one or more WCF services. There are three major security concerns here:

1. Silverlight 2 supports communication with a WCF service in simple text (the basicHttpBinding), so anyone can use a packet sniffer (e.g. Fiddler) to read our data.
2. Anyone can access our WCF service, call its methods and get our data.
3. Anyone can download our Silverlight application (the .xap file), open it (since it is simple a zip file), extract the DLLs and use Reflector to read all our code.

The first problem can be solved by securing the transmission via transport security (using https protocol). More on this can be found at MSDN here. In this post, I will try to address the last two issues.

The good thing is that the Silverlight application and WCF service is hosted inside an ASP.NET website and luckily ASP.NET provides good tools around authentication so we can apply ASP.NET authentication techniques to secure those. The approach I like is to secure the entire ASP.NET web application using either Windows or Forms authentication and deny all anonymous users. This can be done by configuring the web.config as:

  <authentication mode="Windows"/> <!-- or Forms -->
  <authorization>
    <deny users="?"/>
  </authorization>

This way, if anyone tries to access the WCF service, or download the Silverlight .xap file, or view a page inside the ASP.NET website, the ASP.NET engine authenticates the request and only authorized users are able to view the application or use the service.

So now, if our application is configured to use Windows authentication, the ASP.NET engine authenticates the request via integrated windows authentication. If it succeeds, users are automatically redirected to the Silverlight application; otherwise they get a HTTP 401.1 – Unauthorized message.

And, if our application is configured to use Forms authentication, the ASP.NET engine takes the user to an aspx login page. Once the user is validated (we can use either ASP.NET built-in authentication or any custom implementation to authenticate the user), he/she is redirected to the Silverlight application.

To observe this, you can download this application (Be sure to first rename the file to zip; this is a WordPress requirement) and toggle its authentication technique between Windows and Forms using web.config.

Note that the application also demonstrates how to get the logged in user in Silverlight using a WCF service call. The key is that we can use System.Web.HttpContext.Current.User to get the current user principal if the WCF service is running in ASP.NET compatibility mode.

At this point, we have made sure that our application and WCF service is only accessible to authorized users. But the problem still exists to a small extent, although narrowed down to authorized users instead of general public. To further secure our application, we need to use some .NET obfuscater. This will ensure that no one, including authorized users, will be able to decompile our code using .NET reflector. And, to further enhance our WCF service security, we need to implement declarative or imperative security checks for our service methods. As with typical ASP.NET applications, we may need a custom implementation of IPrincipal and IIdentity for securing the WCF service using declarive security attributes.

That’s all. Let me know what you do think in the comments section below.