In Silverlight, if you’re talking to WCF services, you have the built-in option to add credentials to the message header and check those on the server side. This way, you can easily make sure your service methods are only accessible to those people/identities you want to allow. More detail on how to achieve that can be found on MSDN: how to use message credentials to secure a service for Silverlight applications.
There’s one little caveat though: to be able to use this, you MUST use transport security (SSL), which is defined by the HttpsTransport element in your config files: Silverlight will not allow you to send the username/password in the message header using these bindings unless you’re using SSL. This is actually a good thing: having this as a requirement makes sure developers don’t “forget” to use SSL – forgetting that would result in serious security implications, as all the information would be sent over the wire in clear text (or binary encoded, but that’s still quite easy to hack).
Now, you’d typically want to set up SSL in some kind of test environment by using a self signed certificate (you’d buy one when going to an acceptance/production environment), and that’s where the problems might begin: Silverlight doesn’t exactly play nice with self signed certificates. Looking around for that on the net will result in numerous posts, where some people say it’s impossible, some get it to work, but apparently, there’s no clear way to get this to work all the time, everywhere.
Well, I recently found myself requiring secure services over SSL in a Silverlight project, and I needed to use a self signed certificate for this (to learn how to create one, have a look at this post by Scott Guthrie). Sure enough, I set up everything right (using the new Silverlight 4 beta, and I even made sure I added the certificate to the trusted root), and … it didn’t work. Dreadful “NotFound” errors everywhere.
So I started looking at my bindings in the config files, double checked the service implementation, regenerated the proxies, … nothing worked. But after a while, I noticed something: as I was using SSL on a local IIS install, Visual Studio put “localhost” as the root address – which is the default. I changed this to my web servers’ name instead of localhost, and sure enough: it worked!
So, if you’re running into problems with Silverlight and self signed certificates, you might want to try this:
Hope this helps some of you out! 🙂