Многие компании заинтересованы в возможности обмениваться данными с доверенными внешними пользователями через Web. Провайдерам и клиентам удобно обращаться к ресурсам с использованием собственных учетных записей, не создавая учетных записей в чужой системе. Однако необходимо, чтобы доступ получали только проверенные пользователи. Существует несколько решений, с помощью которых можно выполнить по крайней мере некоторые из этих требований, в частности объединения аутентификации. В выпущенной в конце 2005 г. операционной системе Windows Server 2003 Release 2 (R2) есть подходящее решение — службы ADFS (Active Directory Federation Services).
Объединение аутентификации — сложная технология, компоненты и терминология которой знакомы не всем администраторам. В данной статье дается краткое описание способов ее применения. Затем рассматриваются службы ADFS и приводится простой пример функционирования ADFS. В одной из следующих статей будут более подробно описаны компоненты ADFS, принципы их действия и порядок установки.
Задача
Цель объединения аутентификации — упростить обмен информацией с проверенными внешними пользователями компаний. Такие пользователи могут быть компаниями партнерами или потребителями. Например, производственная компания может предоставить провайдерам доступ к своей базе данных контроля поставок, а аналитическая компания — открыть репозитарий публикаций для компаний-клиентов. Ключевое требование — защита данных и доступ к ним только проверенных пользователей. Два типичных решения, которые при этом применяются, — системы управления доступом в Web и брокеры аутентификации. Объединение аутентификации — третий и, возможно, оптимальный вариант.
Чтобы построить систему управления доступом в Web, компании обычно применяют коммерческие программные пакеты. Широко известные примеры — eTrust SiteMinder компании CA и Oracle Access Manager. Классические системы управления доступом в Web работают с обращениями к ресурсам компании, определяя индивидуальные учетные записи для внешних пользователей. Этот подход не всегда удачно масштабируется, может привести к увеличению нагрузки на администраторов и неудобен для внешних пользователей. Последний недостаток проявляется особенно остро, если пользователям приходится работать с системами управления доступом в Web нескольких компаний.
Более удачный способ — предоставить пользователям единственную учетную запись для доступа к ресурсам в разных компаниях. Такой подход применяется в другой категории решений — брокеров аутентификации. Широко известный пример брокера аутентификации Microsoft — Windows Live ID (старое название Microsoft Passport). Брокеры аутентификации — не идеальное решение. Основная проблема заключается в нежелании доверять управление своими учетными записями внешнему управляющему. Центральный репозитарий для хранения учетных записей становится главной мишенью атаки и единой точкой отказа.
Объединение аутентификации — третье решение проблемы доступа к данным, и ему не свойственны недостатки других подходов. Объединение аутентификации обеспечивает единый вход (SSO) для пользователей и позволяет компаниям контролировать собственные учетные записи. Кроме того, при объединении аутентификации не возникает центральных точек атаки или отказа. С другой стороны, в текущих решениях с объединением аутентификации отсутствуют некоторые возможности, которые есть, например, в решениях управления доступом через Web, такие как простая интеграция приложений и мощные функции аудита и отчетов.
Принципы объединения аутентификации
Объединение аутентификации (управление объединенной аутентификацией) представляет собой связывание различных провайдеров средств аутентификации и ресурсов. Компания может быть провайдером аутентификации, провайдером ресурсов или выполнять обе эти роли. Провайдер ресурсов предоставляет и управляет доступом к таким ресурсам, как базы данных и файлы. Большинство компаний комбинируют эти функции: они предоставляют ресурсы компаниям-партнерам и управляют учетными записями собственных сотрудников.
В контексте объединения аутентификации провайдеры аутентификации и ресурсов иногда называются «островами» (island); этот термин подчеркивает их изолированность друг от друга. «Острова» существуют между компаниями, но могут быть и внутри одной организации. Распространенное заблуждение заключается в том, что объединение аутентификации относится только к организации обмена и защите данных между компаниями. В компаниях часто имеются внутренние «острова», созданные в целях безопасности или по политическим соображениям. В таких случаях объединение аутентификации тоже может быть эффективным.
Связывание различных островов превращает объединение в федерацию в интересную технологическую задачу. Обычно островам компании присущи свои особенности и способы решения задач. В них применяются собственные стандарты именования учетных записей и механизмы проверки аутентификации (проверка подлинности) и управления доступом к ресурсам (авторизация). Стандарты объединения обеспечивают общий язык для представления данных об учетных записях, проверки подлинности и авторизации в формате, понятном для различных провайдеров средств аутентификации и ресурсов, а также для обмена этой информацией между партнерами по федерации.
На сегодня существует три основных набора стандартов объединения, именуемых потоками. У каждого потока есть свои сторонники; Microsoft, IBM и VeriSign отдают предпочтение набору спецификаций Web Services-Federation (WS-Federation). Во врезке «Стандарты объединения аутентификации» кратко описаны WS-Federation и соперничающие потоки. Компаниям, которые намерены организовать федерацию, предпочтительно использовать один стандарт объединения. Но это не обязательное условие: некоторые решения (такие, как HP OpenView Select Access и IBM Tivoli Federated Identity Manager) совместимы с различными стандартами объединения или преобразуют форматы различных стандартов.
В спецификацию WS-Federation входят два федеративных профиля: один объединяет пассивных клиентов (профиль пассивного запросчика), другой — активных клиентов (профиль активного запросчика). Пассивные клиенты — браузеры, которые просто поддерживают протокол HTTP и защиту на уровне гнезд (SSL), чтобы обезопасить HTTP-трафик. Пассивный клиент «не знает», что он объединен в федерации.
В действиях активного клиента учитываются требования протоколов объединения; он более гибкий, мощный и безопасный, чем пассивный клиент. Активные клиенты изначально совместимы с протоколом Simple Object Access Protocol (SOAP).
Сейчас Microsoft ADFS строит маркеры, совместимые с Security Assertion Markup Language (SAML) 1.1, и поддерживает пассивных, но не активных клиентов WS-Federation.
Архитектура ADFS
ADFS задействует другие строительные блоки управления удостоверениями Microsoft, такие как Active Directory (AD) и Active Directory Application Mode (ADAM), и тесно интегрируется с Microsoft IIS. На рис. 1 показаны основные компоненты простого экземпляра ADFS: серверы федерации, на которых функционирует компонент ADFS Federation Service; агент ADFS Web Agent и репозитарий AD или ADAM. На рис. 1 инфраструктура ADFS позволяет пользователям браузера из провайдера аутентификации обращаться к Web-приложению на сервере IIS, расположенном в провайдере ресурсов. Пользователи браузера задействуют учетную запись AD, определенную провайдером аутентификации.
- Сервер федерации на провайдере аутентификации использует AD или ADAM для проверки подлинности пользователей. Если проверка пользователя выполнена успешно, то сервер федерации провайдера аутентификации генерирует cookie, файлы-маяки аутентификации и маркеры безопасности. Эти маркеры безопасности содержат запросы о пользователе. Примеры типичной заявки — имя пользователя, членство в группе и адрес электронной почты. Сервер федерации провайдера аутентификации подписывает маркеры безопасности, чтобы защитить их от незаконных изменений.
- Сервер федерации на провайдере ресурсов проверяет cookie-файлы аутентификации и маркеры безопасности, полученные от пользователей, которые пытаются обратиться к его Web-приложению. Сервер федерации также преобразует cookie-файлы и маркеры в формат, приемлемый для Web-приложения, и передает их в Web-приложение.
Агенты Web ADFS Agent позволяют Web-приложениям на базе IIS участвовать в федерации ADFS. Агенты Web ADFS Agent могут взаимодействовать с серверами федерации и обрабатывать cookie-файлы аутентификации и маркеры безопасности ADFS. Чтобы превратить существующее Web-приложение в ADFS-совместимое, иногда требуется внести изменения в исходный текст. В основном изменения связаны с возможностью принимать заявки в маркерах безопасности ADFS (т. е. с их помощью проверять пользователей). Чтобы подготовить Web-приложение для ADFS, можно задействовать механизм Authorization Manager (настройка производится из оснастки Authorization Manager консоли Microsoft Management Console) либо один из интерфейсов ASP.NET API (IsInRole или чистые заявки). Приложение Microsoft SharePoint Portal Server готово для работы с ADFS без изменений в исходном тексте.
Функционирование ADFS
- Шаг 1. Пользователь браузера, определенный в провайдере аутентификации, пытается обратиться к приложению Web-сервера, размещенному в провайдере ресурсов.
- Шаг 2. Агент Web ADFS Agent обнаруживает, что пользователь не прошел проверку подлинности в ADFS, и отсылает его в сервер федерации провайдера ресурсов.
- Шаг 3. На данном этапе, известном как обнаружение домашней области, пользователь браузера предоставляет информацию о своем домене серверу федерации провайдера ресурсов. Домашний домен — место, в котором определено и обслуживается удостоверение пользователя, иными словами, провайдер удостоверения пользователя. При первом подключении пользователя к Web-приложению пользователь предоставляет такие сведения, как имя провайдера удостоверения или адрес электронной почты. При последующих запросах сервер федерации провайдера ресурсов отыскивает эти данные в cookie-файле, переданном пользователем.
- Шаг 4. В зависимости от данных, переданных в процессе обнаружения домашней области, сервер федерации провайдера ресурсов перенаправляет браузер пользователя на сервер федерации провайдера удостоверения для проверки подлинности.
- Шаг 5. Пользователь браузера проходит проверку подлинности в сервере федерации своего провайдера аутентификации с использованием своей учетной записи AD и соответствующих учетных данных.
- Шаг 6. Сервер федерации провайдера аутентификации проверяет учетные данные пользователя в AD. Если проверка завершается успешно, то сервер федерации провайдера аутентификации генерирует cookie-файл аутентификации и маркер безопасности ADFS.
- Шаг 7. Сервер федерации провайдера аутентификации перенаправляет браузер пользователя вместе с маркером безопасности и cookie-файлом аутентификации на сервер федерации провайдера аутентификации.
- Шаг 8. Сервер федерации провайдера ресурсов преобразует заявку в маркере безопасности в набор заявок, распознаваемых Web-приложением, размещенным в провайдере ресурсов, и вставляет их в новый маркер безопасности. Этот процесс известен как преобразование заявки. Сервер федерации также генерирует cookie-файл аутентификации и перенаправляет пользователя браузера (вместе с новым маркером безопасности и cookie-файлом аутентификации) в агент Web ADFS Agent Web-приложения. Web ADFS Agent проверяет cookie-файл аутентификации, извлекает заявку из маркера безопасности и передает ее в Web-приложение.
- Шаг 9. Web-приложение интерпретирует заявки в ходе проверки подлинности и передает соответствующие Web-материалы в браузер пользователя.
ADFS для единой процедуры регистрации в Web
ADFS — решение для единого Web-входа, с помощью которого компании могут расширить область применения своих приложений на базе Web и AD на другие компании. Пользователям Windows 2003, нуждающимся в едином Web-входе, следует обратить внимание на ADFS. Конечно, ADFS не хватает некоторых передовых возможностей чистых Web-решений, таких как CA eTrust SiteMinder или HP OpenView Select Access. А для разработки и интеграции Web-приложений может потребоваться больше времени, но это бесплатный компонент Windows 2003 R2, тесно интегрированный с Web-сервером IIS и SharePoint Portal Server компании Microsoft.
Для успешного применения ADFS Web-приложения AD и IIS должны взаимодействовать с провайдерами ресурсов и аутентификации, отличными от Microsoft. Несколько провайдеров программ уже присоединились к ADFS и выпустили или обещают выпустить ADFS-совместимые решения, которые расширяют область действия ADFS на среды, базирующиеся не на продуктах Microsoft. В качестве примера можно привести решения компаний Centrify и Quest Software, которые позволяют распространить единую Web-регистрацию ADFS на Web-серверы не на основе IIS, такие как Apache Tomcat и IBM WebSphere. Компания Microsoft продемонстрировала возможность взаимодействия ADFS с продуктами управления удостоверениями от IBM, CA, Oracle, BMC Software, Ping Identity и RSA Security.
Подходящей отправной точкой для изучения ADFS будет обзорный документ, подготовленный компанией Microsoft, который можно загрузить по адресу http://www.microsoft.com/windowsserver2003/r2/identity_management/adfswhitepaper.mspx.
Жан де Клерк (jan.declercq@hp.com) — сотрудник Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press).Дополнительная литература
Ресурсы Microsoft Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2, http://www.microsoft.com/windowsserver2003/r2/identity_management/adfswhitepaper.mspxСтандарты объединения аутентификации
Существует три основных потока стандартов объединения аутентификации.
- Поток Security Assertion Markup Language (SAML) принадлежит организации по развитию структурированных информационных стандартов (OASIS). SAML предоставляет диалект языка XML для встраивания идентификационных данных в XML-сообщения. В настоящее время в федерациях используются версии SAML 1.2 и 2.0. Версию SAML 2.0 можно рассматривать как соединение SAML 1.2 со спецификацией Liberty Identity Federation Framework (ID-FF) 1.1. Дополнительные сведения можно найти по адресу http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security.
- Потоки Liberty ID-FF 1.2 и Liberty Identity Web Services Framework (ID-WSF) 1.1 поддерживаются отраслевым консорциумом Liberty Alliance, в который входит более 150 компаний и организаций, заинтересованных в стандартизации объединения аутентификации. Дополнительные сведения приводятся по адресу http://www.projectliberty.org.
- Поток WS-Federation поддерживают компании IBM, Microsoft и VeriSign. Он представляет собой часть более широкого набора спецификаций для Web-служб. WS-Federation — сравнительно независимый поток, имеющий некоторые общие черты с потоками Liberty Alliance. В 2005 г. компании Sun Microsystems и Microsoft объявили о спецификации, которая обеспечивает взаимодействие между стандартами WS-Federation и Liberty ID-FF для единого Web-входа (SSO). Дополнительные сведения о WS-Federation см. по адресу http://schemas.xmlsoap.org/ws/2003/07/secext; дополнительные сведения о взаимодействии между WS-Federation и Liberty ID-FF можно найти по адресу http://xml.coverpages.org/WebSSO-InteropProfile200505.pdf.