Введение в Active Directory Federation Services для разработчиков
Автор: Кит Браун
Источник:
здесьОдним из самых важных компонентов Windows Server 2003 R2 является служба федерации Active Directory (Active Directory Federation Services, ADFS). ADFS решает ряд проблем, и одной из самых важных и сложных является автоматизация взаимодействия между предприятиями (B2B). В этой статье я собираюсь рассмотреть ADFS с точки зрения разработчика, который проектирует веб-приложение и хочет обеспечить доступ к нему другим организациям (ADFS с точки зрения администратора описана в
статье (EN) Мэта Стили в журнале «TechNet Magazine»).
Какие проблемы взаимоотношений B2B я имею в виду? Представьте, что предприятие, выпускающее велосипеды и называющееся Fabrikam, хочет создать веб-приложение, которое позволит уполномоченным дилерам закупать велосипеды и запчасти по оптовым ценам. При этом у предприятия более двухсот организаций-дилеров, в каждой из которых есть несколько человек, которым понадобится это приложение. Компании Fabrikam необходим защищенный механизм входа в систему.
Очевидное решение состоит в том, чтобы создать базу данных, содержащую имена пользователей и пароли, но это решение может быть очень дорогостоящим и трудозатратным. Если кто-то позвонит в Fabrikam, заявив, что он является служащим определенного дилера, то как компания проверит эту заявление? Вероятно, им придется связаться с доверенным лицом в дилерской организации, чтобы проверить статус служащего перед тем, как предоставить ему новую учетную запись. Теперь представим себе стоимость обслуживания такой учетной записи: люди иногда забывают имена, пароли и имеют другие проблемы. А что случится, если служащий будет уволен из дилерской организации? Все ли будут помнить, что нужно вовремя уведомить Fabrikam об удалении учетной записи этого пользователя? Если нет, такой пользователь может прийти домой и разместить ложные заказы от имени дилера.
Пароли сами по себе вызывают другую проблему. По мере роста вычислительной мощности компьютеров появляется все больше возможностей для взлома паролей, и многие организации сегодня предпочитают использовать более эффективные методы аутентификации, например смарт-карты. Но так как Fabrikam должна работать с большим числом дилеров, ей будет очень затруднительно поддерживать нечто более эффективное, чем пароли.
Заметьте, что фактор доверия здесь тоже играет свою роль. Fabrikam доверяет каждому дилеру в том, что они предоставят ей точный список служащих, которым разрешено делать заказы через веб-приложение Fabrikam.
Решение с применением ADFS
ADFS поможет вам установить доверительные отношения и уменьшить потребность в учетных записях пользователей. Зачем создавать базу данных учетных записей пользователей для вашего приложения, когда у дилеров уже есть ПО для аутентификации своих пользователей?
ADFS — это реализованный в Microsoft протокол 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 локальное подтверждение его идентичности в виде подписанного утверждения, о котором я говорил выше. Это большое преимущество с точки зрения безопасности: единый вход (single sign-on), который работает через Интернет и пересекает организационные и технологические границы.
Архитектура ADFS
Теперь я покажу вам различные части ADFS и объясню кое-какую терминологию. В любых федеративных отношениях одна сторона предоставляет пользователей (учетные записи), а другая — приложения (ресурсы). Установив службу ADFS, вы конфигурируете ее политику доверия через оснастку управления ADFS (она содержится в папке Administrative Tools) и составляете список партнеров, с которыми хотите установить федеративные отношения (создать федерацию). Пользователи партнерской организации по имеющимся в ней учетным записям будут обращаться к приложениям с поддержкой ADFS у партнера по ресурсам. На рис. 1 показано дерево политик доверия ADFS обеих сторон, образовавших федерацию.
Рис. 1. Политика для двух партнеров
У обеих сторон есть служба федерации. Каждая служба федерации предоставляет доступ к веб-приложению, и ожидается, что браузер пользователя будет переадресован к этим приложениям для выполнения входа в систему. Служба федерации устраняет всяческие несогласованности между партнерами по учетным записям и ресурсам, причем на таком уровне, что партнеры могут использовать разные идентификации и операционные системы. Вашему приложению не нужно особо заботиться о службе федерации; ADFS предоставляет веб-агент, который работает в конвейере ASP.NET как HttpModule и сделает за вас основную работу. Вам нужно лишь настроить свое приложение на использование веб-агента и ввести некоторые параметры конфигурации, чтобы приложение знало, где найти службу федерации вашей компании. На рис. 2 показаны базовая структура ADFS и то, как браузер пользователя взаимодействует с различными компонентами. Как видите, достаточно легко представить себе партнера по учетным записям, который работает, например, в системе WebSphere и использует службу каталогов IBM, а также службу федерации на основе языка Java.
Рис. 2. Структура ADFS
Федеративный вход
Когда Элис, зарегистрированный пользователь одного из дилеров Fabrikam, впервые открывает в своем браузере торговое приложение Fabrikam, веб-агент обнаруживает, что у нее нет cookie для ADFS. Она пока не зарегистрирована. Веб-агент переадресует ее браузер в службу федерации Fabrikam. Последняя переадресовывает браузер в службу федерации дилера, добавляя к запросу уникальный идентификатор службы федерации Fabrikam, чтобы дилер знал, какой партнер запрашивает вход в его систему. Когда браузер Элис связывается со службой федерации собственной компании, ей поступает запрос на аутентификацию. Поскольку организация дилера использует интегрированную в Windows аутентификацию, браузер Элис автоматически отвечает на этот запрос, и ее служба федерации разрешает вход. После успешного входа в систему ее служба федерации выдает маркер SAML (Security Assertion Markup Language), описывающий учетные данные Элис, и переадресует браузер обратно в службу федерации Fabrikam, посылая маркер SAML как часть тела POST-запроса (возвращаемая страница содержит JavaScript, который автоматически заполняет форму, содержащую скрытые элементы ввода). Fabrikam читает содержимое маркера и создает еще один маркер SAML, который содержит набор заявлений и будет виден приложению (почему используются два разных маркера SAML, я объясню в разделе по преобразованию заявлений). Второй маркер посылается с использованием метода POST и записывается в cookie от fabrikam.com, разрешая Элис работать с приложением на время действия ее cookie (по умолчанию 10 часов).
Помните веб-агент в приложении, который искал cookie для входа в систему? Это он запустил всю эту последовательность событий. Теперь, когда cookie существует, веб-агент открывает его и читает заявления (claims) в маркере 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, чтобы облегчить себе жизнь и снизить вероятность попадания конфиденциальных данных к злоумышленнику.
Ошибки, связанные с вызовом кросс-сайтовых сценариев (cross-site scripting, XSS), могут иметь серьезные последствия для веб-приложения на основе ADFS, как и в любой системе, использующей cookie для представления сеансов входа в систему. Сookie легко украсть из приложения с такой уязвимостью, а если удалось заполучить cookie, удастся и войти в систему. В качестве меры эшелонированной защиты срок действия cookie ADFS для входа в систему истекает по окончании рабочего дня, и этот интервал можно настроить в политике доверия ADFS. Если вы плохо знакомы с XSS и с тем, как избежать их, потратьте полчаса на интерактивную лабораторную работу по XSS, написанную мной.
Откуда ты, пользователь?
У Fabrikam много дилеров, выступающих в роли федеративных партнеров по учетным записям. Когда пользователь использует приложение, как сервер федерации Fabrikam узнает, какому партнеру переадресовать браузер пользователя? Никак. Сервер федерации Fabrikam приостанавливает процесс входа и показывает пользователю список партнеров, чтобы он выбрал свою организацию. Это называют распознаванием принадлежности (home realm discovery). Если клиент солжет о своей принадлежности, он лишь причинит себе неудобства, так как у него нет учетных данных для аутентификации у любого другого дилера.
Одна из целей создания ADFS-приложения — не забивать голову пользователю такого рода деталями. Магазин Northwind, торгующий велосипедами, может пропустить этот этап, предоставляя своим пользователям доступ к веб-сайту Fabrikam через ссылку с магическим параметром в строке запроса — whr. Веб-агент ищет этот параметр в строке запроса и, если находит, извлекает его из строки запроса во время предварительной обработки. Значением этого параметра является URI службы федерации партнера (у каждой службы федерации есть свой URI). Поэтому служащие в магазине Northwind могут получить примерно такую ссылку:
https://fabrikam.com/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). Если вы являетесь партнером по учетным записям и хотите, чтобы ваши пользователи оставались анонимными при работе с определенным партнером по ресурсам, просто включите эту функцию для данного партнера в вашей политике доверия, и, вместо того чтобы увидеть имя пользователя:
alice@northwindbikes.com
партнер увидит нечто вроде:
tQZPfFuodGysa4t40oj+kM2vBIU=@northwindbikes.com
Чтобы сгенерировать этот описатель (handle), служба федерации создает хеш-значение из фактического заявления идентификации, URI партнера по ресурсам и некоего значения, известного только вашей службе федерации (в терминологии ADFS это называют «ключом конфиденциальности»). Благодаря включению URI партнера описатели являются разными для каждого партнера по ресурсам, что препятствует возможности составить досье на определенного пользователя. Ключ конфиденциальности добавляется, чтобы затруднить атаки по словарю.
Несмотря на защиту идентификации от партнера по ресурсам, ее все же можно проследить. Если нужно определить чью-то идентификацию, ее можно найти в файле журнала использования ресурсов и передать администратору партнера по учетным записям, который может использовать журналы событий учетных записей, чтобы определить, какой именно пользователь получил данную идентификацию.
Прокси службы федерации
Установив службу федерации ADFS, вы увидите новое веб-приложение в диспетчере IIS под названием «adfs». Под ним располагаются подкаталоги fs и ls, которые расшифровываются как Federation Service и Logon Service соответственно. Служба входа (Logon Service) — на самом деле просто клиентский интерфейс ADFS на основе браузера; заглянув в подкаталог ls, вы увидите набор страниц ASPX (между прочим, их можно настраивать). Именно сюда перенаправляется браузер при федеративном входе в систему. Я нигде не нашел термина «Logon Service» в опубликованной документации ADFS, но если поглядеть на код, то там это называется именно так. В каталоге fs вы найдете файл под названием FederationServerService.asmx — это веб-сервис, который образует серверную часть ADFS и технически называется службой маркеров защиты (Security Token Service, STS).
Причина такого разделения в том, что клиентский интерфейс (служба входа) может размещаться на периметре сети (который часто называют DMZ, демилитаризованной зоной) и взаимодейстовать с серверной частью службы федерации через веб-сервис ASMX, работающий во внутренней сети. В такой конфигурации клиентский интерфейс называется прокси службы федерации.
Разделит ли ваш администратор службу федерации, используя прокси на отдельной машине, большого значения не имеет, но в любом случае полезно знать, что ADFS способна работать в DMZ.
Включение в веб-приложения поддержки ADFS
Если перед вами стоит задача создать веб-приложение, которое поддерживает вход через ADFS, вам нужно сделать несколько вещей. От вас потребуется настроить свой файл web.config так, чтобы загружать и конфигурировать веб-агент ADFS. В листинге 1 показан файл web.config, который я использовал при подготовке примера приложения для этой статьи.
Листинг 1. Пример web.config
<configuration>
<configSections>
<sectionGroup name="system.web">
<section name="websso" type=
"System.Web.Security.SingleSignOn.
WebSsoConfigurationHandler,
System.Web.Security.SingleSignOn, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
Custom=null"/>
</sectionGroup>
</configSections>
<system.web>
<!-- Стандартные методы аутентификации ASP.NET
не применяются — мы используем ADFS! -->
<authentication mode="None" />
<customErrors mode="Off"/>
<sessionState mode="Off" />
<!-- Загрузка сборок ADFS -->
<compilation debug='true' defaultLanguage='c#'>
<assemblies>
<add assembly="System.Web.Security.SingleSignOn,
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35, Custom=null"/>
<add assembly="System.Web.Security.SingleSignOn.
ClaimTransforms, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35, Custom=null"/>
</assemblies>
</compilation>
<!-- Загрузка модуля, содержащего веб-агент ADFS -->
<httpModules>
<add name="ADFS Web Agent" type=
"System.Web.Security.SingleSignOn.
WebSsoAuthenticationModule,
System.Web.Security.SingleSignOn, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
Custom=null" />
</httpModules>
<!-- Веб-агент ищет здесь свою конфигурацию -->
<websso>
<authenticationrequired />
<eventloglevel>55</eventloglevel>
<auditsuccess>2</auditsuccess>
<urls>
<returnurl>https://resource.local/web/</returnurl>
</urls>
<cookies writecookies="true">
<path>/web</path>
<lifetime>240</lifetime>
</cookies>
<fs>https://resource.local/adfs/fs
/federationserverservice.asmx</fs>
</websso>
</system.web>
<system.diagnostics>
<switches>
<!-- Включает полное протоколирование для отладки -->
<add name="WebSsoDebugLevel" value="255" />
</switches>
<trace autoflush="true" indentsize="3">
<listeners>
<!-- Либо создаем каталог c:\logs и выдаем разрешение
Network Service записывать в него, либо удаляем
этот слушатель -->
<add name="MyListener" type=
"System.Web.Security.SingleSignOn.
BoundedSizeLogFileTraceListener,
System.Web.Security.SingleSignOn, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
Custom=null"
initializeData="c:\logs\webagent.log" />
</listeners>
</trace>
</system.diagnostics>
</configuration>Настроив файл web.config, вы сможете принимать данные для входа в систему от ваших ADFS-партнеров по учетным записям. Следующим шагом будет принятие решений по организации безопасности на основе заявлений.
Существует два веб-агента ADFS. Один называют Web Agent for Windows NT Token-based Applications (веб-агент для приложений, использующих маркер Windows NT). Этот веб-агент запускает реальный сеанс входа в систему для удаленного пользователя. Он создает логин из основного имени пользователя через расширения S4U (Service-for-Users) протокола Kerberos, которые были описаны мной в этой рубрике еще в апреле 2003 г. (нужен специальный аутентификационный пакет, если вы не используете родной режим Windows Server 2003). Преимущество в том, что вы можете переложить авторизацию на существующие диспетчеры защищенных ресурсов, например на файловую систему или SQL Server. (Если эти ресурсы являются удаленными, вам также нужно разрешить переключение протоколов в Active Directory.) Один из самых крупных недостатков этого метода — вам придется предоставлять учетную запись в своем домене для каждого входящего пользователя, что сводит на нет многие преимущества от использования ADFS! (Однако пользователи при этом не должны знать свой пароль доступа к учетной записи на стороне ресурса, и скорее всего они даже не узнают, что для них заведена еще одна учетная запись.)
Если вы хотите работать по схеме федерации, вам нужно создать приложение, которое понимает заявления, и при этом вы не сможете положиться на механизм олицетворения (impersonation), так как у вас не будет учетной записи домена Windows, представляющей пользователей ваших партнеров по учетным записям. Вы будете иметь дело с веб-агентом, который не делает никаких сопоставлений с учетными записями Windows, а передает вам поступающие заявления через свойство HttpContext.User. Этот подход я и применил в своем примере.
Написать код для проверки заявлений нетрудно. На самом деле, если вы в основном полагаетесь на заявления групп, вам вообще не нужно особо думать о заявлениях. Просто продолжайте использовать HttpContext.User.IsInRole, чтобы проверять наличие или отсутствие таких заявлений, рассматривая их как роли приложения. То есть вы можете использовать такие элементы управления ASP.NET, как LoginView, которые работают на основе ролей, полученных через свойство HttpContext.User.
Если вы хотите получать значения нестандартных заявлений, вам понадобится немного кода. В этом фрагменте кода выполняется поиск заявления Title:
string GetTitle()
{
SingleSignOnIdentity id = (SingleSignOnIdentity)
User.Identity;
SecurityPropertyCollection c =
id.SecurityPropertyCollection.GetCustomProperties(
"Title");
return (1 == c.Count) ? c[0].Value : string.Empty;
}Интересной частью передаваемых данных является метод, используемый для аутентификации клиента в его области принадлежности (realm). ADFS поддерживает четыре метода аутентификации: интегрированную в Windows, на основе сертификатов SSL, базовую (Basic) и на основе форм ASP.NET. Узнать, какой метод аутентификации был применен, можно из свойства AuthenticationMethod объекта SingleSignOnIdentity. Не путайте его со свойством AuthenticationType в IIdentity; вы обнаружите, что оно всегда возвращает значение WebSSO, которое означает, что за вход в систему отвечала ADFS.
Другим интересным свойством является AuthenticatingAuthority — URI партнера по учетным записям, который аутентифицировал данного клиента. Всегда полезно наличие кнопки Log Off, и здесь вам пригодится свойство SignOutUrl.
Приложение-пример для этой статьи формирует таблицу по значениям всех открытых свойств SingleSignOnIdentity, как показано на рис. 5. Оно также получает набор свойств, относящихся к защите, который показывает все посланные заявления в их исходном виде. Но, прежде чем запустить это приложение, вам нужно установить ADFS.
Рис. 5. Приложение-пример
Лабораторная работа с ADFS
Если вы хотите поэкспериментировать с ADFS, вам нужно создать подходящую среду. Я делал заметки, когда настраивал свое B2B-приложение, работающее с заявлениями, и могу предложить достаточно быстрый способ создать систему из трех образов Virtual PC, представляющих партнера по учетным записям, у которого есть один клиентский компьютер, и партнера по ресурсам. Я выложил эти заметки на свою страничку
pluralsight.com/wiki/default.aspx/Keith/SettingUpADFS.html (EN). Некоторые заметки могут показаться слишком краткими, но они должны быть понятны тем, кто уже работал с Virtual PC и Windows. Я поясняю, как настроить домены и использовать SYSPREP, что может оказаться новой областью для вас. При желании вы можете внести свои комментарии для других пользователей, дважды щелкнув эту страничку, но прошу вас быть краткими, чтобы сохранить стиль моих заметок.
Там же находится и приложение-пример, включая файл конфигурации, который можно использовать при тестировании. Просто скопируйте файлы default.aspx и web.config в виртуальный каталог на образе партнера по ресурсам; после этого вы сможете войти в систему с компьютера-клиента и указать в своем браузере веб-приложение партнера по ресурсам, в которое вы хотите войти.