Silverlight 5: More details on WS-Trust support

@YaronNaveh

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.

@YaronNaveh

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

Wcf on iPhone?

@YaronNaveh

Apple's announcement yesterday on relaxing the strict AppStore SDK policy is good news for web services interoperability. Why is that? We need to get some background first:

With the rising popularity of iPhone development, people seek for web services support.

One known Mac framework is wsdl2objc (wsdl to objective-C, the iPhone development language). It give the basic functionality of creating a proxy and calling the service.

If your web service is relatively simple and you can afford to build the soap payload by hand, you could also consider using the native Http library CFNetwork or a the ASIHTTPRequest wrapper.

The latter option also enables transport level security (ssl).

Message level security
This is a known pain point. I have yet to find a WS-Security implementation for the iPhone. If you are doing simple stuff (mainly username token) you can get away with manually pushing these headers. But more advanced scenarios (involving X.509) are harder and Apple does not seem to develop a ws-security implementation soon.

So why doesn't any third party develop one?
Until yesterday, apple banned the usage of code generators for AppStore applications. While a soap stack may be developed in pure objective-C, the realm of web services highly relies upon code generation and libraries.
Yesterday, Apple announced that it now allows any development tools to be used for AppStore applications. While the media mainly mentioned the implication on Adobe Flash, the announcment also positively affected the MonoTouch framework which enables C# development for iPhone. And while MonoTouch WCF support is still experiential and does not include advanced WS-*, there is now hope to have all the advanced stuff in a future version.

UPDATE 1: It seems MonoTouch does support the Wcf Silverlight stack. I assume username token is in but not sure about binary encoding and tcp transport. Looking at Mono WCF support page shows that Wcf is still not fully supported there, which may be an indication.

UPDATE 2: Carlos mentions that Silverlight is supported on Mac. After yesterday's announcement there is a reason to believe that SL will be officially supported in iPhone either which makes standalone SL applications a prospect too.

@YaronNaveh

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

Wcf Security Interoperability Series

@YaronNaveh

If you are a fan of Wcf security interoperability blogs - and if you read my blog you must admit you secretly are - you do not want to miss dhurba's series on WCF security interoperability.

As a side note, in the last weeks there is a bug with MSDN hosted blogs (as dhurba's) where I am sometimes prompted for a password when surfing there. This mostly happens with Chrome, but sometimes also in IE. This is usually solved by restarting the browser (better chances with IE) but is really annoying.

@YaronNaveh

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

An error was discovered processing the <Security> header

@YaronNaveh

This week's error can happen when Wse2 processes a secured message.

When Wse receives a message which has expired according to its producer policy we will see this exception:

Message Expired

Pretty much self explained. However in other cases we might see this error:

An error was discovered processing the header

This error means that the message timestamp is not valid according to the server policy (e.g. message was sent in the future).

The answer for these ills is to either sync the client & server clocks or to configure a larger skew.

@YaronNaveh

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

Replay attacks in Wcf

@YaronNaveh

One important attack against web services is a "replay attack": a malicious man-in-the-middle captures a valid message from a client to a server and resends it. This can cause duplicate transactions or denial of service (DOS).

Typically the way to protect here is to have a timestamp on the message and some expiration policy on the server. This is a very simplified description though, here are all the details.

The sending party attaches this timestamp to the SOAP message:

<wsu:Timestamp>
   <wsu:Created>2006-02-22T09:56:27Z</wsu:Created>
   <wsu:Expires>2006-02-22T10:01:27Z</wsu:Expires>
</wsu:Timestamp>

The receiving party can then decide based on some policy how much after the message was created it is suspected as a replay.

But what is this service policy? We can see an "expires" element in the client message itself, then why does the service need an additional policy?

The answer is that there is a duplicate protection against replay attacks. The client can decide its own policy and express it inside the message. The server should respect this policy and also adds its own policy. For example:

Client sends a message in 15:00

Client expiration policy is set to 15:05

Service gets the message in 15:06

Service expiration policy is set to 15:07

In this case the message is considered valid by the service, but the service is expected to respect the client policy and reject the message. the situation gets more interesting when we add real network latency and clocks synchronization into the picture.

In Wcf there are two somehow confusing settings to control the expiration:

LocalServiceSecuritySettings.ReplayWindow - The service expiration policy.

LocalclientSecuritySettings.TimestampValidityDuration - The client expiration policy as expressed in the message itself.

There are various other settings which relate to tolerance for clock differences and I will write a separate post on them some other time.

@YaronNaveh

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

Axis2 & Wcf Interoperability

@YaronNaveh

Recently I had to consume an Axis2 web service using a Wcf client. Axis2 used the rampart module for message security where a mutual X.509 certificate was required. Since I had control over both client and server I was able to fine tune them to reach perfect interoperability.

On the Axis side, I have found the WS-Policy flavor configuration better to work with (interoperability-wise) .

This is the Axis configuration:



and this is the Wcf configuration:



Here is the full Axis2 service (which is based on the rampart SDK sample):



and the wcf client:



You will also need certificates.

Client certificate:



Server Certificate:



If prompt for a password use "adminamdin".

This is the Java key store:



and the password is "adminadmin".

If you want to use your own certificate just make sure the certificates have an SKI.

@YaronNaveh

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

Axis 2 WS-Security (rampart) FAQ

@YaronNaveh

Rampart is the WS-Security module of Axis2.
Prabath summarizes all the current posts that were published in the rampart FAQ blog.

@YaronNaveh

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