WIF Security Token Caching

Question

I have a site that is a relying party to our WIF-based custom STS. We recently implemented a Security Token Cache as described here: Azure/web-farm ready SecurityTokenCache. The major difference between our implementation and the one described in that link is that we use Azure AppFabric Caching as the backing store for the durable cache, rather than table storage. This helped to relieve us of a token truncation issue on certain browsers but has introduced a new problem (We see the truncation problem primarily on pages that have google analytics + antiforgery cookies in addition to the fedauth cookie). We're now receiving the following exception several thousand times per day:

System.IdentityModel.Tokens.SecurityTokenException
ID4243: Could not create a SecurityToken. A token was not found in the token cache and no cookie was found in the context.

System.IdentityModel.Tokens.SecurityTokenException: ID4243: Could not create a       SecurityToken. A token was not found in the token cache and no cookie was found in the context.
   at Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver)
   at Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(Byte[] token, SecurityTokenResolver tokenResolver)
   at Microsoft.IdentityModel.Web.SessionAuthenticationModule.ReadSessionTokenFromCookie(Byte[] sessionCookie)
   at Microsoft.IdentityModel.Web.SessionAuthenticationModule.TryReadSessionTokenFromCookie(SessionSecurityToken& sessionToken)
   at Microsoft.IdentityModel.Web.SessionAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

This exception seems to be happening in a redirect loop, so we'll see hundreds of them within a 1-2 minute time span.

I've been unable to locate any useful information while researching the exception. The only nugget that holds any hope so far is someone mentioning that it may be related to the cached object expiring prior to the session.

We've been unable to reproduce the problem internally and only know it exists because of the thousands of entries filling up our Elmah tables. Any help or insight would be very much appreciated.

We pushed out what we thought may help resolve the problem (code below) but it had no effect:

HttpContext.Current.Response.Cookies.Remove("FedAuth");
WSFederationAuthenticationModule authModule = FederatedAuthentication.WSFederationAuthenticationModule;
string signoutUrl = (WSFederationAuthenticationModule.GetFederationPassiveSignOutUrl(authModule.Issuer, authModule.Realm, null));
Response.Redirect(signoutUrl);

Answer 1

I have an MVC single page application as a relying party using WSO2 4.5 as the IDP and was getting the same error - "System.IdentityModel.Tokens.SecurityTokenException ID4243: Could not create a SecurityToken. A token was not found in the token cache and no cookie was found in the context. ..." Did a search and found the statements below by Brock Allen of Thinktecture fame.

This exception is thrown when the browser is sending a cookie that contains the user’s claims but something about the processing can’t be performed (either the key has changed so the token can’t be validated or if using a server side cache and the cache is empty). An end user isn’t going to be able to do much about this and they’re going to continue to get the error since the browser will keep sending the cookie.

Full article: http://brockallen.com/2012/10/22/dealing-with-session-token-exceptions-with-wif-in-asp-net/

In the same article he provides the following snippet of code that solved the issue in my case. In Global.asax:

void Application_OnError()
{
    var ex = Context.Error;
    if (ex is SecurityTokenException)
    {
        Context.ClearError();
        if (FederatedAuthentication.SessionAuthenticationModule != null)
        {
            FederatedAuthentication.SessionAuthenticationModule.SignOut();
        }
        Response.Redirect("~/");
    }
}

Answer 2

This problem caused by caching the SessionSecurityToken. The cache destination is in the local domain of application pool so when the .NET needs memory, it automatically will be wiped out. The best solution is two cancel the cacheing for security or implement your own subsystem for caching.

solution 1

AppFabric for Windows Server memcached - a distributed memory object caching system

solution 2

var sessionSecurityToken = new SessionSecurityToken(principal, TimeSpan.FromHours(Convert.ToInt32(System.Web.Configuration.WebConfigurationManager.AppSettings["SessionSecurityTokenLifeTime"])))
{
    IsPersistent = false, // Make persistent
    IsReferenceMode = true // Cache on server
};
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionSecurityToken);

Answer 3

We are currently facing exactly the same problem, although our situation is a bit different. We are trying to use WIF to provide Shibboleth SSO for Outlook Web App (OWA). We have several OWA hosts behind a load balancer.

WIF generates the FedAuth cookie (and FedAuth1) which is more than 2.5 kB in size. Our load balancer truncates the cookie. So we set the IsSessionMode-Property to true in OWA's global.asax file. Now, the cookie size is reduced to approx. 600 bytes, which is fine. OWA works.

However, the Exchange Control Panel (ECP) which runs on the same server, does not work any longer. ECP runs in the same IIS application pool and has also the IsSessiobnMode-Property set in its global.asax file. Whenever ECP is called, the application does not send back any response but WIF reports:

Current user: 'User not set'
   Request for URL 'http://owa.ourdomain.com/ecp/' failed with the following error:
   System.IdentityModel.Tokens.SecurityTokenException: ID4243: Could not create a SecurityToken. A token was not found in the token cache and no cookie was found in the context.

Answer 4

We see this exact error if you browse to a freshly started application, while your browser still holds a cookie from an earlier session. Since these cookies are session cookies, the fix is to close all browser windows and browse again to the application.

Our application is a 'normal' web application redirecting to AD FS using WIF without any special security token cache things, as far as I know. However, we do use 'session mode' for WIF cookies (see for example "Your FedAuth Cookies on a Diet: IsSessionMode=true"), which makes the WIF cookies a lot smaller.

Answer 5

This should be done if the number of claims in the token or the total size of the token is too big to be transfered back and forth in cookies. If that is not the case, then simplify your solution and just use the default setting that uses cookies. You shuold however, use certificate based cookie encryption, so it is still "farm friendly". By default WIF will enrcrypt using DPAPI that has machine affinity.