Saturday, December 4, 2010

Silverlight 5: More details on WS-Trust support


Yesterday Microsoft had announced Silverlight 5 Beta to be released in the first half of 2011. Sure, there are plenty of great features there, but if you are readers of my blog I'm sure you are especially interested in a particular one. Here is a hint (click to enlarge):

Yes, more of the WS-* stuff is making its way into SL.

While this is all good news, the announcement is missing more details as for what exactly will be supported. This post will analyze the status of SL & WS-Trust in SL 4 + following unofficial projects, and based on the missing gaps I will try to estimate what the upcoming release *might* include.

Background - Federation and WS-Trust
This post is not aimed to be an introduction to federation or to claims based programming, but as a quick reminder here is the general flow:

Our environment contains:

Application Service. This service contains some operations that clients want to consume. The service will only accept client requests that embed a token gotten from the STS (usually a Saml token, which is an Xml token format). One reason might be that the service does not want to deal with authentication and leaves this mission to the STS which is developed by a dedicated team.

STS. STS role is to authenticate clients and generate tokens that the client can present to the service. This is a little oversimplified, mainly since there are some STS that only aim to provide client identity, and some that provide protection over the resource (service), and in many cases both of them will be used.

Client. The client is any application (client or server) that wants to consume the application service and needs to get a token from the STS first. The client is of course not necessarily using Silverlight.

Needless to say is that Wcf is a great framework for such scenarios.

How Silverlight fits this picture?

A lot of organizations already have security infrastructure that contains STS. They would like SL applications to work with it also, mainly so SL applications can call other web services which expects a Saml identity.

What is the current status of SL & WS-Trust (SL4+ unofficial projects)

Until the beginning of 2010 there was no built-in support for such scenarios, and some creative solutions were used. Earlier this year Caleb Baker had disclosed a project that brings WIF support to SL as part of the identity developer training kit. WIF is (among other stuff) a set of extensions to WCF that makes working with claims easier. Since Saml is very aligned with the claims model, and STS usualy emits Saml over WS-Trust protocol, this effectively brought WS-Trust support for SL for the first time.

What *might* SL5 support?
In other words we need to ask what is missing after the mentioned WIF support.

  • As far as I know the mentioned support was not official but a part of a training kit. Many organization will not use it until it is official.

  • WIF generally work on XP only. I say "generally" because the WIF/SL seems to be standalone so I'm not sure if that's the case with it also. Anyway since SL is not windows-only we will probably get this subset of WIF on all platforms.

  • WIF works well, but it is a different programming model than the Wcf WSFederation binding. Possibly Microsoft will consider supporting the native Wcf model as well.

  • STS is not limited to bearer tokens as the current WIF implementation is. This is actually an SL limitation since it only supports a subset of the Wcf bindings and most of the X.509 certificate settings are not supported. Microsoft might consider to support more bindings which might be used to communicate with the STS / application service.

  • The current training kit does not natively support multi leg federation (e.g. more than one STS), although dominick had published the a way to fix it.

    Again, these are just my guesses / wish-list, but either way this is great news for every silverlight developer.


    What's next? get this blog rss updates or register for mail updates!