wif – 消息：ID4243：无法创建SecurityToken.在令牌缓存中找不到令牌,并且在上下文中未找到cookie

概述我们在生产环境中得到与此线程完全相同的错误. [ WIF Security Token Caching 有人解决了这个错误吗？ 消息：ID4243：无法创建SecurityToken.在令牌缓存中找不到令牌,并且在上下文中未找到cookie. 以下是有关我们设置的一些信息： •我们在.NET Framework 4.5.1中使用内置Windows Identity Framework •问题几乎总 我们在生产环境中得到与此线程完全相同的错误.
[ WIF Security Token Caching

有人解决了这个错误吗？
消息：ID4243：无法创建SecurityToken.在令牌缓存中找不到令牌,并且在上下文中未找到cookie.

以下是有关我们设置的一些信息：

•我们在.NET Framework 4.5.1中使用内置windows IDentity Framework

•问题几乎总是与从RelyingParty#X更改为RelyingParty #Y相关联(例如,当用户点击RP#Y他没有要求退出时) – 当他在此事件后再次登录时,他’在RP#Y里面,他正好走到他要求的页面

•我们正在使用e.SessionToken.IsReferenceMode = true; //在服务器上缓存,以获得更小的cookie

•通过使用IsReferenceMode = true,我们的FedAuth cookie存储一个指向实际令牌的“指针”,该指针存储在我们的数据库中

•我们使用自己的DatabaseSecurityTokenCache,它覆盖了SessionSecurityTokenCache中的函数.通过使用DatabaseSecurityTokenCache和IsSessionMode = true,我们对服务器场友好(但我们也保证在所有登录会话中都在同一服务器内)所以如果由于某种原因应用程序池死了,我们’能够通过DatabaseSecurityTokenCache从数据库中获取令牌.我已经通过在会话中间完全杀死IIS来验证这一点(使用“net stop WAS”并使用“net start W3SVC”重新启动它,我们仍然可以从DatabaseSecurityTokenCache获取令牌).我也试过通过简单地使用开箱即用的SessionSecurityTokenCache来做同样的事情,并且会分别失败(如预期的那样)

•默认令牌生存期为20分钟(但如果用户可以将其更改为40或60分钟) – 这只会在用户下次登录时生效(并且90％的用户只使用默认令牌20)分钟寿命)

•我们使用证书(在所有服务器上都相同)来加密FedAuth cookie,而不是机器密钥(如果使用服务器场,使用不同的机器密钥,那将是灾难性的)

•因此所有服务器都可以解密从其他服务器加密的cookie.

•我们在RelyingParty4和RelyingParty5(两个不同的依赖方)中有一个倒计时的JavaScript,用作“超时脚本”,以防用户无人看管他的计算机……当令牌即将退出时,他将退出到期 – (减去)30秒(例如20分钟 – 30秒= 19,5分钟),空闲时间.这是保护我们非常敏感的银行信息,因此当用户回到他的机器时,他将需要再次登录.例如我们也使用滑动会话([http://www.cloudidentity.com/blog/2013/05/08/sliding-sessions-for-wif-4-5/]]),当我们滑动时,客户端的JavaScript中的时间也会更新,以匹配令牌的长度减去30秒.这30秒用于确保注销时会话仍处于活动状态,因此它比令牌/会话的生命周期短一点.如果满足这个条件,我们目前正在滑动：总寿命/ 2 …. 20/2

•如果用户正在进行任何活动(即他正在四处走动,做一些工作),我们只会滑动.如上例所示,我们在分钟10中滑动(如果令牌寿命为20分钟)

•我们多次调试问题,这是我们得到的WIF错误：异常：System.IDentityModel.Tokens.SecurityTokenException消息：ID4243：无法创建SecurityToken.在令牌缓存中找不到令牌,并且在上下文中未找到cookie.源：Microsoft.IDentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader reader,SecurityTokenResolver tokenResolver)中的Microsoft.IDentityModel,位于Microsoft.IDentityModel.Web.SessionAuthenticationModule的Microsoft.IDentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(Byte []标记,SecurityTokenResolver tokenResolver). ReadSessionTokenFromcookie(Byte [] sessioncookie)位于System.Web.httpApplication.SyncEventExecutionStep.System上的Microsoft.IDentityModel.Web.SessionAuthenticationModule.OnAuthenticateRequest(Object sender,EventArgs eventArgs)的Microsoft.IDentityModel.Web.SessionAuthenticationModule.TryReadSessionTokenFromcookie(SessionSecurityToken& sessionToken). System.Web.httpApplication.ExecuteStep中的Web.httpApplication.IExecutionStep.Execute()(IExecutionStep step,Boolean& completedSynchronously)

•我们已经能够通过使用旧的FedAuth cookie和这个插件重新生成错误:(注意！我们不确定这是否与PROD上发生的情况相同,但至少它给出了同样的结果我们的记录系统中的错误)这很好,但我认为您应该添加有关我们如何修改FedAuth cookie内容的步骤,以便在本地实现此问题.-您可以使用：
从以前的一些会话中获取FedAuth cookie的值很简单(在同一台机器上！而不是从另一台机器上,这将无法工作)并将其粘贴到FedAuth cookie的值中并刷新页面.-

用于修改cookie的插件,在Chrome中称为“编辑此cookie”：
– 如果我们将此cookie的内容更改为上一个会话的值,然后点击刷新(Chrome中的CTRL R),我们就会得到臭名昭着的TokenSecurityException ID4243,并且RP会调用一个联合的FederatedSignout,因为我们无法从此恢复情况.

退出….

我还应该提一下,我们认真对待IsReferenceMode上的Microsoft MSDN文章标记为“重要”,并将其添加到我们的

SessionAuthenticationModule_SessionSecurityTokenCreated事件：

e.SessionToken.IsReferenceMode = true;

取自MSDN：

重要！
要在参考模式下运行,Microsoft建议为global.asax.cs文件中的WSFederationAuthenticationModule.SessionSecurityTokenCreated事件提供处理程序,并在SessionSecurityTokenCreatedEventArgs.SessionToken属性中传递的令牌上设置SessionSecurityToken.IsReferenceMode属性.这将确保会话令牌在每个请求的参考模式下运行,并且优于仅在会话认证模块上设置SessionAuthenticationModule.IsReferenceMode属性.

下面是我们整个SessionAuthenticationModule_SessionSecurityTokenReceived,
请检查我提出的评论……它解释了所有事情的作用：

voID SessionAuthenticationModule_SessionSecurityTokenReceived(object sender,SessionSecurityTokenReceivedEventArgs e)    {        if (e.SessionToken.ClaimsPrincipal != null)        {            DateTime Now = DateTime.UtcNow;            DateTime valIDTo = e.SessionToken.ValIDTo;            DateTime valIDFrom = e.SessionToken.ValIDFrom;            TimeSpan lifespan = new TimeSpan(valIDTo.Ticks - valIDFrom.Ticks);            double keyEffectivelifespan = new TimeSpan(e.SessionToken.KeyExpirationTime.Ticks - e.SessionToken.KeyEffectiveTime.Ticks).TotalMinutes;            double halfSpan = lifespan.TotalMinutes / 2;            if (valIDFrom.AddMinutes(halfSpan) < Now && Now < valIDTo)            {                SessionAuthenticationModule sam = sender as SessionAuthenticationModule;                // This will ensure a re-issue of the token,with an extended lifetime,IE "slIDe". ID deletes the current token from our databasetoken cache (with overrIDen Remove of the SessionSecurityTokenCache ) and writes a new one into the cache with the overrIDen AddOrUpdate of the SessionSecurityTokenCache.                 // it will also write the token back into the cookie ( just the pointer to the cookie,because it's stored in database-cache ) because the IsReferenceMode = True is set                e.Reissuecookie = true; // Will force the DatabaseSecurityTokenCache'ið to clean up the cache with this,handler.Configuration.Caches.SessionSecurityTokenCache.Remove(key); internally in WIF's SessioAuthenticationModule                e.SessionToken = sam.CreateSessionSecurityToken(                    e.SessionToken.ClaimsPrincipal,e.SessionToken.Context,Now,Now.AddMinutes(lifespan.TotalMinutes),false); // Make persistent,þannig að kakan lifir EKKI af browser-close / tab-lokun:                {                    e.SessionToken.IsReferenceMode = true; // Cache on server                }                // Not needed,because if Reissuecookie = true;  is set,it WILL to a WriteSessionTokenTocookie internally in WIF                //FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenTocookie(e.SessionToken); // <---- er þetta e.t.v. bara það sem við þurfum ? Nei,á ekki að þurfa,er gert þegar tóki er búinn til með CreateSessionSecurityToken            }            else if (valIDTo < Now)            {                // Fix                // http://blogs.planbsoftware.co.nz/?p=521                                    var sessionAuthenticationModule = (SessionAuthenticationModule)sender;                sessionAuthenticationModule.DeleteSessionTokencookie(); // <--- is this really needed like the article says ? http://blogs.planbsoftware.co.nz/?p=521                e.Cancel = true; // This will allow a silent-login if the STS cookie is still valID,e.g. switching between RP's where we're switching from an active RP to a RP which has it's cookie outdated,but the STS's session is still alive. We don't want to prompt the user for a new login,beucase the STS session is still OK!            }    }

解决方法 这篇文章帮助了我,所以它可以帮助你和其他有这种错误的人.

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

从this链接.

希望它有用！

总结

以上是内存溢出为你收集整理的wif – 消息：ID4243：无法创建SecurityToken.在令牌缓存中找不到令牌,并且在上下文中未找到cookie全部内容，希望文章能够帮你解决wif – 消息：ID4243：无法创建SecurityToken.在令牌缓存中找不到令牌,并且在上下文中未找到cookie所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。