Кэширование токенов безопасности WIF

У меня есть сайт, который является проверяющей стороной нашего пользовательского STS на основе WIF. Недавно мы внедрили кэш токена безопасности, как описано здесь:Azure / веб-ферма готова SecurityTokenCache, Основное отличие нашей реализации от описанной в этой ссылке заключается в том, что мы используем Azure AppFabric Caching в качестве резервного хранилища для долговременного кэша, а не для хранения таблиц. Это помогло нам избавиться от проблемы усечения токена в некоторых браузерах, но привело к появлению новой проблемы (мы видим проблему усечения в первую очередь на страницах, на которых есть файлы Google Analytics + файлы cookie для защиты от подделки в дополнение к файлу cookie fedauth). Теперь мы получаем следующее исключение несколько тысяч раз в день:

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)

Это исключение, похоже, происходит в цикле перенаправления, поэтому мы увидим сотни из них в течение 1-2 минут.

Мне не удалось найти какую-либо полезную информацию при исследовании исключения. Единственный самородок, который до сих пор сохраняет надежду, это кто-то упомянул, что он может быть связан с кэшированным объектом, срок действия которого истекает до сеанса.

Мы не смогли воспроизвести проблему внутренне и знаем только, что она существует из-за тысяч записей, заполняющих наши таблицы Elmah. Любая помощь или понимание будет очень цениться.

Мы выдвинули то, что, по нашему мнению, может помочь решить проблему (код ниже), но это не дало результата:

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

Ответы на вопрос(5)

если вы перейдете к недавно запущенному приложению, в то время как ваш браузер все еще хранит cookie из предыдущего сеанса. Поскольку эти файлы cookie являются файлами cookie сеанса, исправление состоит в том, чтобы закрыть все окна браузера и снова перейти к приложению.

Насколько я знаю, наше приложение является «обычным» веб-приложением, перенаправляющим в AD FS с использованием WIF, без каких-либо специальных вещей для кеширования маркеров безопасности. Однако мы используем «режим сеанса» для файлов cookie WIF (см., Например,"Ваши файлы cookie FedAuth на диете: IsSessionMode = true"), что делает куки WIF намного меньше.

 Allen Rice02 апр. 2012 г., 05:47
Итак, как мы сможем повторить это, чтобы быть уверенным, что это проблема, и как мы можем предотвратить ее появление? Я проверю, но я полагаю, что мы позволили браузеру сидеть на странице в течение 24 часов, а затем обновились, чтобы посмотреть, сможем ли мы воспроизвести его, а он не будет. Должны ли мы обеспечить запуск / перезапуск приложения? Я не уверен на 100%, что вы подразумеваете под «недавно запущенным приложением».

ия кэша находится в локальном домене пула приложений, поэтому, когда .NET требуется память, оно автоматически удаляется. Лучшее решение - отменить кеширование для безопасности или реализовать собственную подсистему кеширования.

решение 1

Memcached для AppFabric для Windows Server - система кеширования объектов с распределенной памятью

Решение 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);

хотя наша ситуация несколько иная. Мы пытаемся использовать WIF для обеспечения единого входа Shibboleth для Outlook Web App (OWA). У нас есть несколько хостов OWA за балансировщиком нагрузки.

WIF генерирует файл cookie FedAuth (и FedAuth1) размером более 2,5 КБ. Наш балансировщик нагрузки усекает cookie. Итак, мы установилиIsSessionModeСобственностиправда в файле OWA global.asax. Теперь размер печенья уменьшен до ок. 600 байт, что нормально. OWA работает.

Однако панель управления Exchange (ECP), которая работает на том же сервере, больше не работает. ECP работает в том же пуле приложений IIS, а также имеет свойство IsSessiobnMode-Property в своем файле global.asax. Каждый раз, когда вызывается ECP, приложение не отправляет ответ, но WIF сообщает:

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.

ны, использующее WSO2 4.5 в качестве IDP, и получаю ту же ошибку - "System.IdentityModel.Tokens.SecurityTokenException ID4243: не удалось создать SecurityToken. Маркер не найден в кэше токена и в контексте не было найдено ни одного файла cookie. ... "Произвел поиск и нашел утверждения Брока Аллена, известного из Thinktecture ниже.

Это исключение выдается, когда браузер отправляет файл cookie, который содержит утверждения пользователя, но что-то в отношении обработки не может быть выполнено (либо ключ был изменен, так что токен не может быть проверен, либо при использовании кэша на стороне сервера и кэша пустой). Конечный пользователь не сможет много с этим поделать, и он продолжит получать сообщение об ошибке, так как браузер будет продолжать отправлять cookie.

Полная статья:http://brockallen.com/2012/10/22/dealing-with-session-token-exceptions-with-wif-in-asp-net/

В той же статье он предоставляет следующий фрагмент кода, который решил проблему в моем случае. В Global.asax:

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

если количество заявок в токене или общий размер токена слишком велики, чтобы их можно было пересылать в cookie-файлах. Если это не так, то упростите свое решение и просто используйте настройку по умолчанию, которая использует куки. Однако вы должны использовать шифрование cookie на основе сертификатов, поэтому оно по-прежнему «дружественно к ферме». По умолчанию WIF будет шифровать с использованием DPAPI, который имеет привязку к компьютеру.

 Jeff28 мар. 2012 г., 17:59
Мы внедрили кэш маркеров безопасности, потому что в некоторых браузерах (сафари, опера и т. Д.) Наш общий стек cookie превышал ограничение размера файлов cookie домена в 4096 байт. Это было реализовано в ответ на проблему усечения cookie. Мы также уже используем шифрование файлов cookie на основе сертификатов. Кэш маркеров безопасности является для нас «обязательным» и дает эффект, на который мы надеялись, но реализация создала это новое исключение. Настоящая проблема с этим исключением заключается в том, что он бросает наших пользователей в цикл перенаправления.

Ваш ответ на вопрос