Правильная настройка срока действия маркера входа для пользователей утверждений SAML SharePoint 2010

  • Article

Правильная настройка срока действия маркера входа для пользователей утверждений SAML SharePoint 2010

Недавно я разбирался с механизмом истечения срока действия куки-файлов для входа в систему и обнаружил довольно серьезную проблему. Для пользователей утверждений SAML, получивших куки-файл для входа в систему от служб федерации Active Directory, срок действия этого файла не истекал никогда. Это означает, что пользователь может закрыть браузер, открыть его снова через несколько минут или даже через несколько часов и перейти на сайт без повторной проверки подлинности в службах федерации Active Directory. Кроме того, эта же проблема была обнаружена и для клиентских приложений Office 2010. Наконец мне удалось выяснить все факторы, приводящие к возникновению данной проблемы, и я привожу их здесь.

Начнем с краткого введения. При первом открытии сайта SharePoint, защищенного с помощью утверждений SAML, система выполняет проверку подлинности пользователя и получает его утверждения. Поставщик удостоверений SAML (IP-STS) выполняет все необходимые операции и перенаправляет пользователя обратно на сайт SharePoint. При возврате на сайт SharePoint создается куки-файл федеративной проверки подлинности, по наличию которого система определяет, что пользователь прошел проверку подлинности. Для более удобного взаимодействия с пользователем этот куки-файл записывается в локальную папку. Если при последующих запросах к этому сайту система обнаруживает действительный куки-файл федеративной проверки подлинности, она просто считывает его и предоставляет доступ к контенту SharePoint без повторной проверки подлинности. Это может оказаться потрясением для пользователей служб федерации Active Directory 1.x и SharePoint 2007, поскольку в этих версиях все куки-файлы единого входа были привязаны к сеансам и не хранились на диске. Например, при закрытии браузера куки-файл уничтожался, поэтому при каждом открытии браузера требовалось повторно проходить проверку подлинности. Это не относится к SharePoint 2010.

ОБНОВЛЕНИЕ №1. Нам удалось настроить службу маркеров безопасности SharePoint на работу с куки-файлами сеансов, как в SharePoint 2007. Это реализуется с помощью приведенного ниже кода PowerShell.

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
iisreset

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

$sts.UseSessionCookies = $false
$sts.Update()
iisreset

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

  1. Свойство TokenLifetime в службах федерации Active Directory можно задавать отдельно для каждой проверяющей стороны. К сожалению, это свойство задается только при создании проверяющей стороны. Это представляет определенную проблему, поскольку по умолчанию поведение таково, что однажды полученным куки-файлом придется пользоваться в течение длительного времени (хотя я не проверял, как долго действует этот файл).

ОБНОВЛЕНИЕ №2. Рич Харрисон любезно предоставил код для обновления свойства TokenLifetime в службах федерации Active Directory для проверяющей стороны:

Set-ADFSRelyingPartyTrust -TargetName "SPS 2010 ADFS" -TokenLifetime 5

, где "SPS 2010 ADFS" — это имя объекта проверяющей стороны в службах федерации Active Directory 2.0.

Итак, для того чтобы задать свойство TokenLifetime проверяющей стороны в службах федерации Active Directory во время создания, необходимо воспользоваться PowerShell. Ниже приведен небольшой однострочный скрипт, с помощью которого я создал свою проверяющую сторону.

Add-ADFSRelyingPartyTrust -Name "FC1" -Identifier "https://fc1/_trust/" -WsFedEndpoint "https://fc1/_trust/" -TokenLifetime 2 -SignatureAlgorithm https://www.w3.org/2000/09/xmldsig#rsa-sha1

После создания проверяющей стороны с помощью этого сценария выполните вручную указанные ниже действия.

  1. Добавьте область в список идентификаторов (например urn:sharepoint:foo)
  2. Добавьте правило авторизации выпуска, чтобы разрешить доступ всем пользователям
  3. Добавьте правило преобразования выпуска для рассылки по адресам электронной почты и ролям

 

  1. Если сейчас попытаться войти в систему, то после проверки подлинности в службах федерации Active Directory возникнет бесконечный цикл переходов между SharePoint и службами федерации Active Directory. Если посмотреть на трафик в средстве Fiddler, окажется, что проверка подлинности в службах федерации Active Directory выполняется успешно, пользователь возвращается в SharePoint, система выпускает куки-файл федеративной проверки подлинности, пользователь перенаправляется на страницу /_trust/authenticate.aspx на сайте SharePoint, который удаляет выпущенный куки-файл и перенаправляет пользователя обратно на сайт служб федерации Active Directory. Это будет продолжаться до тех пор, пока службы федерации Active Directory не остановят процесс и не выдадут следующее сообщение об ошибке: “В течение одного сеанса клиентского браузера выполнено ‘6’ запросов за последние ‘12’ сек.”. Оказывается, это действительно имеет смысл. Это происходит потому, что значение свойства LogonTokenCacheExpirationWindow для службы маркеров безопасности SharePoint по умолчанию составляет 10 минут. В данном случае при создании своей проверяющей стороны я установил срок действия маркера в службах федерации Active Directory равным 2 минутам, поэтому после проверки подлинности маркера система обнаруживает, что куки-файл действителен в течение меньшего времени, чем значение свойства LogonTokenCacheExpirationWindow, и возвращает пользователя на сайт служб федерации Active Directory для повторной проверки подлинности. Процесс повторяется снова и снова. Чтобы устранить эту проблему, необходимо просто изменить значение свойства LogonTokenCacheExpirationWindow таким образом, чтобы оно стало меньше значения свойства TokenLifetime SAML, после чего можно будет войти на сайт. Ниже приведен пример настройки свойства LogonTokenCacheExpirationWindow в SharePoint.

$sts = Get-SPSecurityTokenServiceConfig

$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)

$sts.Update()

Iisreset

 

Теперь, после правильной настройки всех параметров срок действия маркера входа для пользователей SAML работает правильно. После закрытия окна браузера я могу вернуться на сайт без перенаправления в SharePoint в течение 2 минут. По истечении этого времени мне придется повторно пройти проверку подлинности в службах федерации Active Directory.

Это локализованная запись блога. Исходная статья находится по адресу Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users