Службы федерации Active Directory (ADFS)

Службы федерации Active Directory (ADFS)

Кит Браун (Keith Brown)

Одним из самых важных компонентов Windows Server®2003 R2 являются Службы федерации Active Directory (ADFS, Active Directory Federation Services). ADFS решает ряд проблем, и одной из самых важных и сложных является автоматизация взаимодействия бизнес-бизнес. Какие проблемы взаимоотношений B2B (бизнес-бизнес) я имею в виду? Представьте, что изготовитель велосипедов под названием Fabrikam хочет создать веб-приложение, которое позволит уполномоченным дилерам покупать велосипеды и запчасти по оптовым ценам. При этом у него имеется более двухсот дилеров, у каждого из которых есть несколько человек, которые будут использовать это приложение. Компании Fabrikam необходим безопасный механизм входа в систему.

Очевидное решение состоит в том, чтобы создать базу данных, содержащую имена пользователей и пароли, но это решение может быть очень дорогостоящим и трудозатратным. Если кто-то позвонит в Fabrikam, заявляя, что он является служащим определенного дилера, как компания сможет проверить эту заявку? Вероятно, они захотят связаться с доверенным лицом в дилерской организации, чтобы проверить статус служащего, перед тем, как предоставить ему новую учетную запись. Давайте представим себе стоимость обслуживания такой учетной записи: люди иногда забывают имена, пароли и имеют другие проблемы. А что случится, если служащий будет уволен из дилерской организации? Все ли будут помнить, что нужно вовремя уведомить Fabrikam об удалении учетной записи этого пользователя? Если нет, то такой пользователь может прийти домой и разместить ложные заказы от имени дилера.

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

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

Решение с использованием ADFS

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

ADFS – это реализованный в Майкрософт протокол Passive Requestor Profile стандарта WS-Federation (слово «пассивный» говорит о том, что все, что должно быть у клиента, это браузер с поддержкой cookie и JavaScript, то есть пассивный агент, который не выполняет никакого специального кода, чтобы помочь реализовать протокол). Протокол работает следующим образом: когда пользователь дилера откроет своим браузером сайт веб-приложения Fabrikam, браузер будет переадресован на веб-сайт дилера, где работает этот пользователь, где и произойдёт аутентификация. После этого браузер будет переадресован назад на сайт Fabrikam, причём его новый запрос будет нести в себе подписанное дилером утверждение, указывающее, что данный пользователь действительно является служащим дилера и уполномочен использовать данное приложение. (Я немного упрощаю описание процесса.) Но смысл в том, что Fabrikam доверяет дилеру провести аутентификацию собственных пользователей, что является ключевым приемом в технологии федерации.

Если дилер имеет программное обеспечение, которое поддерживает пассивный профиль WS-Federation, от Fabrikam не требуется предоставлять учетные записи служащим этого дилера. Также не нужно беспокоиться о запросах восстановления паролей. Если пользователь дилера меняет свою роль и больше не работает в отделе закупок, то (как только идентификационные данные пользователя соответственно изменены), когда он попробует использовать торговое приложение Fabrikam, утверждение, полученное от дилера, укажет, что он больше не является агентом по закупкам, и ему будет отказано в доступе. Или, если он прекратит работать в организации дилера, его учетная запись будет удалена, и в результате он также не сможет использовать торговое приложение. Устанавливая федеративные отношения с дилером, Fabrikam гарантированно получит более актуальную информацию о подлинности пользователей.

ADFS основана на спецификации WS-Federation, которая была совместно разработана корпорациями Microsoft, IBM, Verisign, BEA и RSA Security. Различные организации часто используют существенно разное программное обеспечение. Если Fabrikam использует Windows Server 2003 R2 с ADFS, а его дилеры работают с IBM WebSphere или BEA WebLogic, то это на самом деле не должно быть проблемой, так как и WebSphere и WebLogic реализуют стандарт WS-Federation.

Конечные пользователи также будут довольны федеративной идентификацией. Вместо того чтобы помнить еще один пароль, дилерский агент по закупкам может просто запустить в своём браузере приложение Fabrikam и немедленно начать работать. Если система аутентификации дилера поддерживает интегрированный вход в систему через браузер, как это сделано в Windows с Internet Explorer, то у пользователя даже не будут запрошены его учетные данные; аутентификация будет проведена незаметно, и служба федерации передаст в Fabrikam локальное подтверждение его идентичности в виде подписанного утверждения, о котором я говорил выше. Это большое преимущество для веб-безопасности: однократная идентификация, которая работает через Интернет и пересекает организационные и технологические границы.

Архитектура ADFS

Теперь я покажу вам различные части ADFS и объясню кое-какую терминологию. В любых федеративных отношениях одна сторона предоставляет пользователей (учетные записи), а другая — приложения (ресурсы). Установив службу ADFS, вы конфигурируете ее политику доверия через оснастку управления ADFS (она содержится в папке Administrative Tools) и составляете список партнеров, с которыми хотите установить федеративные отношения (создать федерацию). Пользователи партнерской организации по имеющимся в ней учетным записям будут обращаться к приложениям с поддержкой ADFS у партнера по ресурсам. На рис. 1 показано дерево политик доверия ADFS обеих сторон, образовавших федерацию.

 Рис. 1. Политика для двух партнеров

У обеих сторон есть служба федерации. Каждая служба федерации предоставляет доступ к веб-приложению, и ожидается, что браузер пользователя будет переадресован к этим приложениям для выполнения входа в систему. Служба федерации устраняет всяческие несогласованности между партнерами по учетным записям и ресурсам, причем на таком уровне, что партнеры могут использовать разные идентификации и операционные системы. Вашему приложению не нужно особо заботиться о службе федерации; ADFS предоставляет веб-агент, который работает в конвейере как HttpModule и сделает за вас основную работу. Вам нужно лишь настроить свое приложение на использование веб-агента и ввести некоторые параметры конфигурации, чтобы приложение знало, где найти службу федерации вашей компании. На рис. 2 показаны базовая структура ADFS и то, как браузер пользователя взаимодействует с различными компонентами. Как видите, достаточно легко представить себе партнера по учетным записям, который работает, например, в системе WebSphere и использует службу каталогов IBM, а также службу федерации на основе языка Java.

 Рис. 2. Структура ADFS

Подробнее о федеративной регистрации

Когда Алиса, зарегистрированный пользователь одного из дилеров Fabrikam, открывает в своем браузере торговое приложение Fabrikam в первый раз, веб-агент замечает, что она не имеет файла cookie для ADFS. Она пока не зарегистрирована. Веб-агент переадресовывает ее браузер в службу федерации Fabrikam прежде, чем торговое приложение увидит ее запрос. Служба федерации Fabrikam после этого переадресовывает браузер в службу федерации дилера, добавляя к запросу уникальный идентификатор службы федерации Fabrikam, чтобы дилер знал, какой партнер просит входа в его систему. Когда браузер Алисы связывается со службой федерации ее собственной компании, ему поступает запрос на аутентификацию. Поскольку организация дилера использует интегрированную проверку подлинности Windows, браузер Алисы автоматически отвечает на этот запрос, подтверждая её вход в систему в службе федерации. Поскольку вход в систему был успешен, ее служба федерации выпускает маркер SAML (Security Assertion Markup Language), описывающий учетные данные Алисы, и переадресовывает браузер Алисы назад в службу федерации Fabrikam, посылая маркер SAML как часть тела POST-запроса (возвращаемая страница содержит JavaScript, который автоматически заполняет форму, содержащую скрытые элементы ввода). Fabrikam читает содержимое маркера и выпускает еще один маркер SAML, который содержит набор заявок и будет увиден приложением (я объясню, почему используются два различных маркера SAML в разделе по преобразованию заявок). Этот второй маркер посылается с использованием метода POST и записывается в файл cookie от , позволяя Алисе использовать торговое приложение, пока время действия ее файла cookie не истечет, что по умолчанию составляет 10 часов.

Помните веб-агента в торговом приложении, который искал файл cookie для входа в систему? Это он запустил всю эту последовательность событий. Теперь, когда cookie существует, веб-агент открывает его и читает заявку в маркере SAML, который был выпущен службой федерации Fabrikam. После этого веб-агент разрешает осуществить загрузку веб-страницы торгового приложения. Если приложению нужно знать имя вошедшего в систему пользователя, ему нужно всего лишь найти его в обычном месте: HttpContext. User. Identity. Name.

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

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

Защита федеративного входа в систему

Теперь давайте рассмотрим более подробно, как обеспечивается безопасность входа в систему. Один вектор атаки может состоять в том, чтобы считывать маркеры SAML и затем воспроизводить их в удобное время, олицетворяя законного пользователя. Чтобы предотвратить это, всё взаимодействие происходит по протоколу HTTPS. Это критично; и если вы попытаетесь установить ADFS, еще не установив сертификат SSL для веб-сайта по умолчанию в IIS, то инсталлятор ADFS предупредит вас и выйдет из режима установки прежде, чем она начнется.

А как насчет использующегося при входе в систему файла cookie, который содержит заявки? Если бы пользователь захотел поднять свои привилегии при доступе к приложению, то он мог бы просто добавить заявки в маркер SAML в своем файле cookie! Но этот тип подделки данных может быть обнаружен, так как каждый маркер SAML подписывается закрытым ключом, который известен только выпустившей его службе федерации. Все это имеет значение для развертывания ADFS. Если вы действуете как партнер по ресурсам, то каждый из ваших партнеров по учетным записям должен предоставить сертификаты для своих служб федерации. Ваша служба федерации ресурсов будет использовать сертификат партнера по учетным записям, чтобы проверять подписи на маркерах SAML, которые она выпускает. Веб-агент должен делать что-то подобное, проверяя, что каждый маркер SAML, который он получает через файл cookie для входа в систему, был подписан службой федерации партнера по ресурсам.

Файлы сookie, выпущенные ADFS, всегда помечены битом Secure, который указывает, что браузер должен посылать сookie только через HTTPS, а не HTTP. Поэтому, если какая-либо часть вашего приложения использует протокол HTTP, файл cookie для входа в систему будет здесь отсутствовать, и, соответственно, не будет доступа к информации об идентификации пользователя. Это будет выглядеть так, будто пользователь является анонимным. Я бы порекомендовал выполнять всё приложение через SSL, чтобы облегчить себе жизнь и снизить вероятность попадания конфиденциальных данных к злоумышленнику.

Ошибки, связанные с вызовом сценариев на других веб-узлах (XSS, Cross-site scripting), могут иметь серьезные последствия для веб-приложения на основе ADFS, как и в любой системе, которая использует файлы cookie для представления сеансов регистрации в системе. Можно легко украсть сookies из приложения, которое имеет этот тип уязвимости, и если удалось заполучить cookie, то удалось заполучить и вход в систему. В качестве меры глубокой защиты, cookies ADFS для входа в систему устаревают по окончании рабочего дня, и это время устаревания можно настроить в политике доверия ADFS.

Откуда ты, пользователь?

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

Одной из целей создания ADFS-приложения является стремление перестать беспокоить пользователя такого рода подробностями. Велосипедный магазин Northwind может опустить этот шаг, предоставляя своим пользователям доступ к веб-сайту Fabrikam через ссылку с волшебным параметром строки запроса – whr. (Мне нравится расшифровывать это как "which home realm (вы из какой сферы?)"). Веб-агент ищет этот параметр в строке запроса, и если находит, то извлекает его из строки запроса во время предварительной обработки. Значением этого параметра является URI-адрес службы федерации партнера (каждая служба федерации имеет свой URI-адрес). Поэтому служащие в магазине Northwind могут получить ссылку, похожую на эту:

https:///purchasing. aspx/?whr=urn:federation:Northwindbikeshop

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

Заявления и преобразование

Я уже много говорил о заявлениях (claims) в этой статье. Представляя собой новое и все более важное понятие, относящееся к концепции защиты на платформе Windows, заявления являются универсальным способом формирования утверждений о такой сущности, как пользователь. Рассмотрим билет Kerberos, содержащий идентификаторы пользователя и доменной группы для вошедшего в систему пользователя. На самом деле это просто набор заявлений, подписанный контроллером домена, который сгенерировал билет. Идентификатор пользователя — заявление об идентификации. Хотя такое заявление может использоваться для аудита или персонализации, оно обычно не применяется для управления доступом. Более вероятно, что для проверки прав доступа будут использованы группы, указанные в билете. Например, если вы являетесь членом группы Managers, вам может быть разрешено утверждать дорогостоящие закупки.

ADFS поддерживает три типа заявлений: идентификации, группы и нестандартные заявления. Заявление идентификации (identity claim) состоит из основного имени пользователя (user principal name, UPN), его электронного адреса или произвольной строки — так называемого общего имени (common name). Заявление группы (group claim) является логической переменной (член группы или нет) и не обязательно должно представлять Windows-группу: оно может просто отражать логическую роль, распознаваемую вашим приложением. Нестандартное заявление (custom claim) содержит строковое значение. Примерами таких заявлений в ADFS могут быть возраст, пол или даже имя менеджера. Этот тип заявлений должен заставить вас подумать о вопросах конфиденциальности.

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

Каждая компания определяет набор заявлений для своей организации; это похоже на создание понятного ей словаря. Так, Fabrikam может определить заявление группы под названием «Владелец», которая представляет владельца дилерского магазина, торгующего велосипедами. Но магазин Northwind может представить эту же роль в заявлении «Менеджер». Это нормально, если эти заявления имеют одинаковое значение, так как владелец Northwind может использовать федеративную политику доверия своего ресурса, чтобы сопоставить свое исходящее заявление «Менеджер» с заявлением «Владелец», которое способна понять Fabrikam. Администраторы могут настроить такие сопоставления на обеих сторонах, связанных федеративными отношениями. На рис. 3 дан пример сопоставления заявок в политике доверия партнера по ресурсам.

 Рис. 3. Сопоставление заявлений

Некоторые сопоставления слишком изменчивы, чтобы их можно было представить в виде статического сопоставления в политике доверия. Предположим, что партнеру по ресурсам нужно заявление под названием «IsOfLegalVotingAge», чтобы удостовериться, что кому-то уже исполнилось 18 лет, но вы знаете лишь дату рождения пользователя в виде нестандартного заявления от Active Directory. Значит, вам нужен модуль преобразования заявлений, который является сборкой, где реализован управляемый класс IClaimTransform. Вы можете привязать его к вашей политике доверия в окне свойств политики доверия (рис. 4). Этот модуль вызывается дважды: один раз перед тем, как происходит обычное сопоставление политики доверия, и один раз после этого, что позволяет выполнить какую-то пре - или постпроцессную обработку. Каждая политика доверия ADFS дает возможность установить такой модуль, а значит, динамическое преобразование заявлений можно выполнять как на стороне партнера по учетным записям, так и на стороне партнера по ресурсам.

 

Рис. 4. Модуль преобразования заявлений

Откуда поступают заявки?

Если только вы не напишете свой модуль преобразования заявок, который генерирует заявки динамически, то все ваши заявки будут поступать из хранилища учетных записей, которым может быть либо Active Directory, либо ADAM (Active Directory Application Mode) – небольшой сервер управления каталогом, созданный на основе кода Active Directory. Работая с хранилищем учетных записей Active Directory, вы можете отобразить групповые заявки на одну или более групп в Active Directory; в хранилище ADAM вы должны предоставить название атрибута на объекте пользователя и значение для поиска, чтобы указать, нужно ли групповую заявку посылать для данного пользователя. Каждая настраиваемая или идентификационная заявка отображается непосредственно на один атрибут объекта пользователя в каталоге.

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

Анонимность

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

Чтобы поддержать этот анонимный режим работы, есть специальное встроенное преобразование для идентификационных заявок, под названием «улучшенная безопасность идентификации» (enhanced identity privacy). Если вы являетесь партнером по учетным записям и хотите, чтобы ваши пользователи оставались анонимными при работе с определенным партнером по ресурсам, просто включите эту функцию для данного партнера в вашей политике доверия, и вместо того, чтобы увидеть имя пользователя

*****@***com

партнер увидит нечто подобное этому:

tQZPfFuodGysa4t40oj+kM2vBIU=@

Чтобы сгенерировать этот маркер, служба федерации создает комбинацию из фактической идентификационной заявки, URI партнера по ресурсам, и некоего значения, которое известно только вашей службе федерации (в терминологии ADFS это называется "закрытым ключом"). Включение сюда URI партнера обеспечивает то, что маркеры являются разными для каждого партнера по ресурсам, что препятствует возможности составить совместное досье данных на определенного пользователя. Закрытый ключ включается для того, чтобы затруднить атаки по словарю.

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

Прокси-агент службы федерации

Когда вы установите службу федерации ADFS, вы увидите новое веб-приложение в диспетчере IIS, под названием "adfs". Внутри него находятся подкаталоги "fs" и "ls", которые означают Federation Service и Logon Service. Служба входа в систему (Logon Service) на самом деле является интерфейсом ADFS для браузера; и если вы заглянете в подкаталог ls, то увидите набор страниц ASPX (между прочим, вы можете видоизменить эти страницы, если захотите, поэтому стоит их исследовать). Именно сюда перенаправляется браузер при федеративном входе в систему. Я нигде не нашел термина "Logon Service" в опубликованной документации для ADFS, но, если поглядеть на код, то там это называется именно так. В каталоге fs вы найдете файл под названием FederationServerService. asmx – это веб-служба, которая составляет внутреннюю часть ADFS, и технически называется Службой маркеров безопасности (STS, Security Token Service).

Причиной такого разделения является то, что интерфейс (служба входа в систему) может размещаться на периметре сети (который часто называется DMZ, Demilitarized Zone - нейтральная зона) и может общаться с внутренней службой федерации через веб-службу ASMX, которая работает во внутренней сети. В такой конфигурации интерфейс называется прокси-агентом службы федерации.

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

Веб-приложения с поддержкой ADFS

Существует два различных веб-агента ADFS. Один называется веб-агентом для приложений, использующих маркер Windows NT. Этот веб-агент запускает реальный сеанс входа в систему для удаленного пользователя. Он создает регистрационное имя из основного имени пользователя, используя расширения S4U (Service-for-Users) протокола Kerberos. Преимуществом является то, что вы можете принять этот вход в систему и передать функции авторизации существующим диспетчерам безопасности ресурсов, которые работают для вас, таким как файловая система или SQL Server™. (Если эти ресурсы являются удаленными, вам также нужно включить передачу протокола в Active Directory.) Одним из самых больших недостатков этого метода является то, что вам придется предоставлять учетную запись пользователя в вашем домене для каждого входящего пользователя, что, в первую очередь, сводит на нет многие преимущества от использования ADFS! (Однако, пользователи при этом не должны знать свой пароль доступа к учетной записи на стороне ресурса, и, наиболее вероятно, они не будут даже знать, что для них заведена еще одна учетная запись.)

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