Мы'Мы получаем ту же ошибку, что и в этой теме ... в нашей производственной среде. [Кэширование токенов безопасности WIF

У кого-нибудь есть исправление этой ошибки? Сообщение: ID4243: не удалось создать токен безопасности. Токен не найден в кеше токена, и в контексте не найдены файлы cookie.

Вот некоторая информация о нашей настройке: •

 Мы'использовать встроенную Windows Identity Framework с .NET Framework 4.5.1 •

 Проблема почти всегда связана с переходом с RelyingParty # X на RelyingParty # Y (например, в тот момент, когда пользователь нажимает RP # Y, он ‘выписал, не прося) - когда он снова входит в систему после этого события, он ‘взяты прямо на страницу, о которой он просил, внутри RP # Y •

 Мы'повторно использовать e.SessionToken.IsReferenceMode = true; // Кэшируем на сервере, чтобы получить меньший куки

 Используя IsReferenceMode = true, наши файлы cookie FedAuth хранятуказатель" к текущему токену, который хранится в нашей базе данных •

 Мы'мы используем наш собственный DatabaseSecurityTokenCache, который переопределяет функции в SessionSecurityTokenCache. Используя DatabaseSecurityTokenCache вместе с IsSessionMode = true, мы ‘сервер-ферма (но мы ‘Мы также гарантируем, что будем находиться на одном и том же сервере в течение всей нашей сессии входа в систему), поэтому, если пул приложений по какой-то причине умирает, мы ‘возможность получить токен из базы данных через DatabaseSecurityTokenCache. Я'подтвердил это, полностью убив IIS в середине сеанса (счистый стоп был » и перезагрузите его снова счистый старт W3SVC “ и мы'все еще в состоянии получить токен из DatabaseSecurityTokenCache). Я'мы также попытались сделать то же самое, просто используя готовый SessionSecurityTokenCache, и это приведет к ошибке соответственно (как и ожидалось) •

 Время жизни токена по умолчанию составляет 20 минут (но пользователь может изменить его на 40 или 60 минут, если он хочет) - это вступит в силу только при следующем входе пользователя в систему (и 90% нашего пользователя просто используют время жизни по умолчанию 20 минут) •

 Мы'использование сертификата (одинакового на всех серверах) для шифрования файла cookie FedAuth, а НЕ машинного ключа (который был бы катастрофическим, если использовать серверную ферму с разными машинными ключами) •

 поэтому все серверы могут расшифровывать файлы cookie, которые были зашифрованы с другого сервера.

 У нас есть javascript с обратным отсчетом в наших RelyingParty4 и RelyingParty5 (две разные проверяющие стороны), который используется каксценарий тайм-аута если пользователь оставляет свой компьютер без присмотра ... он выйдет из системы, когда срок действия токена истекает - (минус) 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. ReadSessionTokenFromCookie (Byte [] sessionCookie) в Microsoft.IdentityModel.Web.SessionAuthenticationModule.TryReadSessionTokenFromCookie (SessionSecurityToken & sessionToken) в Microsoft.IdentityModel.Web.SessionAuthenticationModule.OnAuthenticateRequest (отправитель объекта, EventArgs eventArgs) в System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionEte.tep.tep.Tec.tep.Exp. , Логическое & completedSynchronously) •

 Мы'мы смогли воспроизвести ошибку, используя старый файл cookie FedAuth и этот плагин: (внимание! Мы ‘не уверен, что это то же самое, что ‘происходит на PROD, но, по крайней мере, это дает ту же ошибку в нашей системе регистрации) Это хорошо, но я думаю, что вы должны добавить шаги о том, как мы weВы можете изменить содержимое cookie-файла FedAuth, чтобы решить эту проблему локально. - Вы можете использовать это: Это ‘Это просто, взяв значение файла cookie FedAuth из некоторых предыдущих сессий (на той же машине! не с другой машины, которая победила ‘работать) И вставить его в значение файла cookie FedAuth и обновить страницу.

Плагин, используемый для изменения куки, в Chrome называется „Редактировать это печенье: - Если мы изменим содержимое этого файла cookie на значение из предыдущего сеанса и нажмем на обновление (CTRL + R в Chrome), мы получим печально известную TokenSecurityException ID4243, а RP вызовет немедленное связывание FederatedSignout, потому что мы 'не в состоянии оправиться от этой ситуации.

Выписка....

Я также должен упомянуть, что мы взялис Microsoft MSDN 'с пометкой "Важный" на IsReferenceMode серьезно и добавил его также в наш

Событие SessionAuthenticationModule_SessionSecurityTokenCreated:

e.SessionToken.IsReferenceMode = true;

взято из MSDN:

Важный! Для работы в справочном режиме Microsoft рекомендует предоставить обработчик для события WSFederationAuthenticationModule.SessionSecurityTokenCreated в файле global.asax.cs и задать свойство SessionSecurityToken.IsReferenceMode для токена, переданного в свойстве SessionSecurityTokenCreatedEventArgs.SessionToken. Это будет гарантировать, что маркер сеанса работает в опорном режиме для каждого запроса и предпочитать просто установив свойство 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); //