Serving WCF HTTPS content through HTTP hosted Silverlight.

Silverlight doesn’t like making cross domain or cross scheme calls by default and in some cases it doesn’t support HTTPS calls for certain items. I was tasked with building an application that loaded some information from one of our databases and served it in a client application that included a MediaElement with streaming video. After much investigation I concluded that while I could not load the Silverlight app with the video in an HTTPS mode (MediaElement will not let you serve streaming media via HTTPS) I could call the WCF service that provides the data to the application using HTTPS. To do that I would need to jump through several hoops and it’s debatable how secure it makes the application in reality, but I won’t go into that. This is purely a post about how to configure your HTTP served Silverlight application to make HTTPS calls to its WCF service. I do not guarantee that this makes your Silverlight app more secure.

The first part of serving your WCF content to Silverlight via HTTPS is having a server with a valid certificate that you can call your WCF service from. Any problems with the certificate will cause many issues that I will not even try to address here. Just make sure your certificate is valid for your domain that serves the HTTPS content (in this case your WCF service).

The second part would be configuring the system.servicemodel entry in the web.config of the application that hosts your WCF service.

Most of this is what you would configure normally for a WCF service. The service I’m using is actually provided by the CSLA Framework, but that isn’t particularly pertinent and I also have some debugging configuration included in this setup. The main thing that is important is the binding configuration and the security node.

Adding this and then specifying the bindingConfiguration element in the endpoint node to refer to this is very important.

Next we’ll move to the ServiceReferences.ClientConfig file within your Silverlight application. This file is where you specify the client’s WCF connection information.

Again this is fairly standard stuff. Again I’m using the CSLA framework in this case to provide my WCF service, you would need to configure your particular service references. The main things to concentrate on here is that the URL being used to contact the service is HTTPS and the below element is part of the binding configuration.

Having this element is key to the whole thing working as it was in the WCF host configuration.

In my case I’m hosting the XAP file under the same domain as my WCF service, YMMV as to how well you can get this to work without doing that.

The last portion of this is that wherever you are hosting your WCF service you will need to configure a clientaccesspolicy.xml file and place it in the root of your domain.

So, in this case my WCF service is hosted at and so I would place the file at the root of the domain so that if I hit the url at I would see the XML file.

This XML file looks like this.

The documentation on this file is generally pretty sound, but this particular scenario is covered only vaguely in that what I’m doing is going cross scheme in this case rather than cross domain (though theoretically with the correct configuration of this file cross domain access and cross scheme access is possible as well, but you should check for limitations based on your content). Silverlight doesn’t like cross scheme calls in much the same way that it doesn’t like cross domain calls. The grant-to node is specifying what path can be specifically accessed using the policy within the domain. In this case I’m specifying the location of my WCF service. You could put * there and it would let everything under the domain be accessed cross domain and schema, but obviously that isn’t advisable. You can also whittle down the domains that you are allowing access from by altering the domain nodes under the allow-from node. In this case I’m allowing anything.

This file works for my scenario where I’m making cross scheme calls within the same domain. Cross domain calls might require a different configuration depending on your scenario

Once these steps have been taken you should be able to access your Silverlight application via HTTP and have it make HTTPS calls to the backend service.

Leave a Reply

Your email address will not be published. Required fields are marked *