Тайм-аут ADFS 2.0 и связь между параметрами Freshness Value,TokenLifetime и WebSSOLifetime

Question

Мне интересно узнать связь между значением Freshness Value,TokenLifetime и WebSSOLifetime в сценарии тайм-аута ADFS 2.0. Я уже сделал свой анализ этого, и мне еще предстоит получить четкую картину.

Answer 1

Я собрал нижеприведенную информацию о времени ожидания ADFS из нескольких источников.

В конфигурации ADFS есть два основных таймаута:

1. WebSSOLifetime - Параметр тайм-аута для всего сервера - Значение по умолчанию = 480 минут
2. TokenLifetime - это настраивается для каждой проверяющей стороны - значение по умолчанию = 10 часов

WebSSOLifetime:

Это настройка для всего сервера, которая применяется ко всем RP (Проверяющая сторона). Всякий раз, когда пользователь запрашивает токен для данного RP, ему сначала нужно пройти аутентификацию в службе ADFS. После связи со службой ADFS он получит два токена, токен, который доказывает, кто он (давайте назовем его токен ADFS), и токен для RP (скажем, токен RP). Теперь тайм-аут WebSSOLifetime определяет, как долго токен ADFS можно использовать для запроса новых токенов RP без повторной аутентификации. Другими словами, пользователь может запросить новые токены для этого RP или для других RP, и ему не нужно будет доказывать, кто он, пока WebSSOLifetime не истечет токен ADFS.

TokenLifetime:

Это настройка уровня RP, которая применяется к конкретному RP. Это не повлияет на другие RP, настроенные на сервере ADFS. Когда пользователь получает токен RP, срок его действия истекает. В это время пользователю придется снова зайти на сервер ADFS и запросить новый токен RP. В зависимости от того, действителен ли токен ADFS или нет, ему не нужно будет проходить повторную аутентификацию.

Одним из аргументов в пользу снижения TokenLifetime может быть то, что вы хотите, чтобы заявки обновлялись быстрее. При использовании по умолчанию всякий раз, когда изменяется какая-либо информация из хранилища атрибутов, потенциально может потребоваться 10 часов, прежде чем это изменение достигнет пользователя в его утверждениях. Мы можем установить TokenLifetime через скрипт Shell, используя следующую процедуру:

• Запустите PowerShell в режиме администратора и введите команду

       “Add-PSSnapin Microsoft.Adfs.Powershell” 

• Получить информацию о конфигурации приложения, используя команду:

Get-ADFSRelyingPartyTrust -Name "отображаемое имя вашего приложения в доверенной стороне ADFS"

• Измените значение TokenLifeTime в настройках ADFS на требуемое значение с помощью следующей команды:

set-ADFSRelyingPartyTrust -Targetname "отображаемое имя вашего приложения в доверенной стороне ADFS" -TokenLifetime "значение в минутах"

Это сделает недействительным токен RP после указанного периода.

С указанными выше настройками, чтобы предложить пользователю повторно пройти аутентификацию, мы требуем, чтобы время WebSSOLifetime было меньше, чем время TokenLifetime.

Представьте себе сценарий, в котором разные RP имеют разные требования к времени ожидания повторной аутентификации - скажем, RP хочет, чтобы пользователи проходили повторную аутентификацию через 10 минут (TokenLifetime установлено в 10), когда время сервера WebSSOLifetime для других RP установлено в 50 минут. В этом случае пользователь не будет перенаправлен на страницу аутентификации ADFS. Вместо этого пользователю будет создан новый сеанс без какой-либо аутентификации. Это связано с тем, что токен WebSSO все еще действителен, хотя токен уровня RP истек.

Ценность свежести:

Чтобы выйти из этого цикла, мы можем использовать параметр под названием Freshness Value (OASIS - wfresh). Этот параметр (установленный как freshness="0") при включении в раздел federatedAuthentication вашего web.config предложит IDP проверить значение свежести токена на основе текущего времени в параметре WCT.

Описание OASIS для значения Freshness - wfresh:

"Этот необязательный параметр указывает требования свежести. Если указано, это указывает желаемый максимальный возраст аутентификации, указанный в минутах. IP/STS НЕ ДОЛЖЕН выдавать токен с более длительным сроком службы. Если указано "0", это означает, что IP/STS запрашивает у пользователя повторную аутентификацию перед выдачей токена ".

Другие факторы, влияющие на время ожидания:

Мы также должны учитывать следующие факторы при публикации ADFS через обратный прокси-сервер ISA или TMG в том месте, где прокси-серверы ADFS не используются - как правило, называются обратными прокси-серверами, не поддерживающими утверждения.

MSISSignOut отслеживает все токены, выпущенные ADFS (в этом сеансе), поэтому запрос на выход может сделать недействительными все сеансы проверяющей стороны, которые были аутентифицированы ADFS, вместо простого выхода из приложения, в котором был инициирован запрос. Это то, что известно как Единый выход или Единый выход. Однако ISA/TMG не был разработан с учетом требований SAML, поэтому они не могут реагировать соответствующим образом, когда инициируется процесс тайм-аута / выхода.

Время жизни токена обратного прокси-сервера, не поддерживающего утверждения, становится очевидным, когда мы сталкиваемся с одним из следующих сценариев:

• Сеанс пользователя истек с запрошенным веб-приложением, и ему необходимо повторно пройти аутентификацию с помощью ADFS, или

• Выход инициирован, как описано выше.

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

Это на самом деле не имеет ничего общего с ADFS. Вот как был настроен сеанс на обратном прокси. Это серьезная причина ограничить время жизни сеанса обратного прокси для этого прослушивателя. Таким образом, даже если время сеанса ADFS истекло, при активном сеансе обратного прокси-сервера можно повторно пройти аутентификацию в ADFS. Подробнее о настройке TMG - ADFS читайте в этом блоге.

Я держу этот вопрос открытым, чтобы получить больше информации по этой теме.