So, let's say you are doing some ADFS programming and you see this big cookie being passed to your app called _WebSsoAuth.  Let's say your app is a token app, so the only trace of the claims from the federation is in the resulting Windows token with the user and group info (see here if you are not certain how to see this info).  Let's ignore for a second that it is possible to have a hybrid token/claims app that uses the IIS web service extension to build a Windows token for you, but also uses the HTTP Module to build a SingleSignOnIdentity so you can read the claims (this is possible!).  You are just really curious about what's in that cookie.  It looks like it contains a big blob of Base64 data.  Can we see the actual SAML token somehow?

Sadly, the answer is "no", not really.

Digging a Little Deeper

At this point, you may choose to stop reading or explore the futility in this a little further.

So, the data is clearly Base64-encoded, but a quick decode of it doesn't give us any angle brackets.  We wonder what gives, so we open up Reflector and start looking at the reverse engineered source code to find out what's up.

As we dig around, we soon discover that the WebSsoAuthenticationModule uses a class called LargeCookieWriter to read the data and decode it.  Interestingly, the Decode method actually calls into an unmanaged code function in another DLL installed by ADFS to do some sort of decompression/unmunging.  Interesting...I wonder what sort of magic goes on in there?  Must be cool if it had to be unmanaged C++!  But anyway, we are not deterred by this as a little reflection code allows us call LargeCookieWriter as well without any details of what's going on down deep.

So, we call the Decode method and we get a string back with readable characters.  Sort of.  Some of the data in there looks like our claims (I see a familar UPN and email address for example), but some of it is Base64 and none of it is XML.  Where's my SAML token???

At this point it gets a little wacky, as apparently there is some sort of XML in this data somehow as ADFS has implemented its own set of XmlReader classes to read this stuff.  This is all handled internally by the constructor on the SamlToken class.  The implementation is a little hard to follow though and we can't easily call the constructor on SamlToken ourselves because it also needs the TrustPolicy and I don't have one in memory right now and I'm getting a little tired of reflection code, so I give up.  Perhaps I'm just too easily deterred, but I really just wanted to see angle brackets and it does not look like there are any to be seen.  Sigh.

The moral of the story is that when the product team says that the _WebSsoAuth cookie is a proprietary format that is not intended to be read without their code, they mean it.  If you want the claims, you are supposed to go through the HTTP Module to get a SingleSignOnIdentity.  This gives them some flexibility to change how things work under the hood in future releases and other products.  Is this a violation of the WS-Fed spec?  Apparently not, as it doesn't specify the token format used in the cookie.

Should the Only Consumers of Claims Data Be .NET 2.0 Apps?

Would it be nice to have a way to get the claims as XML based on the cookie?  I think so.  The real use case in my book is allowing access to the claims for apps that aren't using .NET 2.0.  This could be a .NET 1.x app or could be another app platform altogether running on IIS.  It seems reasonable to me that I should be able to grab the cookie and call a web service method on the federation server to get a nice text-based XML SAML token to examine.  This just opens up the platform to allow a greater ecology of applications to participate.

Another option is to capture the redirected form post from the resource federation server when the user initially returns from logging in.  This does actually contain the XML-based SAML token.  The problem is that this event only happens once and triggers an immediate redirect, so there is an excellent chance you won't be able to grab it.

Still another option (which I think may be the best one) would be for the ADFS IIS web service extension (the part of ADFS that makes the token app work) to populate custom HTTP headers/server variables that contained the claims data.  Then any app platform running on IIS from ASP 3.0 to Rails to consume the claims.  The Windows token would be a secondary consideration, and in this case you could treat that token the same way you treat the anonymous user token in other forms authentication IIS apps (by ignoring it for purposes of authorization).

(ps: if anyone wants to see the reflection code required to actually call the Decode method and get the underlying string data, let me know and I'll post it.)