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

Статья будет интересна всем, кто хочет узнать значение страшного термина «Active Directory Federation Services» на примере из реальной жизни, а также всем, кто занимается разработкой кастомных систем на базе SharePoint и находится в процессе принятия решения, какую модель авторизации и аутентификации выбрать, либо собирается переключить существующее решение на ADFS.

А самое главное, она пригодится тем, кому важны потребительские качества IT-продукта, его значение и удобство для конечного пользователя.

Совсем недавно мы перевели на ADFS портал «Кассир-Бонус» для S7 Airlines. Это стало частью большого процесса инфраструктурных изменений системы. Всегда интересней говорить о сложных вещах в привязке к бизнес-целям, которым эти сложные технические вещи служат. Поэтому — небольшое описание «Кассир-Бонуса».

«Кассир-Бонус» — это система лояльности для кассиров, которые продают билеты на рейсы авиакомпании S7. Выполнена на MS SharePoint. Через портал кассиры подают заявки на бонусные билеты, продают их, копят бонусы и получают за них подарки (сувенирку, турпутевки, подарочные карты и т.п.) S7 таким образом может гибко управлять продажами нужных направлений, анализировать работу кассиров и агентств и много еще чего полезного.

Мы разрабатывали «Кассир-Бонус» для S7 с самого начала. Первый релиз состоялся в феврале 2013 года. Развитие системы продолжается. Например, только что мы провели полный редизайн портала. Но этому предшествовала миграция на ADFS, как важнейший этап модернизации. Об этом — дальше речь.

Вкратце схему работы ADFS можно описать так:

Клиент заходит на портал, веб-сервер портала перенаправляет клиента на сервис ADFS для авторизации. Здесь клиент проходит авторизацию и получает от сервиса авторизации «CLAIM» (маркер), затем с помощью данного маркера авторизуется на портале.

Миграция на ADFS в авиакомпании S7

«Кассир-Бонус» является частью сложного решения на базе SharePoint, которое состоит из разных подсистем, живущих на разных сайтах. Нужно было обеспечить Single Sign On во все эти продукты, упростить и брендировать вход, сделать его более привычным для пользователей.

В данном случае требовалось не создание решения с нуля, а «миграция авторизации» с «classic ntlm» на ADFS. И мы пошли своим классическим путем отработанной многоэтапной подготовки к переносу:

1. Развернули у себя на тестовой площадке прототип решения и начали отрабатывать ошибки.
2. Убедившись, что все заработало, составили документацию по развертыванию решения и отправили ее заказчику, чтобы он развернул решение у себя.
3. Протестировали у заказчика на тестовой конфигурации.
4. Успешно провели боевую миграцию.

Анализируем собственное решение

Итак, для начала анализируем, что нам нужно для перехода:

1. У нас есть список пользователей сайта (несколько тысяч), которых надо заменить на claim записи.
2. У нас есть списки и библиотеки документов с кастомными разрешениями. И нужно, чтобы после миграции у новых пользователей права остались прежними.
3. У нас есть куча кастомного кода (веб-части, страницы, хендлеры и т.д.), в котором проверяется уровень доступа пользователя через AD. Все это надо прорефакторить и переписать с учетом того, что пользователи могут быть клеймовые.
4. Так как мы переключаем на ADFS не весь портал, а только отдельный узел, то придется узел выделить в отдельное веб-приложение. Но часть данных используется с корневого узла, поэтому необходимо вынести слой работы с данными в WCF-сервис, с помощью которого будем эти данные в нашем новом приложении получать.

Начинаем процесс:

1. Начали с 4 пункта – выделения получения данных с корневого узла в отдельный сервис и последующего отделения нашего узла в отдельное приложение.

   По первой части особых проблем не возникло – обыкновенный рефакторинг кода и настройка WCF сервиса. Пара недель – и все работает.
   С отделением узла в отдельное приложение возникли некоторые сложности. В основном они были связаны с тем, что надо было при импорте/экспорте убедиться, что все данные сохранились, юзеры перетащились, права остались. Но так как данных на узле было достаточно много, то процедура импорта/экспорта занимала часа 3, и при неудачном исходе приходилось все это дело запускать заново и терпеть снова.

   Самой долгой и непонятной проблемой до некоторых пор была проблема с импортом юзеров. Они импортировались вроде бы нормально, но вот права на списки и библиотеки и поля с типом User никак не хотели восстанавливаться.

   После долгих и мучительных поисков причин выяснилось: проблема в том, что портал был ранее мигрирован с SharePoint 2007 на SharePoint 2010, и в схеме списков описание поля типа User было неполным. Пришлось для начала прогонять утилиту (написанную своими руками), потом опять делать экспорт/импорт. После этого импорт состоялся успешно.

2. Теперь можно переключать новое приложение на ADFS. Идем по стандартной процедуре:

   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

При запросе страницы серверный обработчик удаляет сессию с 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
(это предусмотрено у MS из коробки).

Заключение

Почему миграция «Кассир-Бонуса» на ADFS оказалась важна для заказчика?

1. ADFC дает возможность авторизоваться на портале с помощью дружелюбного логина-пароля вместо устрашающей стандартной Windows Authentication формы. Также, если пользователь забыл пароль, система любезно его подскажет, не нужно будет разыскивать админа и доказывать ему, что ты не верблюд.
2. Такой вход можно брендировать корпоративными цветами и символикой и подогнать под единые корпоративные визуальные стандарты.
3. ADFS дает возможность настроить single sign on авторизацию, и юзеры смогут не плодить учетные записи, а заходить в систему с помощью своих аккаунтов в соцсетях. Что не может не сказаться на их душевном равновесии и позитивном настрое на работу :)
4. ADFS отлично подходит для применения в таких сложных систем, как у S7, т.к. предоставляет функционал единого входа к разным веб-приложениям в течение одного сеанса работы.

Автор: eastbanctech

Источник