Memoria dei token di sicurezza WIF

Question

Possiedo un sito che fa parte del nostro STS personalizzato basato su WIF. Recentemente abbiamo implementato una Security Token Cache come descritto qui: Azure/web-farm ready SecurityTokenCache. La principale differenza tra la nostra implementazione e quella descritta in questo link è che utilizziamo Caching di AppFabric di Azure come backing-store per la cache duratura, anziché per la memorizzazione delle tabelle. Ciò ci ha aiutato ad alleviare un problema di troncamento del token su alcuni browser, ma ha introdotto un nuovo problema (vediamo il problema del troncamento principalmente nelle pagine che contengono google analytics + antiforgery cookie oltre al cookie di fedauth). Stiamo ricevendo la seguente eccezione diverse migliaia di volte al giorno:

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) 

Questa eccezione sembra accadere in un loop di reindirizzamento, quindi vedremo centinaia di loro entro un arco di tempo 1-2 minuti.

Non sono riuscito a trovare alcuna informazione utile durante la ricerca dell'eccezione. L'unica pepita che detiene finora qualche speranza è qualcuno che menziona che potrebbe essere correlato all'oggetto memorizzato nella cache che scade prima della sessione.

Non siamo riusciti a riprodurre il problema internamente e sappiamo solo che esiste a causa delle migliaia di voci che riempiono le nostre tabelle Elmah. Qualsiasi aiuto o intuizione sarebbe molto apprezzato.

Abbiamo spinto fuori quello che abbiamo pensato possa contribuire a risolvere il problema (codice qui sotto), ma non ha avuto alcun effetto:

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

Answer 1

Questo dovrebbe essere fatto se il numero dei sinistri nel token o la dimensione totale del il token è troppo grande per essere trasferito avanti e indietro nei cookie. In caso contrario, semplifica la soluzione e utilizza semplicemente l'impostazione predefinita che utilizza i cookie. Tuttavia, si utilizza la crittografia dei cookie basata su certificato, quindi è ancora "farm friendly". Per impostazione predefinita, WIF crittografa utilizzando DPAPI con affinità macchina.

Answer 2

Vediamo questo errore esatto se si passa a un'applicazione appena avviata, mentre il browser contiene ancora un cookie di una sessione precedente. Poiché questi cookie sono cookie di sessione, la soluzione è chiudere tutte le finestre del browser e sfogliare nuovamente l'applicazione.

La nostra applicazione è un'applicazione Web "normale" che reindirizza a ADFS utilizzando WIF senza particolari elementi di cache dei token di sicurezza, per quanto ne so. Tuttavia, utilizziamo la "modalità sessione" per i cookie WIF (vedi ad esempio "Your FedAuth Cookies on a Diet: IsSessionMode=true"), il che rende i cookie WIF molto più piccoli.

Answer 3

Attualmente stiamo affrontando esattamente lo stesso problema, anche se la nostra situazione è leggermente diversa. Stiamo cercando di utilizzare WIF per fornire Shibboleth SSO per Outlook Web App (OWA). Disponiamo di numerosi host OWA dietro un bilanciatore del carico.

WIF genera il cookie FedAuth (e FedAuth1) di dimensioni superiori a 2,5 kB. Il nostro servizio di bilanciamento del carico tronca il cookie. Pertanto, impostiamo la IsSessionMode -Property su true nel file global.asax di OWA. Ora, la dimensione del cookie è ridotta a ca. 600 byte, che va bene. OWA funziona.

Tuttavia, il Pannello di controllo di Exchange (ECP) che viene eseguito sullo stesso server non funziona più. ECP viene eseguito nello stesso pool di applicazioni IIS e ha anche la proprietà IsSessiobnMode impostata nel suo file global.asax. Ogni volta che ECP è chiamata, l'applicazione non invia alcuna risposta indietro ma WIF riferisce:

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

Questo problema causato dalla cache il SessionSecurityToken.La destinazione della cache si trova nel dominio locale del pool di applicazioni, quindi quando .NET ha bisogno di memoria, verrà automaticamente cancellato. La soluzione migliore è due annullare il cacheing per sicurezza o implementare il proprio sottosistema per la memorizzazione nella cache.

soluzione 1

AppFabric per Windows Server memcached - sistema distribuito di memoria oggetto di caching

soluzione 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 5

Ho un'applicazione singola pagina MVC come relying party con WSO2 4.5 come IDP e stava ottenendo lo stesso errore - "System.IdentityModel.Tokens.SecurityTokenException ID4243: Impossibile creare un SecurityToken. Un token non è stato trovato nella cache dei token e no cookie è stato trovato nel contesto. ... "Effettuò una ricerca e trovò le affermazioni riportate di seguito da Brock Allen su Thinktecture.

Questa eccezione viene generata quando il browser invia un cookie che contiene le affermazioni dell'utente, ma qualcosa sull'elaborazione non può essere eseguito (la chiave è stata modificata in modo che il token non possa essere convalidato o se si utilizzi una cache lato server e la cache sia vuota). Un utente finale non sarà in grado di fare molto su questo e stanno andando a . continuare a ottenere l'errore in quanto il browser continuare a inviare il cookie

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

Nello stesso articolo fornisce il seguente snippet di codice che risolve il problema nel mio caso. 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("~/"); 
    } 
}