Предоставьте партнерам доступ к данным с помощью Active Directory Federation Services

Сегодня многие организации изыскивают способы простого и безопасного совместного использования данных и доступа к корпоративной сети доверенных внешних пользователей. В этом им могут помочь реализованные в системе Windows Server 2003 Release 2 (R2) службы Active Directory Federation Services (ADFS). В статье «Объединенная аутентификация с использованием ADFS» (опубликованной в Windows IT Pro/RE № 2 за 2007 г.) я рассказал о службах ADFS и дал определение объединенной аутентификации, которая соединяет неоднородных поставщиков аутентификации и поставщиков ресурсов, чтобы облегчить процессы обмена данными внутри организаций. На этот раз я предлагаю более внимательно присмотреться к компонентам ADFS и проанализировать, как они взаимодействуют друг с другом, а также разобраться в том, что требуется для планирования работы служб ADFS и развертывания этих служб в условиях конкретной организации.

Служба объединения

Прежде чем приступить к рассмотрению службы Federation Service, которая является самым важным компонентом ADFS, хочу сказать несколько слов об используемой в сфере объединенной аутентификации терминологии. Компания может быть поставщиком аутентификации, поставщиком ресурсов или сочетать обе эти роли. Поставщик аутентификации — это организация, которая создает учетные записи и управляет ими. Поставщик ресурсов предоставляет доступ к ресурсам и управляет этим доступом. Поставщиков аутентификации и ресурсов иногда называют островами; данный термин подчеркивает их изоляцию друг от друга. Острова могут находиться в различных организациях, но могут создаваться и в рамках одной компании. Задача средств объединенной аутентификации, таких как ADFS, как раз и состоит в том, чтобы объединять эти острова.

Служба объединения Federation Service — это Web-служба ASP.NET, которую необходимо устанавливать на платформах Windows 2003 R2 Enterprise Edition или Datacenter Edition. Система ADFS предполагает установку службы объединения для каждого поставщика аутентификации или ресурсов, участвующего в федерации. На серверах Windows 2003 R2 Federation Service также должны быть установлены следующие программные средства: Microsoft IIS 6.0, Microsoft .NET Framework 2.0 и ASP.NET. Службу объединения, как и все рассматриваемые в статье компоненты ADFS, можно установить на системе Windows 2003 R2 с помощью мастера Windows Components оснастки Add or Remove Programs панели управления. Системы R2 имеют новую функцию в списке Windows Components, именуемую Active Directory Services. Она включает в себя ADFS, Active Directory Application Mode (ADAM) и Identity Management for UNIX, или Services for UNIX (SFU).

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

  • Проверяет учетные данные пользователей и генерирует аутентификационные файлы-«маяки» ADFS. Federation Service может проверять учетные данные пользователей либо средствами Active Directory (AD), либо средствами ADAM. Аутентификационные «маяки» используются для осуществления однократной процедуры регистрации через Web, Web single sign-on (SSO). Аутентификационные «маяки» удостоверяют, что пользователи прошли проведенную службой Federation Service процедуру аутентификации, и подтверждают, что эти пользователи не обязаны вновь вводить учетные данные всякий раз, когда обращаются к ресурсу партнера по федерации. Каталог AD или ADAM, используемый при установке ADFS, должен находиться либо в системе Windows 2003 Service Pack 1 (SP1) или SP2, либо в системе Windows 2003 R2, либо в Windows 2000 SP4.
  • Генерирует и трансформирует маркеры безопасности ADFS. Маркер безопасности ADFS содержит атрибуты пользователя. В системе ADFS свойства этих атрибутов также именуются заявками. Как будет показано далее, маркеры безопасности и их заявки используются главным образом в целях авторизации. Служба Federation Service может генерировать новые маркеры безопасности или преобразовывать их из одного формата в другой. Для создания и наполнения маркеров безопасности Federation Service извлекает заявки пользователей из каталогов AD или ADAM.
    В процессе преобразования маркеров Federation Service трансформирует заявки, содержащиеся в маркере безопасности, в новый набор заявок, которые затем сохраняются в новом маркере. Цель преобразования заявок состоит в том, чтобы превратить заявку, сформулированную в одной организации, в эквивалентную заявку, определенную в терминах другой организации. К примеру, статус пассажира, часто пользующегося услугами авиакомпании, в одной организации именуется «золотым членством» (gold membership), а в другой организации такого человека называют «привилегированным клиентом» (privileged customer). В этой статье мы еще будем более подробно рассматривать преобразование маркеров службой Federation Service.
  • Управляет политикой доверительных отношений внутри федерации, которые установлены между Federation Service и другими партнерами по федерации. Политика доверительных отношений внутри федерации определяет, какими притязаниями обмениваются друг с другом партнеры по федерации. В заявки могут входить такие идентификаторы пользователей, как адрес электронной почты или основное имя пользователя User Principal Name (UPN), авторизационные данные пользователя, такие как членство в группах, и другие атрибуты пользователя (скажем, номер телефона и почтовый адрес). Управление политикой доверительных отношений внутри федерации, которая реализуется службой Federation Service, осуществляется из оснастки ADFS консоли Microsoft Management Console (MMC), которая показана на экране 1. Эта оснастка устанавливается автоматически в процессе загрузки службы Federation Service.

Экран 1. Консоль управления ADFS

Federation Service Proxy

Входящий в состав ADFS компонент Federation Service Proxy (FSP) выполняет функции пользовательского интерфейса службы Federation Service. Его можно устанавливать отдельно с помощью «мастера» Windows Components приложения Add or Remove Programs панели управления. Кроме того, этот компонент устанавливается автоматически в процессе загрузки службы Federation Service. FSP выступает в качестве посредника между браузерами и службой Federation Service; в результате неинтеллектуальные клиенты браузера, образно говоря, получают «собеседника». Требования при установке FSP такие же, как при установке Federation Service.

Federation Service — это центр обеспечения безопасности, который не должен иметь прямого выхода в распределенную сеть или Internet. Если федеративные пользователи или партнеры подключаются к ресурсам компании из распределенной сети или Internet, следует установить дополнительный компонент FSP в демилитаризованной зоне (DMZ) организации.

FSP выполняет следующие задачи:

  • Обеспечивает интерфейс для обнаружения базового домена пользователей. В системе ADFS базовый домен пользователя — это поставщик учетных записей, в котором определяется учетная запись данного пользователя. Поставщик ресурсов ADFS должен знать базовый домен пользователя, чтобы иметь возможность перенаправить пользователя к соответствующему поставщику учетных записей для проведения аутентификации. FSP включает в себя специальную Web-страницу, которая позволяет вручную выбирать базовый домен пользователя. Процесс обнаружения базовых доменов можно автоматизировать; эта процедура разъясняется в документации ADFS.
  • Собирает учетные данные от клиентов браузеров и передает их в службу Federation Service для проверки.
  • Передает маркеры безопасности и аутентификационные «маяки», созданные службой Federation Service, которая выступает в роли поставщика аутентификации, службе Federation Service, исполняющей роль поставщика ресурсов.
  • Возвращает маркеры безопасности и аутентификационные «маяки», созданные службой Federation Service, клиентам браузеров.

Web-агент ADFS

Web-агент ADFS — это первая точка контакта пользователя ADFS с самими службами. Web-агент обеспечивает интерфейсную логику между инфраструктурой ADFS и приложением для Web. Агент использует сведения, содержащиеся в маркерах безопасности, а также в аутентификационных «маяках», и передает заявки ADFS приложениям для Web. Затем приложения могут использовать эти заявки для принятия решений по авторизации или оказывать услуги по имперсонализации пользователей. В состав агента входит фильтр Internet Server API (ISAPI), который направляет не прошедших процедуру аутентификации пользователей компоненту FSP и в службу Federation Service для прохождения данной процедуры.

Web-агент ADFS должен быть установлен на каждой системе IIS, где существуют оснащенные средствами ADFS приложения. В отличие от Federation Service и FSP, данный агент также может быть установлен на сервере Windows 2003 R2 Standard Edition. В ходе загрузки Web-агента ADFS можно устанавливать также приложения с функциями доступа к заявкам, приложения на базе маркеров Windows NT либо и те и другие. Давайте посмотрим, в чем состоят различия между ними.

Интеграция приложений ADFS

Приложения ADFS на базе маркеров Windows NT поддерживают традиционную модель авторизации Windows, в основе которой лежат идентификаторы безопасности, маркеры доступа, списки управления доступом (ACL) и процесс имперсонализации. Подходящим примером приложения, которое может быть интегрировано в ADFS в качестве приложения на базе маркеров Windows NT, может служить Microsoft SharePoint Portal Server. Для того чтобы подготовить приложения на базе маркеров NT к интеграции в службы ADFS, требуются лишь минимальные изменения конфигурации. Но для создания приложений ADFS с функциями доступа к заявкам необходимо специальное кодирование.

Для приложений на базе маркеров NT Web-агент ADFS извлекает из маркера безопасности ADFS сведения об индивидуальной и/или групповой заявке, сверяет извлеченную информацию с локальной учетной записью AD и запрашивает маркер доступа Windows. Затем Web-приложение использует этот маркер доступа для осуществления авторизации. Надо отметить, что для осуществления процесса имперсонализации, используемого Web-агентом ADFS, и для связанного с ним процесса создания маркера доступа необходимо наличие на стороне Web-сервера (который является поставщиком ресурсов) специальной локальной учетной записи AD.

Имеющие функции доступа к заявкам приложения ADFS напрямую используют заявки, содержащиеся в маркерах безопасности ADFS. В отличие от приложений на базе маркеров NT, приложения с функциями доступа к заявкам не требуют наличия локальной учетной записи AD на стороне поставщика ресурсов. Для создания приложений с функциями доступа к заявкам можно использовать диспетчер Authorization Manager системы Windows 2003 SP1 или SP2, класс IsInRole ASP.NET 2.0, либо API исходных заявок ASP.NET 2.0. Корпорация Microsoft впервые реализовала Authorization Manager в системе Windows 2003 и включила в него изменения, позволяющие работающим с Authorization Manager приложениям использовать заявки, которые содержатся в маркерах безопасности ADFS. Благодаря этим изменениям заявки ADFS можно напрямую ставить в соответствие ролям Authorization Manager.

Обеспечение безопасности на основе заявок

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

Как уже отмечалось выше, заявки являются атрибутами участника системы безопасности, такими как имя администратора, членство в группах, привилегии и функции. Маркеры безопасности, генерируемые службой STS (Security Token Service), которая является частью службы Federation Service, содержат заявки. Чтобы защитить целостность заявок маркера безопасности, служба STS подписывает маркеры безопасности. Службы ADFS поддерживают заявки следующих типов:

  • Заявки на аутентификацию. Маркер безопасности ADFS всегда должен содержать заявку на аутентификацию. Заявка на аутентификацию может включать имя UPN, адрес электронной почты, отформатированный в соответствии с RFC 822, и общее имя common name (CN).
  • Групповые заявки. В них указывается членство пользователя в группе или в роли.
  • Специальные заявки. В них могут содержаться любые другие данные об авторизации или о профиле пользователя, не относящиеся к категории сведений о личности пользователя или его принадлежности к той или иной группе. К специальным заявкам могут относиться, например, идентификационный номер служащего, номер социальной страховки и возраст сотрудника.

Преобразование заявок

В статье «Объединенная аутентификация с использованием ADFS» я разъяснил важность использования общего языка для различных поставщиков аутентификации и ресурсов. Такой общий язык обеспечивается средствами служб ADFS. При этом выполняется процесс, известный как преобразование заявок (он показан на рисунке).

Рисунок. Процесс преобразования заявок в ADFS

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

Внутренние заявки организации, т.е. заявки, которые заполняются данными из репозитария аутентификации (AD или ADAM) на стороне поставщика аутентификации, и заявки, потребляемые приложениями на стороне поставщика ресурсов, именуются также заявками организации. Заявки, возникающие в процессе преобразования заявок на стороне поставщика аутентификации, именуются исходящими заявками. Заявки, получаемые поставщиками ресурсов, — входящими.

Следующие этапы отражают детали процесса, в ходе которого ADFS создает, обменивает и использует заявки в случаях, когда пользователь запрашивает доступ к ресурсу, например к Web-приложению:

  • служба Federation Service поставщика аутентификации ADFS пользователя генерирует заявки организации и заполняет их атрибутами пользовательских объектов AD;
  • служба Federation Service поставщика аутентификации преобразует заявки организации в набор исходящих заявок;
  • исходящие заявки направляются в службу Federation Service поставщика ресурсов;
  • служба Federation Service поставщика ресурсов преобразует входящие заявки в набор заявок организации;
  • оснащенное средствами для взаимодействия с ADFS Web-приложение потребляет заявки организации и использует их для выдачи разрешений пользователю или приложения для этого пользователя.

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

Определять заявки можно в контейнере Claim Definitions, который расположен в оснастке ADFS консоли MMC (Active Directory Federation ServicesFederation ServiceTrust PolicyMy Organization). Для определения преобразований заявок необходимо перейти в раздел Active Directory Federation ServicesFederation ServiceTrust PolicyPartner Organizations. На экране 2 показаны преобразования заявок на стороне поставщика аутентификации (верхняя панель) и на стороне поставщика ресурсов (нижняя панель). В данном примере внутренняя группа, именуемая Purchasing Agent, преобразуется в Purchaser; при этом предполагается, что заявка на стороне поставщика ресурсов становится входящей.

Экран 2. Пример преобразования заявок

Используемая в ADFS модель преобразования заявок является расширяемой. Организация может разработать собственный модуль преобразования заявок, который, к примеру, для осуществления процедуры заполнения заявок соединяется с базой данных Microsoft SQL Server или включает процесс организации потока работ для преобразования заявок.

Более подробные сведения о том, как следует разрабатывать модуль преобразования заявок, можно найти в обновленной для версии Windows 2003 R2 редакции программного комплекта средств разработчика Windows SDK.

Требования сертификатов ADFS X.509

Для защиты данных, которыми обмениваются компоненты ADFS, а также для подписи маркеров безопасности ADFS используются сертификаты X.509. Подписывающие сертификаты передаются по безопасному протоколу Secure MIME (S/MIME). Сертификаты, используемые для безопасной связи, являются клиентскими и серверными сертификатами Secure Sockets Layer (SSL). Следующие каналы связи ADFS должны быть защищены с помощью протокола SSL:

  • каналы связи между FSP и Federation Service требуют клиентский сертификат SSL на FSP и серверный сертификат SSL на Federation Service;
  • каналы связи между клиентом браузера и FSP требуют серверный сертификат SSL на FSP. Если вместо одного из прочих методов аутентификации клиентов IIS (базовая, комбинированная или интегрированная аутентификация Windows) желательно использовать строгий метод аутентификации на базе сертификатов, можно применить к клиенту браузера факультативный сертификат SSL;
  • каналы связи между клиентом браузера и Web-приложением, оснащенным средствами для взаимодействия с ADFS, требуют серверный сертификат SSL на Web-сервере IIS, где размещается способное к взаимодействию с ADFS Web-приложение. Клиентский сертификат SSL можно задействовать и для клиента браузера.

Автоматическое создание этих сертификатов средствами ADFS в ходе процесса установки ADFS не предусмотрено. Сертификаты нужно запрашивать вручную до установки ADFS. Их можно запрашивать у коммерческих центров сертификации Certification Authority (CA), таких как VeriSign, или использовать внутренние центры сертификации, например внутренний CA Windows 2003 или Windows 2000. Кроме того, можно генерировать самоподписанные сертификаты с помощью selfssl.

Все три метода получения сертификатов имеют свои достоинства и недостатки. Внешние федеративные партнеры компании будут автоматически доверять сертификатам коммерческих CA. Но такое отношение не будет распространяться на сертификаты, которые генерируются средствами внутреннего CA или с помощью инструмента selfssl. Пользователи браузеров должны непосредственно доверять внутреннему CA компании или самоподписанному сертификату. Использование внутреннего CA обеспечивает максимальный контроль и гибкость в деле выпуска сертификатов. С другой стороны, использование внутреннего CA влечет за собой дополнительные расходы на управление и обслуживание.

Вы можете настроить ADFS на сертификат подписи маркера в процессе установки ADFS. Клиентские и серверные сертификаты SSL должны настраиваться вручную. Более подробные сведения о настройке приведены в документации по ADFS и IIS 6.0, а также в статье Microsoft «Certificate requirements for federation servers».

Какие требования предъявляет ADFS

Необходимо выделить время для тщательного планирования и проектирования федеративной инфраструктуры на базе ADFS, включая выбор поставщика сертификатов, выбор подходящих хранилищ для учетных записей (AD или ADAM), а также определения и преобразования заявок. Возможно, придется вносить изменения в код приложений (это зависит от приложений, которые предполагается оснастить инструментами для взаимодействия с ADFS). Силы и средства, вложенные сегодня в планирование и проектирование инфраструктуры ADFS, в будущем принесут неоценимые преимущества как самой организации, так и ее федеративным партнерам.

Жан де Клерк (jan.declercq@hp.com) — член Secirity Office корпорации HP. Специализируется на проблемах управления идентичностью и вопросах безопасности продуктов Microsoft