WIF 4.5 Точка безопасности BootstrapContext null

Я использую новый материал 4.5 WIF для аутентификации пользователей веб-сайта и для обеспечения связи между моим веб-сайтом MVC и службами WCF.

У меня есть веб-сайт, настроенный для сохранения контекста начальной загрузки, чтобы я мог повторно использовать один и тот же токен безопасности для всех запросов на уровень сервиса.

В нормальных условиях все работает нормально, и каждый запрос веб-сайта аутентифицирован, а SecurityToken предоставляется через контекст для защиты вызовов WCF.

Если веб-сайт домена reset (например, создание приложения при разработке), любые запросы на веб-сайт будут по-прежнему аутентифицированы, но SecurityToken больше не доступен в контексте для передачи вызовов WCF.

Отладка BootstrapContext имеет 4 полезных свойства:

SecurityToken
SecutiryTokenHandler
Token
TokenBytes

Домен приложения reset SecurityToken и SecurityTokenHandler имеют значения, а post reset Знак имеет значение.

Наблюдая за значением для Token после reset, похоже, что это необработанный XML SAML, поэтому я могу предположить, что он может перегрузить полный SecutiryToken, но это кажется странным поведением, о котором я не могу найти никакой документации.

Любые идеи, что я мог бы сделать для обеспечения безопасности, всегда доступны для спасения меня в обмене с токеном XML?

Обновление

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

В конце концов я отказался от попытки разобраться и теперь использую следующий фрагмент кода, чтобы убедиться, что у меня есть токен

if (context.SecurityToken != null)
{
    token = context.SecurityToken;
}
else if (context.Token.IsNotEmpty())
{
    var handlers = FederatedAuthentication.FederationConfiguration.IdentityConfiguration.SecurityTokenHandlers;
    token = handlers.ReadToken(new XmlTextReader(new StringReader(context.Token)));
}

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

ОТВЕТЫ

Ответ 1

Я наткнулся на ту же проблему. Я вижу, что токен имеет xml-представление токена, а SecurityToken - null. Я также заметил, что это действительно легко воспроизвести, убив w3wp.exe.

Ответ 2

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

Ответ 3

У меня была такая же проблема, когда я применил образец ClaimsAwareWebFarm от Microsoft. Проблема возникает, когда вы добавляете этот раздел в файл web.config:

  <caches>
    <sessionSecurityTokenCache type="CacheLibrary.SharedSessionSecurityTokenCache, CacheLibrary">
      <!--cacheServiceAddress points to the centralized session security token cache service running in the web farm.-->
      <cacheServiceAddress url="http://localhost/SecurityTokenCacheService/SessionSecurityTokenCacheService.svc" />
    </sessionSecurityTokenCache>
  </caches>

Спасибо Мэтту за это обходное решение!