Время жизни аутентификации с WS-Federation через ADFS и WIF

Некоторый фон

Я работаю над веб-приложением ASP.NET MVC, которое реализует федеративную аутентификацию с использованием WIF.
По независящим от меня причинам я вынужден использовать прокси-сервер STS, который, с одной стороны, служит IdP для моего приложения MVC, но в то же время он реализует собственную федеративную аутентификацию через сервер ADFS.
Таким образом, процесс аутентификации пользователя в приложении MVC выглядит следующим образом:

  1. Пользователь входит в приложение MVC.
  2. Приложение перенаправляет пользователя на прокси-сервер STS для аутентификации.
  3. Прокси-сервер STS перенаправляет пользователя на сервер ADFS для проверки подлинности.
  4. Сервер ADFS аутентифицирует пользователя и перенаправляет обратно на прокси-сервер STS.
  5. Прокси-сервер STS перенаправляет пользователя обратно в приложение с той же информацией аутентификации, которую выдал сервер ADFS.

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

Проблема (и что я пытался сделать, чтобы решить ее)

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

  1. Установите для параметра persistentCookiesOnPassiveRedirects значение true в конфигурации ws-federation приложения MVC с длительностью истечения 1 недели (чтобы убедиться, что cookie-файл аутентификации не теряется из-за истечения сеанса).
  2. Установка времени жизни HTTP-сеанса в приложении MVC на неделю (чтобы убедиться, что токен безопасности не теряется на стороне сервера из-за истечения сеанса).
  3. Установка времени жизни токенов безопасности для токенов, выданных прокси-сервером STS, равным 1 неделе (что я убедился в том, что оно применяется, изучив токены безопасности, полученные приложением MVC).
  4. Выполнение действий, описанных в пунктах 1 и 2, на прокси-сервере STS.
  5. Установка времени автоматической перезапуска пула приложений IIS для пула приложений MVC устанавливается один раз в неделю.

Ничто из вышеперечисленного, похоже, не решило проблему, но затем я попытался:

  1. Установка времени жизни токенов безопасности для токенов, выпущенных сервером ADFS, равным 8 часам.

В результате время аутентификации увеличилось, даже на 10-11 часов.

Вопрос

Что контролирует продолжительность аутентификации с WS-Federation в приведенном выше сценарии?
Какие из перечисленных выше вещей, которые я попробовал, действительно должны относиться к моей проблеме, а какие не должны затрагивать ее вообще (в частности, я хотел бы понять, действительно ли время жизни маркера ADFS должно иметь какой-либо эффект, и если да, то почему, или мне просто не повезло с моими тестами, и это было действительно что-то еще, что могло бы помочь с этой проблемой)?

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

Источник

1 ответ

Вы указали много соответствующих параметров. Я буду говорить только о части WIF/.NET и токенах SAML. Не об утилизации бассейнов и т. Д. Это разные темы. Вам придется взглянуть на XML в сообщениях SAML и токенах, если вы действительно хотите это контролировать.

Одна из проблем заключается в том, что между токенами SAML1 и SAML2 существуют различия. Кроме того, некоторые временные метки достоверности содержатся в протоколе SAML, который не используется между WIF и IdP.

Обобщенная:
Похоже, что WIF использует условия для SessionToken. Это единственное, что доступно в SAML 1.1. Хорошо там.
SecurityTokenHandler.ValidateToken (токен) вызывает DetectReplayedTokens(). Метод SecurityTokenHandler.DetectReplayedTokens(SecurityToken) проверяет действительность входящего токена (SubjectConfirmationData @NotOnOrAfter). В SAML 1.1 его нет, там WIF использует Условия @NotOnOrAfter. Это по существу правильно для обнаружения воспроизведения в SAML 2. Несколько глупо (слишком широко, слишком долго) для SAML1.1.

Приложения могут (и делают) переопределять это поведение в TokenHandler(ах) или в событиях WSFAM и SesAM. См. Например Витторио о скользящем истечении.

Источник
Другие вопросы по тегам