Adfs авторизация что это
Перейти к содержимому

Adfs авторизация что это

Что такое ADFS (службы федерации Active Directory)?

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

Что такое ADFS для человека не из Microsoft?

Как это отличается от таких вещей, как LDAP?

Как это работает? Какого рода информация будет включена в типичный запрос к серверу ADFS? Он предназначен как для аутентификации, так и для авторизации?

Доступны ли серверы ADFS из Интернета (тогда как корпоративные контроллеры домена AD не будут)?

Я попытался прочитать некоторые из документов Technet, но в них много разговоров с Microsoft, что не очень полезно.

Википедия лучше (см. Ниже), но, возможно, некоторые из сообщества ServerFault могут заполнить некоторые пробелы.

  1. Пользователь входит в свой локальный компьютер (как обычно, когда он начинает работать утром)
  2. Пользователю необходимо получить информацию на веб-сайте экстрасети компании-партнера, например, для получения информации о ценах или сведениях о продукте.
  3. Пользователь переходит на сайт экстрасети компании-партнера — например, http://example.com.
  4. Веб-сайт партнера теперь не требует ввода пароля — вместо этого учетные данные пользователя передаются на сайт экстрасети партнера с помощью AD FS.
  5. Теперь пользователь вошел на сайт партнера и может взаимодействовать с сайтом, вошедшим в систему.

Что такое ADFS для человека не из Microsoft?

ADFS — это решение Microsoft для единого входа и аутентификации через Интернет.

Он используется главным образом для предоставления единого набора учетных данных, которые могут получить доступ к множеству сайтов, не обязательно размещенных в одном домене.

Как это отличается от таких вещей, как LDAP?

LDAP:

  • Связь через TCP / UDP через порт 389 (или порт 636 для LDAPS)
  • Содержит команды для поиска / извлечения / добавления / удаления / изменения пользователей, профилей и других записей каталога
  • Может не быть выполнено непосредственно с помощью веб — браузера, однако аутентификация HTTP может быть переведена на LDAP , используя такие вещи , как в Apache mod_authnz_ldap .
  • При использовании для аутентификации на стороннем веб-сайте требует, чтобы имя пользователя и пароль были предоставлены третьей стороне, что не идеально для безопасности.
  • Это более открытый стандарт и имеет множество реализаций Linux.

ADFS:

  • Лучше разработан для Интернета, поскольку он общается по стандартному HTTPS
  • Следует более безопасному процессу, аналогичному (но не точному) OAuth, где исходное имя пользователя / пароль предоставляются непосредственно серверу ADFS организации (или прокси-серверу, но не третьей стороне), который, если он действителен, возвращает уникальный токен, который может быть используется для доступа к стороннему веб-сайту.
  • Хотя он использует некоторые открытые стандарты (HTTPS, SAML и т. Д.), Он специфичен для Microsoft и требует информационных служб Интернета (IIS), которые работают только на серверах Windows.

Смотрите также этот ответ по этому вопросу.

Как это работает? Какого рода информация будет включена в типичный запрос к серверу ADFS? Он предназначен как для аутентификации, так и для авторизации?

Он работает, имея один сайт (сайт A), на котором размещены прокси-серверы ADFS / ADFS, который имеет доступ к учетным данным (обычно путем связи с контроллером домена Active Directory). Затем ему предоставляется доверие между другими сайтами (сайтами B & C), которые требуют аутентификации через ADFS.

Когда пользователь пытается получить доступ к сайту B в своем браузере, сайт перенаправляет пользователя на веб-сайт ADFS-прокси (сайт A), который запрашивает их имя пользователя и пароль, аутентифицирует их, возвращает набор файлов cookie для их запоминания и перенаправляет их вернуться на сайт B вместе с токеном доступа.

Если пользователь затем попытается посетить сайт C, он также будет перенаправлен на сайт A для проверки подлинности с веб-сайта ADFS-прокси. Если правильные файлы cookie существуют, пользователю не нужно будет снова вводить свой пароль, но он сразу же перенаправляется обратно на сайт C с токеном.

ADFS может быть настроен с конкретными утверждениями (или разрешениями) для пользователя в целях авторизации. Так что он может выполнять обе роли. (Обратите внимание на разницу между аутентификацией и авторизацией .)

Некоторые люди предпочитают не использовать его для авторизации, а вместо этого сохраняют управление разрешениями на стороннем веб-сайте. Очевидным недостатком является то, что оба сайта A & B должны отслеживать учетные записи пользователей, в то время как в сценарии, где ADFS обрабатывает оба, только ADFS должна знать о пользователях.

Доступны ли серверы ADFS из Интернета (тогда как корпоративные контроллеры домена AD не будут)?

Да почти всегда ADFS основана на том, что она будет в основном использоваться для аутентификации на сайте. И построен вокруг IIS.

Сайт ADFS-прокси обычно доступен из Интернета. Однако сама ADFS нет. ADFS обычно является отдельным сервером от ADFS-прокси.

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

Статья будет интересна всем, кто хочет узнать значение страшного термина «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-сервис, с помощью которого будем эти данные в нашем новом приложении получать.

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

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

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

a. Устанавливаем доверенный ADFS-сервер и сертификат через powershell скрипт

b. Меняем настройки аутентификации приложения

c. Мигрируем юзеров для того чтобы все разрешения стали через Claims (опять через powershell скрипт)

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

Боевое переключение делали в субботу, так как время только на экспорт/импорт уходило около 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:

Заключение

Почему миграция программы лояльности на ADFS оказалась важна для заказчика?

ADFS 2.0Применение Active Directory Federation Services 2.0 в решениях для идентификации

Как разработчик вы наверняка хотя бы слышали о Windows Identity Foundation (WIF), которая ранее называлась Geneva Framework и которая предоставляет мощный API для поддержки заявок в приложениях и создания собственных сервисов Security Token Service (STS). Менее известна служба Active Directory Federation Services версии 2.0 (ADFS 2.0), изначально проходившая под кодовым названием «Geneva Server»; это корпоративное решение для объединения в федерацию и поддержки единого входа (single sign-on, SSO). ADFS 2.0 является эволюционным развитием ADFS 1.0 и поддерживает варианты с активной (WS-Trust) и пассивной федерацией (WS-Federation и SAML 2.0).

Я начну с обзора ADFS 2.0, а потом расскажу, как разработчики могут использовать ADFS 2.0 в своих решениях для идентификации. Основное внимание я уделю функциональности выдачи маркеров в ADFS 2.0, основанной на второй бета-версии. Как видно из рис. 1, выдача маркеров — не более чем малая часть ADFS 2.0, но она представляет особый интерес для .NET-разработчиков, переходящих к поддержке федеративной идентификации. С архитектурной точки зрения, ADFS 2.0 опирается на WIF и Windows Communication Foundation (WCF), поэтому, если вы хорошо знаете эти технологии, то без проблем освоите ADFS 2.0.


Рис. 1 Архитектура ADFS 2.0

Обзор ADFS 2.0

На высоком уровне ADFS 2.0 можно считать набором сервисов, показанных на рис. 2.

Центральное место в ADFS 2.0 занимает сервис маркеров защиты (Security Token Service, STS), который использует Active Directory как хранилище идентификаций, а также Lightweight Directory Access Protocol (LDAP), SQL или собственную базу данных как хранилище атрибутов. STS в ADFS 2.0 может выдавать маркеры защиты по различным протоколам, в том числе WS-Trust, WS-Federation и Security Assertion Markup Language (SAML) 2.0. ADFS 2.0 STS также поддерживает форматы маркеров SAML 1.1 и SAML 2.0.

ADFS 2.0 спроектирована с четким разделением между сетевыми протоколами и внутренним механизмом выдачи маркеров. Различные сетевые протоколы преобразуются в стандартизованную объектную модель на входе в систему, и на внутреннем уровне ADFS 2.0 использует одну и ту же объектную модель для каждого протокола. Это разделение делает возможным модель расширения ADFS 2.0, независимую от внутреннего устройства разных сетевых протоколов. Более подробные сведения о расширяемости ADFS 2.0 будут изложены в ADFS 2.0 SDK перед выпуском RTM-версии этой службы.


Рис. 2 Компоненты ADFS 2.0

ADFS 2.0 как провайдер идентификаций

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

Настройка RP

Настройка новой RP через ADFS 2.0 осуществляется довольно легко. Вы можете воспользоваться мастером Add Relying Party через режим Policy в консоли управления ADFS 2.0. В этом мастере вы или системный администратор должны указать подходящие источники данных на странице Select Data Source мастера (рис. 3).


Рис. 3 Страница Select Data Source в мастере Add Relying Party

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

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

А вообще очень поучительно пройти все этапы после выбора переключателя Enter relying party configuration manually просто для того, чтобы представлять, что нужно для настройки новой RP. На следующих нескольких страницах мастера вам предложат выбрать профиль — щелкните ADFS 2.0 Profile, если вы хотите поддерживать клиенты как на основе браузеров, так и на основе WCF, либо ADFS 1.x Profile, если вам нужна совместимость с ADFS 1.x и не требуется поддержка активных клиентов (WCF, CardSpace).Настройте сертификат для шифрования маркера, чтобы только RP с соответствующим закрытым ключом могла расшифровать и использовать выданный маркер.Затем укажите идентификатор, который будет идентифицировать эту RP во всех запросах на выдачу маркера.

После мастера Add Relying Party открывается Rules Editor. В этой утилите вы настраиваете правила выдачи и преобразования. На рис. 4 показан Rules Editor, сконфигурированный на выдачу маркера с одной заявкой, значение которой будет извлекаться из основного хранилища атрибутов. Заметьте, что атрибут displayName сопоставлен с заявкой Given Name. В ADFS 2.0 введен новый язык, специфичный для предметной области, который позволяет определять простые правила выдачи маркеров и преобразования заявок. Каждое правило состоит из условия и действия и заканчивается — как в [c] =>> a; — точкой с запятой. Логика преобразования — это серия правил, последовательно выполняемых в процессе выпуска маркера. Для определения этих правил на вкладке Simple View предоставляется специальный UI (рис. 4). Вкладка Advanced View позволяет создавать правила, напрямую используя язык, специфичный для предметной области.


Рис.4 Средство Rules Editor

Этот пример иллюстрирует, насколько легко сконфигурировать RP в ADFS 2.0. К моменту, когда ADFS 2.0 принимает запрос на выдачу маркера, она извлекает идентификатор из данных сетевого протокола (например, элемент appliesTo в случае WS-Trust) и использует его для поиска целевой RP. Найдя таковую, ADFS 2.0 использует параметры, заданные в мастере, для создания логики выдачи маркера.

Теперь рассмотрим, как с помощью WCF запросить маркер для данной RP от ADFS 2.0.

Запрос маркера с применением WCF

Существует два варианта взаимодействия с ADFS 2.0 STS при использовании WCF:

  • явно запрашивать маркер, выступая в роли клиента WS-Trust;
  • настраивать WCF-клиент так, чтобы инфраструктура неявно запрашивала маркер в процессе вызова.

В первом варианте вы используете класс WSTrustClient, который предоставляет простой API для запроса маркеров напрямую от STS по протоколу WS-Trust:

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

В тестовой среде, где вы обычно имеете доступ к закрытому ключу RP, можно использовать следующий код для извлечения SAML-утверждения (assertion) из возвращаемого маркера:

SAML-маркер содержит только заявки, настроенные для данной конкретной RP. Вернитесь к рис. 4, где показано, как маркер для этой RP был настроен так, чтобы возвращать единственный атрибут. Вы можете отредактировать конфигурацию RP и включить в выдаваемый маркер больше заявок; при этом все они должны быть отражены здесь. Кроме того, можно использовать язык политики заявок, чтобы напрямую определить логику преобразований и фильтрации.

Как WSTrustClient API, так и новые привязки WSTrust являются частью WIF, поэтому, чтобы предыдущий код мог работать, на клиенте нужно установить WIF. Вы, конечно, можете напрямую использовать WCF API для явного получения маркера, но WIF проще и удобнее.

В коде на рис. 5 IssuedSecurityTokenProvider является WCF-эквивалентом WSTrustClient и обычно используется привязкой wsFederationBinding при запросе маркеров в ваших интересах. Поскольку это открытый API, вы можете свободно применять его в своем коде, если вам нужен доступ к необработанным маркерам. Ну и CustomBinding — эквивалент WindowsWSTrustBinding.

Рис. 5 Доступ к необработанному маркеру через IssuedSecurityTokenProvider

В неявном варианте можно использовать стандартную привязку wsFederationHttpBinding, и в этом случае инфраструктура WCF прозрачно получает маркер и посылает его сервису при вызове. Всякий раз, когда вы создаете новый WCF-прокси и применяете его для вызова сервиса, инфраструктура получает за вас новый маркер. Очевидно, что в некоторых ситуациях это перехлест. Код на рис. 6 настраивает фиктивный EmployeeService для запроса маркеров от ADFS 2.0.

Рис. 6 Неявное получение маркера через wsFederationHttpBinding

Связь концепций ADFS 2.0 с WCF

Основная задача ADFS 2.0 — выдавать маркеры аутентифицированным пользователям. Аутентификация может выполняться по разным механизмам (например, средствами Windows). Вы можете увидеть все поддерживаемые механизмы аутентификации, выбрав узел Endpoints в консоли управления.

Просматривая названия столбцов в Endpoints вы заметите две знакомые концепции безопасности WCF.

  • Authentication Type в ADFS 2.0 эквивалентен clientCredentialType в WCF.
  • Для Security Mode можно выбрать значения Transport, Message или Mixed. Mixed в ADFS 2.0 эквивалентен TransportWithMessageCredentials в WCF.

Различные комбинации значений этих двух параметров доступны через разные конечные точки, и вы выбираете конкретную конечную точку, исходя из своих требований к аутентификации. Например, если вам нужна аутентификация с использованием имени и пароля, вы можете выбрать конечную точку Clear Password.

В случае ADFS 2.0 STS, спроецировав эти концепции обратно на Address, Binding и Contract (ABC) в WCF, вы получите следующие эквиваленты:

  • Address = базовый адрес ADFS 2.0 + URL Path конечной точки;
  • Binding = Security Mode конечной точки + Authentication Type;
  • Contract = стандартный протокол WS-Trust.

Объединение ADFS 2.0 в федерацию с другим STS

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

Настройка в качестве провайдера идентификаций

Настройка нового доверяемого провайдера идентификаций в ADFS 2.0 аналогична настройке новой RP. Используемый при этом мастер Add Identity Provider выглядит и работает во многом похоже на мастер Add Relying Party (вернитесь к рис. 3).

Чтобы попасть на страницу Configure Identifier, вновь выберите вариант настройки вручную (как это делалось на рис. 3) и на странице Choose Profile укажите ADFS 2.0 Profile. На странице Configure URL оставьте настройки, предлагаемые по умолчанию. Затем выберите идентификатор и сертификат открытого ключа для своего провайдера идентификаций и нажмите кнопку Finish в мастере, чтобы зарегистрировать новый провайдер идентификаций.

Запрос маркера с применением WCF

После регистрации дополнительного провайдера идентификаций в ADFS 2.0 логическая архитектура выглядит примерно как конфигурация, показанная на рис. 7.


Рис. 7 Архитектура ADFS 2.0 с дополнительным провайдером идентификаций

Код на рис. 8 позволяет явно получать маркер, что дает возможность локально кешировать его и передавать сервису по мере необходимости.

Рис. 8 Явное получение маркера через IssuedTokenWSTrustBinding

IssuedTokenWSTrustBinding очень похожа на wsFederationHttpBinding в том плане, что она скрывает все сложности, связанные с промежуточными маркерами, прозрачно взаимодействуя с IP-STS для получения промежуточного маркера, который потом посылается R-STS в качестве маркера аутентификации.

Код на рис. 9 использует wsFederationHttpBinding, чтобы WCF-клиент мог неявно получить маркер в процессе вызова сервиса.

Заметьте, что я использую customBinding при взаимодействии с конечной точкой /IssuedTokenMixedSymmetricBasic256. Стандартная wsFederationHttpBinding здесь не работает, потому что она пытается установить защищенный сеанс, несовместимый с данной конечной точкой ADFS 2.0. Для объединения WCF-клиентов в федерацию с ADFS 2.0 нужно использовать либо customBinding, либо одну из новых привязок на основе WSTrust, поставляемых с WIF.

Рис. 9 Неявное получение маркера через wsFederationHttpBinding

ADFS 2.0 и клиенты, выполняемые в браузере

ADFS 2.0 полностью поддерживает единый вход через Web (WebSSO) и объединение в федерацию с применением протоколов WS-Federation или SAML 2.0.

Концептуально WS-Federation и протокол SAML похожи, даже несмотря на то, что они имеют разные форматы. Сетевой формат WS-Federation тесно связан с протоколом WS-Trust, поэтому он является логичным выбором, когда вы обслуживаете как активные, так и пассивные (выполняемые в браузере) клиенты. Протокол SAML обладает более широкой совместимостью. ADFS 2.0 полностью поддерживает оба протокола. Правильнее использовать один протокол (например, WS-Federation) в рамках ваших границ безопасности и применять ADFS 2.0 как концентратор-посредник различных протоколов для входящих и исходящих SSO-запросов.

Рассмотрим пример. Допустим, у вас есть простое приложение ASP.NET, функциональность которого доступна только аутентифицированным пользователям. Это автономное приложение, логика аутентификации реализована внутри него, поэтому взаимодействие с приложением потребует выполнения операций, показанных на рис. 10.


Рис.10 Прямая аутентификация в простом приложении ASP.NET

Здесь реализованы обычные механизмы аутентификации ASP.NET, например на основе форм. Наша цель — отделить функциональность аутентификации от этого приложения и задействовать ADFS 2.0.

В системе с ADFS 2.0, приведенной на рис. 11, приложение становится доверяющей стороной в ADFS 2.0 и поэтому доверяет маркерам, выдаваемым ADFS 2.0. Приложение использует WIF для выполнения всей черновой работы, связанной с разбором маркеров, извлечением заявок и т. д. Информация об идентификации предоставляется приложению через стандартные абстракции IIdentity/IPrincipal.

Распределенная аутентификация в ADFS 2.0 гораздо гибче прямой аутентификации и дает следующие основные преимущества.

  • Аутентификация выносится из приложения, поэтому ее механизм можно изменять, не влияя на само приложение.
  • Благодаря гибкости модели на основе заявок приложение может получать всю необходимую информацию как часть маркера, а не из множества разных источников.

Во второй бета-версии WIF введены новые шаблоны проектов, которые упрощают выделение логики аутентификации из приложений в STS. На момент написания статьи такие шаблоны были доступны только в C#.


Рис.11 Распределенная аутентификация в ADFS 2.0

Выделение логики аутентификации

Для выделения этой логики из приложения используйте диалоговое окно New Web Site в Microsoft Visual Studio. Выберите шаблон Claims-aware Web Site для создания стандартного веб-сайта ASP.NET с уже настроенными параметрами WIF.

Чтобы запустить мастер Federation Utility (рис. 12), щелкните правой кнопкой мыши узел Web Site в Solution Explorer и выберите Modify STS Reference из меню.


Рис.12 Federation Utility

В данном примере мы выберем параметр Use an existing STS и укажем ADFS 2.0 в качестве STS. Мастеру потребуется URL документа метаданных для автоматического создания всех необходимых конфигураций. URL документа метаданных доступен как конечная точка в ADFS 2.0.

Метаданные федерации содержат важную информацию, в том числе сертификат подписи STS, предлагаемые заявки и URL, по которому осуществляется выдача маркеров. Стандартизованный формат этой информации дает возможность автоматизировать установление доверительных отношений между STS и доверяющими сторонами.

На странице Summary мастера дается сводный список изменений, которые будут внесены в файл web.config.

Мастер Federation Utility настраивает WIF для вашего веб-сайта, чтобы обеспечить следующую функциональность.

  • Все неаутентифицированные запросы будут перенаправляться в ADFS 2.0.
  • Любой запрос, содержащий действительный маркер, будет обработан, а информация об идентификации будет представлена приложению в виде ClaimsIdentity/ClaimsPrincipal. Приложение будет по-прежнему обращаться к этой информации с использованием стандартных абстракций IPrincipal/IIdentity независимо от ее источника.

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

  • адрес, по которому следует отправить маркер;
  • протокол (SAML или WS-Federation), по которому будет передан маркер.

Вы можете добавить к RP пассивную конечную точку на вкладке Endpoints диалогового окна Test RP Properties. Например, если вы выбираете WS-Federation в качестве Endpoint Type, то ADFS 2.0 будет возвращать маркеры RP по протоколу WS-Federation. А уже внутри RP инфраструктура WIF, полностью поддерживающая протокол WS-Federation, будет обрабатывать эти маркеры.

Теперь, когда вы попытаетесь перейти к приложению, вы будете автоматически переадресованы в ADFS 2.0 для аутентификации, где сможете выбрать метод аутентификации: Windows Integrated Authentication, Certificate Authentication или Username/Password Form.

После успешной проверки подлинности вы (вместе с маркером, выданным ADFS 2.0) будете перенаправлены обратно в приложение. WIF обработает этот маркер и создаст конечную идентификацию (в виде заявок), доступную приложению через стандартные механизмы ASP.NET (например, Page.User).

Федерация на основе браузера

Базовый сценарий внешней аутентификации можно расширить в федеративный, создав дополнительный доверяемый провайдер идентификаций. Параметры провайдера идентификаций показываются в процессе аутентификации.

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

Мощный инструмент

Как вы видели в этой статье, ADFS 2.0 STS предоставляет простое готовое решение для поддержки заявок в ваших WCF-сервисах и приложениях на основе браузеров. Сам STS является не более чем малой частью ADFS 2.0, которая также включает систему обеспечения CardSpace, механизм преобразований на основе правил, инфраструктуру автоматизированного управления доверительными отношениями, сервисы управления и конфигурирования вместе с соответствующими средствами. В сочетании с WIF служба ADFS 2.0 становится мощным инструментом для программирования решений в области идентификации на платформе Windows.

Добавить комментарий

Ваш адрес email не будет опубликован.