Silverlight and WCF Authentication Issues

Welcome to a new post of “My Adventures in SIlverlight” series. In this post I’ll try to outline a few caveats I found while trying to communicate a Silverlight ciient application and a WCF provider service.

The Basics

As we mentioned earlier, Silverlight only recognizes basicHttpBinding protocol. It means that it cannot use web service extensions for authentication, unlike standard ASP.NET applications. Furthermore, as Silverlight is a platform-agnostic technology, it cannot use Windows authentication neither. In an enterprise environment, this is a serious handicap.

The Alternatives

Alternative #1: Non-Authenticated Service + Username + Secret Value

You can use a non-authenticated service as a endpoint for a Silverlight client to connect to. Inside the method call, insert the username and a secret value only known to both the client application and the server. This secret value should act as a second check (the first is the username) for the service.

It’s not flawless, thought, but it should be considered.

Alternative #2: Implicit Authentication

If your Silverlight application runs in the same IIS site as the service it’s trying to consume, and this requires authentication, then you can forfeit the authentication code. Silverlight can consume a secured web service without authentication as long as the service and Silverlight client application are in the same IIS site.

Talking to a WCF Service From Silverlight

In this second installment of “My Adventures with Silverlight” series, I will talk of how to successfully invoke a WCF service from Silverlight client.

The Basics

In a nutshell: you have a Silverlight client application that wants to consume data available in a remote service. This service is hosted in a classic ASP.NET web service (.asmx) or, like in this example, in a Windows Communication Foundation (WCF) service (.svc).

Silverlight has a built-in support for invoking WCF services in System.ServiceModel namespace. You should add a reference to the WCF service from “Add Service Reference” option in your Silverlight project when it’s open in Visual Studio.


In this dialog box you specify the URL of the service you want to add.


If everything goes well, after clicking OK you should see the service referenced correctly:


After the service is referenced, you must instantiate a service proxy (a class which is created automatically when the service reference is added). Then, you invoke the service methods in the proxy. The proxy itself invokes those methods in the remote service, sending SOAP-encoded messages over the HTTP connection.

The Limitations

In order to successfully connect your Silverlight application to a WCF service, you should abide by some known restrictions.

The first limitation is that standard WCF services use wsHttpBinding binding configuration, which enables security and other enhancements. Silverlight 2 is currently limited to basicHttpBinding configuration, which doesn’t include them (but, in the other hand, is much more interoperable with non-WCF services). So, in order to successfully add a service reference, you should manually change the binding information in your service web.config file, as shown here:



Additionally, you must enable ASP.NET pipeline support in your WCF service. This is accomplished by adding a AspNetCompatibilityRequirements attribute to your WCF service class and adding a AspNetCompatibilityEnabled node in your WCF service web.config file.



If you use the standard Visual Studio WCF Service template, you will have to do these changes manually. If you use the Silverlight-enabled WCF Service template, these settings will be applied automatically.

Message Size Limit

If one of your service methods has a parameter that can grow in size, like a humble String, you need to know that the default service configuration in WCF has a limit somewhere around 7780 bytes of message size. A message bigger than that will throw a NotFound —> System.Net.WebException. This exception is a catch-all generic exception when something goes wrong in communication with the WCF service. You will need a Http Debugging Proxy (more on that in next posts) to really dig out the real culprit.

To fix this you can follow the suggestion in Silverlight Official Forum:

  • Change the binding entry in ServiceReferences.ClientConfig file of your Silverlight project to something like this:
    <binding name="BasicHttpBinding_YourService" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">

  • Add a new binding entry in system.ServiceModel node of the service web.config. Change the endpoint bindingConfiguration to use this new binding.

My Adventures in Silverlight

If you’ve been returning to my blog in the past month, you could see that I haven’t written anything since December the 3rd. I haven’t disappeared, don’t worry. I just had to endure the year’s end project closures, the holidays, the vacations (in snowy Berlin) and the back-to-the-reality adjustment. I’m back and kickin’ again!

Last week I started an internal company project in Silverlight 2.0 and Windows Communication Foundation. By doing it, I learned some oddities and particularities which I want to share with you.


The Background

The project I undertook is an entry form for our monthly time tracking system. We now fill an Excel form with formulae that automatically calculate if you are eligible for an daily allowance. It also sums up your monthly expenses and allowances to give you a clear number of your expenses for the month.

The employees are assigned to different projects, each one with its own project code. This code is often incorrectly typed or unknown by the employees. Moreover, the existing process is cumbersome for the administration people, as they have to cross-check that no wrong data has been submitted (such as working too many hours or in holidays) and to sum up the total costs for their input in the financial payroll system.


Our first try was to use InfoPath Forms Services for this task, but we found it lacking the agility to code dynamic data and easy-to-use interface of an Excel form. I suggested to give Silverlight a try and in just a week the system has been built from the scratch.

The Beginning

My initial idea was to build a Windows Communication Foundation service that provides the service layer for the Silverlight client interface hosted in a SharePoint web part. The Silverlight client would have a data grid for data entry and additional controls to show statistics, user details, comments and so on. The filled forms would be saved by the WCF service on the server or a database.

I downloaded Silverlight Tools for Visual Studio 2008 and I began to build the application. Since then and until the product beta rollout (few days ago) I’ve (painfully) learned what can and what cannot be done in Silverlight and what should you take into account when building a Silverlight LOB application.

I will share the lessons learned in the following posts (soon to arrive):

  1. Talking to a Windows Communication Foundation service from Silverlight
  2. Silverlight and WCF Authentication issues
  3. Silverlight controls and its limitations
  4. Hosting a Windows Communication Foundation service and Silverlight in IIS
  5. Hosting a Silverlight user control in SharePoint web part

See you in the next post!