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.
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.
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.