Pull to refresh
0
True Engineering
Лаборатория технологических инноваций

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

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

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

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

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

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

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



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

Миграция на ADFS

Программа лояльности является частью сложного решения на базе 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@company
    После этого все заработало в целом. Потом еще долго тренировались локально и на тестовых серверах.


Боевое переключение и проблемы

Боевое переключение делали в субботу, так как время только на экспорт/импорт уходило около 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. ADFS дает возможность авторизоваться на портале с помощью дружелюбного логина-пароля вместо устрашающей стандартной Windows Authentication формы. Также, если пользователь забыл пароль, система любезно его подскажет, не нужно будет разыскивать админа и доказывать ему, что ты не верблюд.
  2. Такой вход можно брендировать корпоративными цветами и символикой и подогнать под единые корпоративные визуальные стандарты.
  3. ADFS дает возможность настроить single sign on авторизацию, и юзеры смогут не плодить учетные записи, а заходить в систему с помощью своих аккаунтов в соцсетях. Что не может не сказаться на их душевном равновесии и позитивном настрое на работу :)
  4. ADFS отлично подходит для применения в таких сложных систем, как нашего заказчика, т.к. предоставляет функционал единого входа к разным веб-приложениям в течение одного сеанса работы.
Tags:
Hubs:
+3
Comments 7
Comments Comments 7

Articles

Information

Website
www.trueengineering.ru
Registered
Founded
Employees
101–200 employees
Location
Россия