У меня есть интересная проблема с попыткой отследить истекшие сеансы аутентификации WIF / куки.

Немного предыстории: сайт MVC 3, использует Windows Identity Foundation (WIF), который имеет доверие к серверу ADFS в качестве STS. Весь сайт защищен SSL. STS имеет срок действия токена 60 минут.

Когда пользователь выходит из системы вручную, мы просто вызываем метод SignOut в модуле FedAuth:

FederatedAuthentication.WSFederationAuthenticationModule.SignOut(false);

Это, конечно, удаляет куки-файлы FedAuth, но здесь начинается проблема. Если я получу эти файлы cookie с помощью Fiddler, я смогу повторно представить их на сайте в течение срока их действия, и они будут считаться зарегистрированными.

Я понимаю, что это выполняется с привилегированной позиции браузера, принявшего fiddler в качестве прокси-сервера ... но клиент обеспокоен тем, что эти файлы cookie с подлинным сроком действия, которые на самом деле не просрочены, представляют значительную угрозу безопасности. Они не уверены, что SSL в достаточной степени защищает сайт, и что если злоумышленник может выполнить атаку MITM, он может использовать эти файлы cookie после того, как пользователь решит, что он вышел из системы.

Я объяснил, что если они уязвимы после выхода из системы, они уязвимы во время входа, но им все равно ...

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

Я думаю, что это на самом деле более широкая проблема -> как вообще определить просроченные куки? Действительный файл cookie - это действительный файл cookie!

Очевидное решение состоит в том, чтобы как-то отслеживать эти куки-файлы после выхода из системы, но я бы хотел, если возможно, избегать маршрута с собственным кодом; как новичок, много литературы по безопасности говорит, что следует избегать пользовательского кодирования любого вида механики сессий, поскольку вы, вероятно, ошибетесь!

Кто-нибудь знает какие-либо стандартные решения в ASP.NET для этой проблемы?

Заранее спасибо.