STS, IssuedTokens, SAML and web browsers

Hey all,

I am finally starting to get into some of the deeper issues with WCF and am
now in the throws of forumlating a few scenarios before we hit the metal and
start writing some production code. In any case i seem to have an issue
right now with a particular security scenario.

I think we are going to want to use a federated scenario for security,
having a seperate STS to issue a SAML token and then of course when we do
hit our service we are able to inspect the claims in the token and base
decisions on them. Unfortunatley our services essentailly will automate, or
rather project in the SOA world, existing functionality presented through a
web front end. Now that web architecture uses a cookie to transport i guess
what might in the saml world be the claims specific to the client (this
cookie i want to replace with a cookie which contains instead the sts
issued saml token).

Anyway, suppose then we write wcf services to inspect the saml token wherein
we will look for these claims / properties then all is well and good if the
token is supplied via the proxies created by svcutil or vs. All this stuff
happens under the hood, and our token appears in the wcf service magically
and ready for inspection.

For our web scenario however the chances are we will contact the STS and
store the token in the web browser as a cookie. Now i will point out in
advance that cardspace is not an option. Anyway, so if i contact the same
webservice from some ajax code in the browser, notably using webHttpBinding,
somewhere in the pipeline that is WCF we'll need to extract that cookie, and
pump it into the servicesecuritycontext (the idea is that we will use the
token in the cookie to replace those existing cookie claims as i mentioned
above). I have no ideas how to do this, or whether there is some
functionality in WCF that can do this automatically. If this doesn't
happen - then how can my service code be security agnostic? I want to use
claims and i should code against claims. The browser shouldn't get in the
way of that and shouldn't require cardspace. There must be some
extensibility point in WCF where i can intercept WCF and make the magic
happen?

The code in the service should be able to do something like
OperationContext.Current.ServiceSecurityContext.Authori....(from memory
this) and regardless of whether the client was a browser or a smart client -
the service should be non the wiser as security would look the same
regardless.

Anyone know the answers, or have any pointers? I am about to embark on a
large system and WCF seems to fit the bill. I just need to hit that 98%
comfortable mark to give it the green light.

Cheers

Terraslate