Знакомимся с сервисом Windows Azure AppFabric Access Control Service заново

Если вы ищете сервис, который упрощает аутентификацию и авторизацию пользователей на ваших веб-сайтах и в сервисах, то еще раз рассмотрите сервис Windows Azure AppFabric Access Control service (ACS для краткости), так как на момент написания этой статьи в него вносились существенные обновления.

Открытие доступа к приложению для пользователей из других организаций с соблюдением стандартов высокой безопасности всегда было серьезной проблемой. Эта проблема традиционно была связана с корпоративными сценариями применения, где пользователи, как правило, распределены по каталогам. Появление и развитие социальных сетей как важной арены онлайновой активности делает привлекательной идею доступа к корпоративному приложению пользователей из сферы Windows Live ID, Facebook, Yahoo и Google.

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

ACS в значительной мере снимает остроту этих проблем. Если в двух словах, то ACS может выступать в роли посредника между вашим приложением и репозитариями пользователей (провайдерами идентификаций) (identity providers, IP), где хранятся учетные записи, с которыми вы хотите работать. ACS берет на себя низкоуровневые детали взаимодействия с каждым IP и использует соответствующий протокол, избавляя ваш код от необходимости учитывать детали транзакции каждого типа. ACS поддерживает множество протоколов, например OpenID, OAuth WRAP, OAuth 2.0, WS-Trust и WS-Federation. Это позволяет вам задействовать преимущества многих IP.

Делегирование аутентификации (и отчасти авторизации) из вашего решения в ACS осуществляет очень просто. Вам нужно лишь использовать Windows Identity Foundation (WIF) — расширение Microsoft .NET Framework, которое дополняет приложения «продвинутыми» средствами идентификации и управления доступом, — и выполнить ряд операций с помощью специального мастера в Visual Studio. Обычно это делается без написания какого-либо кода!

Вам это кажется темным лесом? Не волнуйтесь, вы не одиноки; как это часто бывает в случае идентификации и защиты, объяснить что-то куда труднее, чем сделать. Давайте рассмотрим один распространенный вариант применения ACS — делегирование аутентификации на вашем веб-сайте множеству IP — и пошагово разберем, как это происходит.

Делегирование аутентификации на веб-сайте сервису ACS

Для начала возьмем обычный веб-сайт и разрешим пользователям входить через учетную запись в Google.

Но сначала убедимся, что у нас есть все необходимое. Вот что нам потребуется:

• Visual Studio 2010;
• исполняющая среда Windows Identity Foundation;
• Windows Identity Foundation SDK и одна из следующих ОС: Windows 7, Windows Server 2008, Windows Server 2008 R2 или Windows Vista SP1.

Хотя это не обязательно, наличие IIS на компьютере упростит работу; если у вас не установлен IIS, вам придется самостоятельно подстраивать отдельные операции.

Говорить что-то о Visual Studio вряд ли стоит, но, вероятно, есть смысл немного обсудить WIF (произносится как «dub-IF») и почему она необходима. (Полное описание WIF см. в книге «Programming Windows Identity Foundation» [Microsoft Press, 2010].)

WIF — это расширение .NET Framework, которое предоставляет новую модель для программирования аутентификации и идентификаций пользователей; эта модель отделяет ваше приложение от деталей того, как происходит аутентификация. Традиционные системы аутентификации (вроде API провайдера членства в группах ASP.NET) просто вынуждают вас иметь дело с деталями того, как выполняется аутентификация. А это требует использования низкоуровневых API для работы с низкоуровневыми конструкциями наподобие паролей, сертификатов т. д. WIF меняет все это, предлагая удобную абстракцию, которая позволяет вам указывать внешнюю сущность, берущую на себя аутентификацию пользователя. В случае аутентификации на основе форм вы указываете определенную страницу (обычно login.aspx), на которую перенаправляются запросы, если обратившийся к первоначальной странице еще не аутентифицирован. В случае WIF вы можете указать внешнюю сущность (IP), которая будет вызываться при необходимости аутентификации пользователя. Способы выбора IP на этапе разработки и в период выполнения следуют общеизвестным протоколам. Подсистема WIF сама распознает, какие протоколы нужно использовать, и вводит в действие соответствующие политики взаимодействия. И вновь это гораздо легче показать, чем объяснить.

Создание начального решения

Откройте Visual Studio. Создайте новый веб-сайт, выбрав File | New | Web Site. Давайте создадим веб-сайт ASP.NET, но сначала убедитесь, что вы выбрали в Web location параметр «HTTP» и сконфигурировали URL так, чтобы сайт работал в IIS (рис. 1).Это обеспечит беспроблемное выполнение при использовании инструментария WIF. Если на вашем веб-сервере доступен HTTPS, используйте его; хотя это не обязательно для данного примера, в производственных системах настоятельно рекомендуется применять HTTPS, и это же избавит вас от некоторых предупреждений WIF.

Рис.1. Выбор веб-сайта ASP.NET с HTTP в качестве Web location

Нажав клавишу F5, вы увидите базовый веб-сайт ASP.NET, а щелкнув ссылку Log In, вы получите предложение ввести имя пользователя и пароль. Вот это мы и изменим: вместо использования имени и пароля и прямой обработки аутентификации на веб-сайте, мы задействуем WIF для делегирования аутентификации в ACS. Сервис ACS в свою очередь позволит нам открыть доступ внешним IP (провайдерам идентификации).

Настройка проекта ACS

Для начала мы создадим проект на портале Windows Azure AppFabric LABS. Портал LABS — это среда, настроенная специально для того, чтобы сообщество могло получать доступ к самой свежей версии. Использование AppFabric LABS совершенно бесплатно, но нет никаких гарантий или соглашений об уровне обслуживания (service-level agreements, SLA).

Откройте браузер и перейдите по адресу portal.appfabriclabs.com. Вам предложат зарегистрироваться с помощью Windows Live ID.После регистрации вам понадобится создать новый проект — щелкните ссылку «create a project». Вы должны будете выбрать имя проекта; выберите что-нибудь подходящее и щелкните OK. После этого вы увидите имя активного проекта (в нашем примере «acsdemoproject») — щелкните его (рис. 2).

Рис. 2. Создание проекта на портале Windows Azure AppFabric LABS

Прежде чем делегировать аутентификацию ACS, нужно определить пространство имен сервиса. Рассматривайте это пространство как нечто, предоставляющее вам часть среды AppFabric LABS, и в случае ACS как уникальный компонент для всех URI ресурсов, которые вы будете использовать при взаимодействии с ACS из своего приложения. Все, что содержится в этом пространстве имен сервиса, находится под вашим полным контролем. Щелкните Add Service Namespace, укажите имя, выберите зону — на портале LABS можно выбрать только «United States (South/Central)» — и щелкните Create. Заметьте, что URI, используемые AppFabric, доступны в Интернете всем и уникально идентифицируют сервисы; поэтому вы должны выбрать пространство имен, которое еще не выбрано другими.

Это займет несколько секунд, но после активизации пространства имен вашего сервиса вы сможете щелкнуть ссылку Access Control и приступить к конфигурированию ACS для своего веб-сайта.

Теперь это делается на портале управления (рис. 3).

Рис. 3. Портал управления сервисом Windows Azure AppFabric Access Control Service

Щелкните кнопку Manage, чтобы начать работу. Портал управления руководит выполнением некоторых операций, из которых состоит начальный процесс; этим мы и воспользуемся.

Выбор нужных вам провайдеров идентификации

Щелкните ссылку Identity Providers. Здесь нужно настроить различные провайдеры идентификации для социальных сетей, которые вы собираетесь использовать из своего приложения. Windows Live ID присутствует в списке по умолчанию; добавим в него поддержку учетных записей Google.

Щелкните ссылку Add Identity Provider — появится список провайдеров. Щелкните кнопку Add рядом с Google. Вы можете указать URL собственного изображения для IP, но пропустите это и просто щелкните Save. Вот и все, мы добавили Google как поддерживаемый источник идентификаций пользователей.

Настройка ACS на распознавание вашего веб-сайта

Теперь, сконфигурировав список IP, нужно предоставить информацию ACS о нашем веб-сайте. На жаргоне идентификации приложения часто называют доверяющими сторонами (relying parties, RP), подразумевая, что приложение полагается в аутентификации на один или более IP. ACS UI соответствует этой терминологии.

Щелкните Relying Party Applications, а затем Add Relying Party Application. Укажите следующую информацию:

• Name: My Website
• Realm: https://localhost/Website/
• Return URL: https://localhost/Website/
• Token format: SAML 2.0
• Token signing: Use service namespace certificate (typical)

Поле Token Format заслуживает хотя бы краткого пояснения (подробнее о нем мы поговорим позже). Маркер (token) — это артефакт (обычно XML-фрагмент или нечто в другом сериализуемом формате), используемый IP, чтобы сообщить об успешной операции аутентификации. После аутентификации пользователя через любую систему, выбранную IP, браузер будет переадресован к ACS с маркером, удостоверяющим, что данный пользователь опознан. Формат маркера и протокол определяются согласно IP. ACS анализирует маркер и, если находит его удовлетворительным (подробности позже), выдает новый, собственный маркер и посылает его вашему приложению. Настройки, которые вы изменяете на этом этапе, определяют, какой формат маркера должен использовать ACS при обратном взаимодействии с вашим приложением. ACS способен генерировать маркеры трех форматов — SAML 2.0, SAML 1.1 и SWT, — представляющие различные компромиссы между безопасностью, применимостью для некоторых типов клиентов и т. д. Здесь просто выберите SAML 2.0; такие детали для нас не важны.

Важно, чтобы область (realm) соответствовала URL для ранее созданного веб-сайта. Как только происходит аутентификация в выбранном IP, ACS перенаправляет пользователя обратно на ваш веб-сайт по указанному вами URL. Заметьте, что по умолчанию выбирается Create New Rule Group (мы используем это на следующем этапе). Щелкните Save и вернитесь на портал управления.

Добавление правил

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

Щелкните ссылку Identity Providers. Вы должны увидеть группу правил Default Rule Group for My Website, созданную, когда мы добавили приложение как доверяющую сторону. Выберите эту группу, щелкните ссылку Generate Rules, подтвердите, что выбираются и Google, и Windows Live ID, а затем щелкните кнопку Generate — вот и все, что нужно в отношении правил в этом сценарии.

Получение адреса WS-Federation Metadata

К этому моменту мы закончили с конфигурированием ACS. Однако, прежде чем перескакивать обратно в Visual Studio, давайте посмотрим информацию на странице Application Integration. Щелкните ссылку Application Integration и скопируйте URL «WS-Federation Metadata» — мы используем это в WIF для нашей веб-страницы.

Не вдаваясь в детали, документ WS-Federation Metadata — это машинно-читаемое описание того, как ACS обрабатывает аутентификацию. Это понадобится для того, чтобы ваше приложение можно было настроить на делегирование аутентификации в ACS.

Настройка веб-сайта на использование ACS

Вернемся в Visual Studio и к веб-сайту. Мы теперь хотим задействовать WIF для делегирования аутентификации в ACS, который в свою очередь разрешает обращаться к нашему приложению по учетным записям Google. В Solution Explorer щелкните правой кнопкой мыши проект веб-сайта и выберите Add STS Reference. Это приведет к запуску мастера Federation Utility, который сконфигурирует веб-сайт на использование WIF в качестве механизма аутентификации и ACS в качестве центра аутентификации. STS расшифровывается как «Security Token Service»; это особый вид веб-сервиса или веб-страницы, которая служит входной точкой для запроса маркеров; обычно у каждого IP или издателя маркеров есть хотя бы один такой сервис.

По большей части вы можете просто щелкать кнопку Next; этапов, на которых вам потребуется вводить какую-то информацию, очень мало. Пройдите до этапа Security Token Service и укажите Use an existing STS. Вставьте URL метаданных федерации, который вы скопировали с портала ACS (рис. 4).

Рис. 4 Запуск мастера Federation Utility в Visual Studio

С этого момента соглашайтесь с настройками по умолчанию, пройдите оставшуюся часть мастера, нажимая Next и, наконец, щелкните Finish. Мастер добавит все необходимые сборки WIF, некоторые файлы на ваш веб-сайт и (что самое главное) обновит ваш web.config информацией, необходимой для участия ACS в ходе аутентификации.

Проверка потока аутентификации

Наконец настал момент опробовать в работе только что защищенный веб-сайт! Нажмите F5. Вы будете немедленно перенаправлены на страницу Home Realm Discovery, которая дает пользователю шанс выбрать конкретного IP из числа ранее сконфигурированных на портале управления ACS (рис. 5).

Рис. 5 Страница Home Realm Discovery

Выбрав Google и введя удостоверения своей учетной записи в Google, вы увидите страницу, где предлагается разрешить доступ из проекта ACS к вашей учетной записи (важно понимать, что разрешение запрашивает не ваш веб-сайт, а сервис ACS) (рис. 6).

Рис. 6.Сервис Windows Azure AppFabric Access Control Service запрашивает разрешение на получение информации от Google

Разрешив ACS необходимый ему доступ, вы вновь попадете на свой веб-сайт (рис. 7). Вот и все — вы вошли!

Рис. 7 Успех! Вход на веб-сайт состоялся

Если вы хотите проверить то же самое с Windows Live ID, просто закройте браузер, вновь нажмите F5 и на странице Home Realm Discovery выберите Windows Live ID вместо Google.

Если у вас есть опыт поддержки протоколов аутентификации на веб-сайтах, то вы знаете, что традиционно добавление нового IP требовало изучения его протоколов и API, написания весьма сложного кода и тестирования/отладки до тех пор, пока все не начнет работать правильно. И так с каждым дополнительным IP.

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

ACS: структура и механизмы

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

ACS работает согласно принципам идентификации на основе заявок (claims-based identity). Основная идея, стоящая за этим принципом, состоит в том, что каждая сущность в транзакции идентификации играет одну или более канонических ролей (всего их четыре): субъект (subject), провайдер идентификации (identity provider, IP), доверяющая сторона (relying party, RP) и провайдер федерации (federation provider, FP). В предыдущем сценарии мы видели их все в действии. Взаимодействие между этими сущностями сводится к запросу, получению и пересылке маркеров защиты, как показано на рис. 8.

Увеличить

Рис. 8 Запрос, получение и пересылка маркеров защиты

Роль субъекта играет пользователь, т. е. это сущность, которую нужно аутентифицировать. IP — сущность, которая хранит учетную запись для субъекта: имя пользователя, учетные данные, атрибуты и т.д. IP использует один или более сервисов STS для доступа к своим средствам аутентификации и для выдачи маркеров. RP — это приложение, которым хочет воспользоваться субъект. Этих трех ролей достаточно для описания наиболее базового случая: субъект получает маркер от IP, которому доверяет RP, использует этот маркер в RP, и аутентификация завершена.

Но одну вещь мы не охватили в предыдущем сценарии.Дело в том, что маркеры не только представляют успешный результат операции аутентификации, но и используются для транспорта атрибутов, описывающих пользователя: имени, адреса электронной почты, ролей и чего угодно другого, что нужно знать RP и что IP делает доступным. Если вы помните свойства подписанного маркера защиты, то увидите, что третья сторона не может модифицировать эти атрибуты и что они контролируются на предмет получения от конкретного IP. То есть RP может считать корректными получаемые атрибуты в той мере, насколько она доверяет IP, от которого они исходят. Возьмите ситуацию из реальной жизни, когда вам нужно что-то доказать, например что вы действительно проживаете по определенному адресу. В компаниях часто просят вас предоставить счет за коммунальные услуги главным образом потому, что больше доверяют муниципальному предприятию, чем вам. Информация одна и та же (адрес), но вся разница в том, что она исходит от IP.

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

Хотя для моделирования любой системы можно было бы использовать роли «субъект-RP-IP», на практике это не слишком удобно. Если одна RP доверяет нескольким IP, как в нашем сценарии, эта модель потребовала бы от RP поддержания множества взаимосвязей, обрабатывать разные протоколы и др. Вот тут на сцену и выходит четвертая роль — FP. То есть FP является посредником между одной или более RP и одним или более IP, как показано на рис. 9.

Увеличить

Рис. 9. Провайдер федерации в качестве посредника

FP доверяет нескольким IP, ведет себя подобно приложению и ожидает маркеры от IP. В свою очередь RP доверяет FP; для этого FP предоставляет свой сервис STS, который выдает маркеры для RP. FP берет на себя детали работы с различными IP, в то же время всегда предоставляя RP один фасад, поэтому IP можно добавлять и удалять, не влияя на RP. FP также может преобразовывать заявки, поступающие от разных IP, и делать их более полезными RP. Он умеет нормализовать различные типы входящих заявок, включать дополнительные заявки вроде ролей или разрешений и т. д.

Как вы, вероятно, уже догадались, ACS играет роль FP (рис. 10).

Увеличить

Рис. 10. Сервис Windows Azure AppFabric Access Control Service играет роль провайдера федерации

Когда вы создаете пространство имен сервиса, вы получает собственный полнофункциональный провайдер федерации в облаке. В готовом виде этот FP включает четыре конечные точки STS, каждая из которых предлагает свои протоколы, подходящие для приложений разных типов: WS-Federation (для входа на веб-сайты), WS-Trust (для вызова веб-сервисов SOAP), OAuth WRAP и OAuth 2 (для веб-сервисов REST) и Web API для универсальных целей. Эти конечные точки вы используете при настройке своего приложения на делегирование аутентификации.

ACS заранее настроен на доверие к различным IP, и это облегчает их выбор. Кроме того, ACS способен устанавливать доверительные отношения с коммерческими IP, такими как Active Directory Federation Services 2.0 (AD FS 2.0), которые сами предоставляют конечные точки STS. На практике ACS предоставляет эквивалент функциональности «Add STS reference», которую вы видели при настройке веб-сайта на доверие ACS. Применение AD FS 2.0 как IP крайне интересно, так как позволяет вам в любой момент повторно использовать учетные записи пользователей, в том числе находящиеся в приложениях, размещенных в Windows Azure. Другая интересная особенность коммерческих IP заключается в том, что они обычно предоставляют гораздо более обширный набор заявок, который можно задействовать для добавления сложной, управляемой идентификациями логики в обработке маркеров.

ACS позволяет описывать ваши заявки в виде правил — это простой, но эффективный механизм. Например, вы можете назначить роль пользователю, просто введя нечто вроде «если входящая заявка идентификатора имени (incoming name identifier claim) имеет значение X, добавить исходящую заявку роли такого-то типа со значением Y».

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

Как бы банально это ни звучало, мы едва коснулись обширных возможностей ACS. Приглашаем вас к изучению Identity Developer Training Kit и Windows Azure Platform Training Kit для более детального исследования более широкого круга сценариев. Если вы хотите упростить управление доступом к своему веб-сайту, веб-сервису или Web API, то ACS поможет и в этом!