- PVSM.RU - https://www.pvsm.ru -
Статья будет интересна всем, кто хочет узнать значение страшного термина «Active Directory Federation Services» на примере из реальной жизни, а также всем, кто занимается разработкой кастомных систем на базе SharePoint и находится в процессе принятия решения, какую модель авторизации и аутентификации выбрать, либо собирается переключить существующее решение на ADFS.
А самое главное, она пригодится тем, кому важны потребительские качества IT-продукта, его значение и удобство для конечного пользователя.
Совсем недавно мы перевели на ADFS портал «Кассир-Бонус» для S7 Airlines. Это стало частью большого процесса инфраструктурных изменений системы. Всегда интересней говорить о сложных вещах в привязке к бизнес-целям, которым эти сложные технические вещи служат. Поэтому — небольшое описание «Кассир-Бонуса».
«Кассир-Бонус» — это система лояльности для кассиров, которые продают билеты на рейсы авиакомпании S7. Выполнена на MS SharePoint. Через портал кассиры подают заявки на бонусные билеты, продают их, копят бонусы и получают за них подарки (сувенирку, турпутевки, подарочные карты и т.п.) S7 таким образом может гибко управлять продажами нужных направлений, анализировать работу кассиров и агентств и много еще чего полезного.
Мы разрабатывали «Кассир-Бонус» для S7 с самого начала. Первый релиз состоялся в феврале 2013 года. Развитие системы продолжается. Например, только что мы провели полный редизайн портала. Но этому предшествовала миграция на ADFS, как важнейший этап модернизации. Об этом — дальше речь.
Вкратце схему работы ADFS можно описать так:
Клиент заходит на портал, веб-сервер портала перенаправляет клиента на сервис ADFS для авторизации. Здесь клиент проходит авторизацию и получает от сервиса авторизации «CLAIM» (маркер), затем с помощью данного маркера авторизуется на портале.
«Кассир-Бонус» является частью сложного решения на базе SharePoint, которое состоит из разных подсистем, живущих на разных сайтах. Нужно было обеспечить Single Sign On во все эти продукты, упростить и брендировать вход, сделать его более привычным для пользователей.
В данном случае требовалось не создание решения с нуля, а «миграция авторизации» с «classic ntlm» на ADFS. И мы пошли своим классическим путем отработанной многоэтапной подготовки к переносу [1]:
Итак, для начала анализируем, что нам нужно для перехода:
Начинаем процесс:
По первой части особых проблем не возникло – обыкновенный рефакторинг кода и настройка WCF сервиса. Пара недель – и все работает.
С отделением узла в отдельное приложение возникли некоторые сложности. В основном они были связаны с тем, что надо было при импорте/экспорте убедиться, что все данные сохранились, юзеры перетащились, права остались. Но так как данных на узле было достаточно много, то процедура импорта/экспорта занимала часа 3, и при неудачном исходе приходилось все это дело запускать заново и терпеть снова.
Самой долгой и непонятной проблемой до некоторых пор была проблема с импортом юзеров. Они импортировались вроде бы нормально, но вот права на списки и библиотеки и поля с типом User никак не хотели восстанавливаться.
После долгих и мучительных поисков причин выяснилось: проблема в том, что портал был ранее мигрирован с SharePoint 2007 на SharePoint 2010, и в схеме списков описание поля типа User было неполным. Пришлось для начала прогонять утилиту (написанную своими руками), потом опять делать экспорт/импорт. После этого импорт состоялся успешно.
a. Устанавливаем доверенный ADFS-сервер и сертификат через powershell скрипт
$map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$map2 = New-SPClaimTypeMapping "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming
$map3 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UserPrincipalName" -SameAsIncoming
$signingTokenCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$signingTokenCertPath")
$webServerCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$webServerCertPath")
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS Federated Server" -Description "ADFS Federated Server" -Realm $realm -ImportTrustCertificate $signingTokenCert -ClaimsMappings $map1,$map2,$map3 -SignInUrl $signinurl -IdentifierClaim $map3.InputClaimType
New-SPTrustedRootAuthority "ADFS Token Signing" -Certificate $signingTokenCert
New-SPTrustedRootAuthority "ADFS web server" -Certificate $webServerCert
b. Меняем настройки аутентификации приложения
c. Мигрируем юзеров для того чтобы все разрешения стали через Claims (опять через powershell скрипт)
$webAppUrl = "..."
$account = "..."
$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
$webApp = get-SPWebApplication $webAppUrl
$policy = $webApp.ZonePolicies("Default").Add($account,"PSPolicy")
$fullControlRole=$webApp.PolicyRoles.GetSpecialRole("FullControl")
$policy.PolicyRoleBindings.Add($fullControlRole)
$webApp.Update()
$webApp.MigrateUsers($true)
$webApp.ProvisionGlobally()
d. После этого обновляем все существующие учетные записи и приводим их к Claim записи вида i:0e.t|ADFS Federated Server|user@vsm.s7
После этого все заработало в целом. Потом еще долго тренировались локально и на тестовых серверах.
Боевое переключение делали в субботу, так как время только на экспорт/импорт уходило около 5 часов. В итоге со всеми мелкими проблемами начали в 9 утра, закончили в 12 ночи :)
В целом все заработало сразу нормально, так как до этого все оттренировали и оттестили на тестовом окружении. Но вылез один баг, который на тестовом у нас не повторялся никогда (и до сих пор не повторяется) — проблема логаута в Internet Explorer.
Суть в следующем:
Для выхода используется редирект на страницу ADFS-сервера вида adfs.ru/adfs/ls/?wa=wsignout1.0&Source=yoursiteurl [2]
При запросе страницы серверный обработчик удаляет сессию с ADFS, а чтобы удалить авторизационный cookies и сессию в SharePoint на этой же странице лежит невидимый iframe, в котором грузится страница выхода SharePoint-портала.
Так вот, чтобы выход в SharePoint прошел корректно, необходимо при вызове этой страницы выхода передать в запросе авторизационный cookies FedAuth/
Как оказалось, в IE это происходит не всегда, и получался эффект, когда мы жмем выход, но выйти не можем.
В итоге пришлось немного подправить url выхода, чтобы после отработки страницы логаута ADFS вызывалась напрямую страница логаута SharePoint, а после нее обратно страница авторизации ADFS:
https://myadfs.ru/adfs/ls/?wa=wsignout1.0&Source=https%3a%2f%2fmysharepoint%2f_trust%2f%3fwa%3dwsignoutcleanup1.0%26wreply%3dhttps%3a%2f%2fmyadfs.ru%2f [3]
(это предусмотрено у MS из коробки).
Почему миграция «Кассир-Бонуса» на ADFS оказалась важна для заказчика?
Автор: eastbanctech
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/asp-net/53231
Ссылки в тексте:
[1] классическим путем отработанной многоэтапной подготовки к переносу: http://habrahabr.ru/company/eastbanctech/blog/168493/
[2] adfs.ru/adfs/ls/?wa=wsignout1.0&Source=yoursiteurl: https://adfs.ru/adfs/ls/?wa=wsignout1.0&Source=yoursiteurl
[3] https://myadfs.ru/adfs/ls/?wa=wsignout1.0&Source=https%3a%2f%2fmysharepoint%2f_trust%2f%3fwa%3dwsignoutcleanup1.0%26wreply%3dhttps%3a%2f%2fmyadfs.ru%2f: https://myadfs.ru/adfs/ls/?wa=wsignout1.0&Source=https%3a%2f%2fmysharepoint%2f_trust%2f%3fwa%3dwsignoutcleanup1.0%26wreply%3dhttps%3a%2f%2fmyadfs.ru%2f
[4] Источник: http://habrahabr.ru/post/209834/
Нажмите здесь для печати.