Время жизни аутентификации с 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 - это всего лишь небольшая услуга (реализованная с использованием this tutorial), который я полностью контролирую.

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

Используя описанную выше настройку, я заметил, что аутентификация пользователей прекращается примерно через час, а затем их нужно повторно аутентифицировать, поэтому теперь я ищу способ продлить срок аутентификации.
Что касается моего Понимая, этого должно быть достаточно, чтобы продлить время жизни токена безопасности, выданного прокси-службой 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 действительно должно иметь какое-либо влияние, и если да, то почему, или мне просто не повезло с моими тестами, и это действительно было что-то еще, что могло помочь с проблемой)?

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


authentication asp.net adfs ws-federation wif
person Johan Hirsch    schedule 26.02.2015    source источник
comment
stackoverflow.com/q/14867613/9922   -  person rbrayb    schedule 02.03.2015

Ответы (1)


arrow_upward
1
arrow_downward

Вы достигли множества релевантных параметров. Я буду говорить только о части 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. См., Например, Витторио о скользящем истечении срока годности.

person paullem    schedule 27.02.2015