Кэширование токенов безопасности WIF - PullRequest
Новая
       4

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

12 голосов
/ 20 марта 2012

У меня есть сайт, который является проверяющей стороной нашего пользовательского 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 ]

6 голосов
/ 09 мая 2014

В качестве проверяющей стороны я использую одностраничное приложение MVC, использующее 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("~/");
    }
}
2 голосов
/ 24 марта 2013

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

решение 1

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

раствор 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);
1 голос
/ 29 марта 2012

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

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

1 голос
/ 19 июня 2012

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

WIF генерирует файл cookie FedAuth (и FedAuth1), размер которого превышает 2,5 КБ. Наш балансировщик нагрузки усекает cookie. Поэтому мы устанавливаем IsSessionMode -Property в true в файле global.asax OWA. Теперь размер печенья уменьшен до ок. 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.
0 голосов
/ 22 марта 2012

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

...