WIF 4.5 BootstrapContext security token null

I am using the new 4.5 WIF stuff to authenticate users of the website and to secure the communication between my MVC website and WCF services.

I have the website configured to save the bootstrap context so that I can re-use the same security token for all requests to the service layer.

Under normal conditions all is working fine with each website request authenticated and the SecurityToken made available via the context to secure the WCF calls.

If however the websites app domain is reset (e.g. building the app while developing) any requests to the website will still be authenticated but the SecurityToken is no longer available in the context to pass on to the WCF calls.

Debugging the BootstrapContext it has 4 useful properties:

SecurityToken
SecutiryTokenHandler
Token
TokenBytes

Pre-app domain reset SecurityToken and SecurityTokenHandler have values, and post reset Token has a value.

Eyeballing the value for Token after the reset it looks like this is the raw SAML XML so I can presumably rehydrate a full SecutiryToken from it but this seems strange behavior that I cannot find any documentation about.

Any ideas what I could do to ensure the SecurityToken is always available to save me messing around with the token XML?

Update

Using dotPeek to look at what is going on in the framework source code I could see the execution path that casues this behaviour but I couldn't determine any reason why it needed to be this way and how it could be avioded.

In the end I gave up trying to work it out and now use the following piece of code to ensure I have a token

if (context.SecurityToken != null)
{
    token = context.SecurityToken;
}
else if (context.Token.IsNotEmpty())
{
    var handlers = FederatedAuthentication.FederationConfiguration.IdentityConfiguration.SecurityTokenHandlers;
    token = handlers.ReadToken(new XmlTextReader(new StringReader(context.Token)));
}

What I am now concerned about is I have missed some reasoning behind this behaiour and my fix above is going to blow up at some point.

回答1:

I have stumbled upon the same issue. I see the Token to have the xml representation of the token and the SecurityToken being null. I also noticed that this is really easy to reproduce by killing w3wp.exe.

回答2:

I have solved the problem by deleting the browser cookie including the Fedauth cookie. Once debugging again I was able to get all needed values

回答3:

I had the same issue when I implemented the ClaimsAwareWebFarm sample from microsoft. The problem arises when you add this section to the web.config:

  <caches>
    <sessionSecurityTokenCache type="CacheLibrary.SharedSessionSecurityTokenCache, CacheLibrary">
      <!--cacheServiceAddress points to the centralized session security token cache service running in the web farm.-->
      <cacheServiceAddress url="http://localhost/SecurityTokenCacheService/SessionSecurityTokenCacheService.svc" />
    </sessionSecurityTokenCache>
  </caches>

Thank you Matt for this workaround!