Руководство по Microsoft® .NET Access Control Service для разработчиков

                                                                                  

Управление доступом в облаке

Кейт Браун, Pluralsight

Май 2009

Содержание

Аннотация

Обзор .NET Access Control Service

     Вопросы идентификации

     Лучший вариант решения – Microsoft .NET Access Control Service

     Модель идентификации на основании утверждений

Введение в идентификацию на основании утверждений

     Терминология идентификации на основании утверждений

          Удостоверение/идентификация

          Утверждение

          Маркер доступа

          Служба сертификации и провайдер удостоверений

          Сервис маркеров доступа (STS)

          Участвующая сторона (RP)

     Простой сценарий с использованием утверждений и SOAP

     Стандарты

     Приложения, выполняющиеся в браузере

     Связанные издатели

     Интеграция удостоверений для разных областей безопасности

Понимание .NET Access Control Service

     Начало работы с ACS

     ACS в действии: пример сервиса Calculator

Настройка .NET Access Control Service

     Учетные записи и решения

     Области действия решения

     Параметры области действия

     Издатели удостоверений

     Типы утверждений

     Преобразование утверждений

Реализация управления доступом на основании ролей (RBAC)

Примеры пассивных сценариев

     Интеграция ACS в веб-приложение ASP.NET

     Код Contoso Woodworking

Управление через AtomPub

Заключение

Дополнительные ресурсы

     Пакеты документов по Microsoft® .NET Services

     Ресурсы .NET Access Control Service

Об авторе

Благодарности

Аннотация

Цель этого документа – показать разработчикам, как с помощью модели идентификации на основании утверждений и Microsoft® .NET Access Control Service, части семейства сервисов Microsoft® .NET Services, реализовывать интегрированную идентификацию с единой регистрацией и управление доступом на основании ролей в веб-приложениях и сервисах.

Поскольку лучшим средством интеграции этого сервиса в ваши приложения является инфраструктура Geneva Framework, настоятельно рекомендуется, прочитав этот документ, ознакомиться с «Geneva» Framework whitepaper (Документация Geneva Framework).

Обзор .NET Access Control Service

Microsoft® .NET Services1 – это набор высокомасштабируемых ориентированных на разработчика сервисов, выполняющихся в центрах обработки данных Microsoft как часть платформы Azure™ Services Platform. Microsoft .NET Services предоставляет разработчикам основные стандартные блоки и инфраструктуру сервисов для приложений в облаке и работающих с облаком. Во многом аналогично тому, как .NET Framework обеспечивает основные стандартные блоки для разработки локального ПО, Microsoft® .NET Services предлагает основные стандартные блоки для приложений в облаке.

Microsoft® .NET Access Control Service – один из основных сервисов, предлагаемых в составе Microsoft® .NET Services. Сегодня его дополняют два других сервиса: Microsoft® .NET Service Bus и Microsoft® .NET Workflow Service. .NET Service Bus полагается на Access Control Service в управлении доступом к решениям Azure через модель безопасности на базе утверждений. .NET Workflow Service позволяет описывать рабочие процессы в облаке, моделирующие взаимодействия с сервисами через .NET Service Bus. Совместно эти сервисы обеспечивают полноценную среду разработки, необходимую большинству приложений в облаке. Они предоставляют разработчику возможность сосредоточить внимание исключительно на бизнес-требованиях, таким образом, упрощая разработку для облака.2

Данный документ посвящен реализации модели идентификации на основании утверждений с использованием .NET Access Control Service для поддержки интегрированной идентификации с единой регистрацией и управления доступом на основании ролей. Сначала рассмотрим основные термины и принципы, которые важны для понимания идентификации на основании утверждений, и уже после этого более детально поговорим об ACS.

1 Microsoft® .NET Services – новое более подходящее имя инициативы, изначально называвшейся BizTalk Services.

2  Более подробно Microsoft® .NET Services, .NET Access Control Service и .NET Workflow Service рассматриваются в сопутствующих документах серии «Пакеты документов по Microsoft .NET Services», ссылки на которые можно найти в конце данного документа.

Вопросы идентификации

Первые два вопроса, на которые сегодня приходится отвечать большинству приложений, касаются идентификации: кем является пользователь и что ему разрешено делать? Аутентификация и авторизация необходимы различным типам приложений, начиная от веб-сервисов и приложений, выполняющихся в браузере, заканчивая насыщенными настольными приложениями Windows и консольными приложениями командной строки. Но несмотря на такую глобальную потребность в этих возможностях, зачастую приложения используют собственные специальные решения. Большинство разработчиков не являются экспертами в области безопасности и чувствуют себя неуверенно при реализации задач по аутентификации, авторизации и персонификации пользователей. Эти вопросы не рассматриваются в обычном курсе программирования и часто игнорируются во всем процессе разработки вплоть до самых поздних этапов.

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

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

Лучший вариант решения – Microsoft .NET Access Control Service

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

Microsoft® .NET Access Control Service – это сервис в облаке, выполняющий именно это. Вместо того чтобы создавать собственную базу данных учетных записей и ролей, можно поручить ACS управление аутентификацией и авторизацией своих пользователей. ACS использует существующие хранилища учетных записей пользователей, такие как Windows Live ID, Active Directory, а также любые другие хранилища, поддерживающие стандартные протоколы интеграции, о которых мы поговорим немного позже. Это делает естественным использование единой регистрации для всех приложений, а также является замечательным способом централизации логики аутентификации и управления доступом, что упрощает приложения.

3 Фишинг заключается в вынуждении пользователя к разглашению конфиденциальных данных (таких как пароли). Обычно это делается путем отправки электронного письма, якобы от лица легальной компании, в которой пользователь может иметь учетную запись. Это электронное письмо включает ссылку, которая приводит на веб-сайт злоумышленников, внешне похожий на официальный веб-сайт данной компании. Когда пользователь «регистрируется», его пароли и другая информация, которую удастся выманить, попадает к злоумышленникам.

Модель идентификации на основании утверждений

При работе с приложениями, поддерживающими утверждения, пользователь предоставляет удостоверения в виде набора утверждений (рис. 1). Одно утверждение может быть именем пользователя, другое – адресом его электронной почты, и т.д. Эти утверждения предоставляются службой сертификации, которая знает, как аутентифицировать пользователя и где взять его атрибуты. Клиентское приложение, в роли которого может выступать браузер или насыщенный клиент, прозрачно взаимодействует с этой службой, получая эти утверждения и передавая их в ваше приложение. В конечном итоге, ваше приложение получает все необходимые данные удостоверения пользователя в виде набора утверждений. Кроме того, утверждения подписаны, что обеспечивает криптографическую гарантию их происхождения.

                               

                         Web App/Service

                 Веб-приложение/Сервис

                                              Рис. 1: Пользователь предоставляет утверждения

Использование такой модели позволяет обеспечить единую регистрацию. Кроме того, приложение больше не отвечает за:

  • Аутентификацию пользователей
  • Хранение учетных записей пользователей и паролей
  • Обращения к каталогам предприятия в поисках данных удостоверения пользователя
  • Интеграцию с системами идентификации других платформ или компаний

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

Введение в идентификацию на основании утверждений

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

Терминология идентификации на основании утверждений

Для описания идентификации на основании утверждений обычно используется несколько терминов, включая идентификация и удостоверение (identity), утверждение (claim), маркер доступа (security token), служба сертификации (issuing authority), служба маркеров доступа (security token service, STS) и участвующая сторона (relying party). Важно четко понимать эти термины, прежде чем переходить к детальному рассмотрению ACS.

Удостоверение/идентификация

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

Утверждение

Утверждение можно рассматривать как элемент удостоверяющих данных, таких как имя, адрес электронной почты, возраст, принадлежность к определенной роли и т.д. Чем больше утверждений получает приложение, тем больше вы будете знать о пользователе, от которого поступил запрос. Возможно, возникнет вопрос, почему используется термин «утверждение», а не более традиционный «атрибут», обычно применяемый в мире каталогов предприятий. Причина в методе доставки: в данной модели приложение не ведет поиск атрибутов пользователя в каталоге, напротив, пользователь предоставляет утверждения приложению, и вы проверяете их с определенной степенью недоверия. Утверждения подписаны издателем (issuer), и вы доверяете этому набору утверждений настолько, насколько доверяете этому издателю. Частью принятия утверждения является проверка того, действительно ли оно поступило от издателя, которому вы доверяете. Для этого придется повозиться с криптографией, что можно реализовать самостоятельно, используя средства .NET Framework, но, как будет показано ниже в данном документе, WCF, Geneva Framework и ACS прекрасно сделают это за вас, предоставляя возможность сосредоточиться на выборе надежного провайдера удостоверений.

Маркер доступа

Пользователь предоставляет набор утверждений вместе с запросом. В веб-сервис эти утверждения поступают в заголовке безопасности конверта SOAP. В веб-приложение, выполняющееся в браузере, утверждения передаются через HTTP-запрос POST браузера пользователя и могут использоваться для установления обычного сеанса регистрации на базе cookie. Независимо от способа доставки утверждения должны быть каким-то образом сериализованы. Вот здесь пригодятся маркеры доступа. Маркер доступа – это набор утверждений, сериализованный в XML (чаще всего как SAML4), и подписанный цифровой подписью службой сертификации. Подпись имеет важное значение, потому что является гарантом того, что эти утверждения выданы службой сертификации, а не являются просто набором самостоятельно скомпонованных пользователем утверждений.

4 SAML (Security Assertion Markup Language) – Язык разметки утверждений безопасности. Это словарь XML, предназначенный для представления утверждений. Маркеры SAML используются в отрасли уже много лет, как в системах Microsoft .NET, так и в системах Java.

Служба сертификации и провайдер удостоверений

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

Существует множество служб сертификации, включая Windows Live ID, Geneva Server (продукт, использующий Active Directory в качестве хранилища данных пользователей), PingFederate от Ping Identity (продукт, представляющий удостоверения пользователей из мира Java) и многие другие.

Некоторые службы сертификации, такие как Windows Live ID, занимаются исключительно идентификацией пользователей. Их задача состоит в аутентификации пользователя и выпуске SAML-маркера с ID пользователя и, возможно, другими атрибутами удостоверения. Службы сертификации такого типа называются провайдерами удостоверений (иногда используется сокращение IdP). В конечном счете, они отвечают на вопрос «кто вы?» и гарантируют, что пользователь знает свой пароль, является владельцем смарт-карты, знает PIN-код, имеет соответствующие результаты сканирования радужной оболочки глаза и т.д.

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

ACS также является службой сертификации, и хотя в CTP-версии ACS временно выполняет функцию провайдера удостоверений, на самом деле, это не его задача. Скорее, задача ACS – обеспечивать набор утверждений, предназначенных конкретному приложению. Это означает преобразование утверждений, поступающих от провайдера удостоверений, такого как Geneva Server или Windows Live ID, в набор ролей и других утверждений, имеющих значение для конкретного приложения. Приложению, возможно, абсолютно не интересно имя пользователя, но чрезвычайно важно знать, какие функции он имеет право использовать.

Большую часть ACS составляет его административная система. ACS имеет административный веб-портал, попасть на который можно через браузер, зарегистрировавшись на нем (и выполнив вход)6. На этом портале выполняется настройка правил, определяющих, как ACS будет выпускать утверждения для различных пользователей, и, в конечном счете, отвечать на вопрос, что они могут делать. Портал представлен на рис. 2.

5 Не путать с WS-Policy.

6 ACS также включает конечные точки SOAP и REST для программного администрирования, а также набор классов .NET, упрощающих использование этих конечных точек. Таким образом, можно создать собственную консоль администрирования, если вас не устраивает предоставляемая ACS или если есть желание провести настройку соответственно предметной области.

                                                 

                                                                                  Рис. 2: Портал ACS

Сервис маркеров доступа (STS)

Сервис маркеров доступа (security token service, STS) – это инфраструктура, создающая, подписывающая и выпускающая маркеры доступа, соответственно протоколам, обеспечивающим возможность взаимодействия, которые будут рассматриваться в одном из последующих разделов под названием «Стандарты». Любопытно, что всю эту ответственную работу ACS выполняет с помощью Geneva Framework.

Говоря более сухим техническим языком, STS является реализацией WS-Trust, которая принимает Запросы на получение маркера (Request for Token, RST) и возвращает ответ (RSTR). Но в литературе службу сертификации все чаще называют STS, даже если WS-Trust не применяется (как, например, в пассивных сценариях доступа через браузер). Я не собираюсь заниматься этими тонкостями в данном документе. Таким образом, термин STS просто следует рассматривать как элемент службы сертификации, фактически отвечающий за выпуск маркеров.

Участвующая сторона (RP)

При создании приложения, работающего с утверждениями, фактически, создается участвующая сторона. Такие приложения также называют поддерживающими утверждения приложениями (claims aware application) или работающими с утверждениями приложениями (claims-based application). Я привожу здесь это определение, главным образом, потому что оно встречается в литературе. ACS ориентирован исключительно на построение приложений, выступающих в роли участвующих сторон, поэтому чтобы не говорить слишком сухим техническим языком, я будут называть создаваемые приложения просто «приложениями».

Простой сценарий с использованием утверждений и SOAP

После рассмотрения терминологии можно перейти к примеру универсальной системы, использующей утверждения, в действии.

                                                 

                                Issuing Authority

                         Служба сертификации

                                   Smart Client

                                 Смарт-клиент

                        Application (Web Service)

                      Приложение (веб-сервис)

                         Active Client (WS-Trust)

                    Активный клиент (WS-Trust)

                            1. Get WSDL

                            1. Получение WSDL

                            2. Get Claims

                    2. Получение утверждений

                           3. Send Claims

                       3. Отправка утверждений

                                                  Рис. 3: Базовый сценарий с веб-сервисами

На рис. 3 представлено поддерживающее утверждения приложение (так получилось, что оно является веб-сервисом) и смарт-клиент, желающий использовать это приложение. Приложение предоставляет WSDL7, описывающий его адреса, привязки и контракты. Раздел политики в WSDL включает список утверждений, необходимых приложению, например, имя пользователя, адрес электронной почты и членство в роли. Также политика обеспечивает смарт-клиенту адрес STS службы сертификации, по которому смарт-клиент должен обращаться для получения этих утверждений.

Ознакомившись с политикой приложения (1), клиент знает, куда направляться для аутентификации. Смарт-клиент делает запрос WS-Trust (2) к STS для получения необходимых приложению утверждений. Работа STS заключается в аутентификации пользователя и возвращении маркера доступа со всеми необходимыми утверждениями. После этого смарт-клиент отправляет свой запрос приложению (3), включая маркер доступа в SOAP-заголовок безопасности. Теперь приложение может с помощью такой инфраструктуры как WCF или Geneva Framework проверить достоверность подписи маркера. Данное конкретное приложение принимает только запросы, содержащие маркер, подписанный службой сертификации, которой оно доверяет; все остальные запросы отклоняются.

7 WSDL – Web Service Description Language (язык описания веб-сервисов).

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

Стандарты

Возможность взаимодействия всех этих элементов обеспечивается несколькими стандартами WS-*. WSDL извлекается с помощью WS-MetadataExchange или простого HTTP-запроса GET, и политика в WSDL структурирована соответственно спецификации WS-Policy. STS службы сертификации предоставляет конечную точку, реализующую спецификацию WS-Trust8, которая описывает процессы запроса и получения маркеров доступа.

Еще один важный стандарт – SAML, Security Assertion Markup Language. Это принятый в отрасли словарь XML, который может использоваться для представления утверждений в форме, обеспечивающей возможность взаимодействия. ACS в качестве входных данных принимает маркеры SAML от провайдеров удостоверений и как выходные данные выпускает SAML-маркеры для ваших приложений.

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

Приложения, выполняющиеся в браузере

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

8 На момент написания данного документа последней версией WS-Trust является 1.3. Чтобы использовать ACS, инфраструктура веб-сервисов, как на клиенте, так и на сервере, должны поддерживать эту версию. Microsoft поддерживает WS-Trust 1.3, а также Geneva Framework, в WCF версии 3.5 и последующих. WS-Trust 1.3 также поддерживаются и в Java-мире (Metro является одним из примеров).

9 Смарт-клиентов называют «активными», потому что они имеют инфраструктуру (WCF, например), которая может производить синтаксический разбор политики и реализовывать WS-Trust напрямую. Веб-браузеры являются «пассивными», потому что они ничего не знают о политике и WS-Trust, поэтому для передачи утверждений от издателя в приложение используются специальные методики, такие как строки запросов, перенаправление и javascript, с привлечением SSL для снижения риска атак, таких как спуфинг серверов, несанкционированный перехват данных и повреждение или подделка.

Служба сертификации управляет аутентификацией пользователя. В некоторых случаях она может делать это напрямую (ACS поддерживает это временно в бета-версии), или может еще раз перенаправлять браузер на веб-страницу, предоставленную провайдером удостоверений, таким как Windows Live ID.

Как только пользователь аутентифицирован, служба сертификации выясняет, какие утверждения должны быть выпущены, комплектует их в SAML-маркер и подписывает его закрытым ключом. После этого SAML-маркер кодируется в ответ вместе с некоторым java-сценарием. При поступлении ответа в браузер пользователя этот сценарий обеспечивает автоматическую отправку маркера в приложение посредством HTTP-запроса POST. Если приложение желает установить сеанс входа для пользователя, обычно оно формирует cookie, чтобы пользователю не приходилось обращаться к провайдеру удостоверений при каждом запросе. Спецификация WS-Federation включает раздел10, в котором описывается, как сделать все это, обеспечивая взаимодействие.

Находите на рис. 3 сходные моменты с примером веб-сервиса? Клиент точно так же обращается к службе сертификации для получения утверждений и затем отправляет их приложению.

В этот пример добавлена лишь потенциальная возможность наличия нескольких служб сертификации. Например, приложение могло бы сначала перенаправляться на ACS, который затем направлял бы его к Windows Live ID. Это может применяться и к веб-сервисам. В этом случае, путь, преодолеваемый смарт-клиентом, определялся бы политикой приложения и всех участвующих издателей.

10 Чтобы быть точным, раздел 13. Вероятно, вы встречали, что ранее его называли профилем пассивной запрашивающей стороны (passive requestor profile), но на момент написания данного документа последняя версия WS-Federation больше не использует этот термин.

                                                  

                                 Issuing Authority
                                Web Page

                               Служба сертификации
                               Веб-страница

                                        Browser

                                      Браузер

                          Application (Web App)

                Приложение (веб-приложение)

                       Passive Client (WS-Trust)

                   Пассивный клиент (WS-Trust)

                             1. HTTP GET

                           1. HTTP-запросGET

                             2. Redirect

                           2. Перенаправление

                             3. HTTP POST

                           3. HTTP-запрос POST

                                                   Рис. 4: Базовый сценарий для веб-браузера

Связанные издатели

На момент написания данного документа ACS существует в версии Community Technology Preview (CTP)11. Для простоты он может выполнять роль провайдера удостоверений: вы можете задавать имена пользователей и пароль, которые будут использоваться ACS для аутентификации конечных пользователей. Но эта возможность является временной мерой, и в окончательной версии ее не будет.

В какой-то момент понадобится сообщить ACS, какой внешний провайдер удостоверений желает использовать приложение, будь то Windows Live ID или какой-то другой провайдер, возможно, Geneva Server. При этом в результате может получиться так, что необходимые приложению утверждения выпускают разные издатели. Тогда они объединяются в цепочку связанных издателей. В данном конкретном примере причиной использования нескольких служб сертификации является простое разделение задач: ACS не должен заниматься аутентификацией пользователей, он должен быть механизмом преобразования утверждений, который может использоваться для реализации управления доступом на основании ролей, персонализации и т.д. ACS уступит ответственность по аутентификации пользователей любому выбранному вами провайдеру.

11 Предварительная версия для сообщества (прим. переводчика).

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

Интеграция удостоверений для разных областей безопасности

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

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

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

Через некоторое время, возможно, Боб начинает сотрудничать со многими производителями велосипедов, каждый из которых имеет собственный механизм закупок. Некоторые используют Интернет, некоторые полагаются на факс и телефонные звонки. Боб запросто может забыть обо всех этих незначительных деталях, ведь основная его задача – продажа велосипедов. Поэтому при появлении нового сотрудника, Алисы, Бобу может забыть о том, что он должен позвонить в Fabrikam (и всем остальным производителям) и попросить их предоставить Алисе право делать закупки. Первые несколько рабочих недель Алисы напоминают страшный сон, потому что ей приходится запоминать все пароли, необходимые для доступа к разным системам, которые она будет использовать, и потому что ей запрещен доступ к сайту Fabrikam до тех пор, пока Боб не найдет время позвонить в Fabrikam и добавить Алису как пользователя.

А что если роль Алисы в компании Боба меняется или, что еще хуже, она увольняется? Когда Fabrikam станет известно об этом?

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

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

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

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

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

                                                       

                                    Bob’s shop

                                  Магазин Боба

                                  Bob’s Issuer

                                Издатель Боба

                               Fabrikam Issuer

                            Издатель Fabrikam

                                          Client

                                        Клиент

                                   Application

                                  Приложение

                                                  Рис. 5: Интеграция магазина Боба с Fabrikam

Как видно на рис. 5, клиент находится в одной области безопасности (магазин Боба), тогда как приложение располагается в центре обработки данных Fabrikam. В данном случае клиент (скажем, Алиса) проходит аутентификацию у издателя Боба (1) и получает маркер доступа, который может отправить Fabrikam. Этот маркер свидетельствует о том, что Алиса аутентифицирована средой безопасности Боба, и включает утверждения, указывающие на то, какие роли она исполняет в организации Боба.

Клиент оправляет этот маркер издателю Fabrikam, который рассматривает утверждения, принимает решение о том, что Алисе должен быть предоставлен доступ к заданному приложению, и выдает второй маркер доступа, содержащий утверждения, необходимые приложению. Клиент отправляет этот второй маркер, содержащий все необходимые удостоверяющие данные об Алисе, приложению (3), и может спокойно разрешить ей доступ к приложению, соответственно утверждениям, полученным от издателя Fabrikam.

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

Итак, а где же здесь место для ACS? Возвращаясь к рис. 5, Fabrikam могла бы использовать ACS как службу сертификации, а Боб мог бы использовать Geneva Server для аутентификации своих клиентов и выпуска маркеров доступа для них. Как видите, при создании приложения с использованием ACS сразу же появляется возможность принимать пользователей из других организаций без изменения своих приложений! ACS поможет также персонализировать приложение в зависимости от области безопасности пользователя.

                                                            

                                    Java Users

                            Java-пользователи

                                    Java Issuer

                                Java-издатель

                                         Client

                                      Клиент

                                     .NET Apps

                             .NET-приложения

                                     .NET Issuer

                                 .NET-издатель

                               .NET Application

                             .NET-приложение

                                     Рис. 6: Межплатформенная интеграция удостоверений

Рассмотрим другой сценарий. На рис. 6 показана компания, создающая свои приложения с использованием Microsoft .NET Framework. Недавно она объединилась с другой компанией, ИТ-платформа которой основана на Java. Поскольку изначально приложения создавались для работы с утверждениями, рассматриваемая компания смогла установить издателя на базе Java. И неожиданно приложения Microsoft .NET стали доступными пользователям Java приложений, и для этого в приложения не пришлось вносить никаких изменений.

Возможности межплатформенного взаимодействия выходят далеко за рамки этого примера. Так случилось, что ACS написан с использованием Microsoft .NET и Geneva Framework, но ничто не мешает реализовать его с помощью Java или какой-либо другой технологии. Каждый из представленных на рис. 6 четырех компонентов мог бы быть построен на совершенно разных платформах и технологиях. Единственное условие при этом – все участвующие стороны должны следовать стандартам для интегрированной идентификации (WS-Trust и WS-Federation). Если приложение спроектировано на использование ACS, нет никаких причин, по которым нельзя было бы перейти к другому больше понравившемуся издателю, даже если он построен не на платформе Microsoft. Основная идея мира интегрированной идентификации – возможность взаимодействия, и команда ACS делает все, чтобы реализовать этот идеал.

Понимание .NET Access Control Service

ACS включает три основных составляющих: сервис маркеров доступа, который выпускает маркеры доступа; портал администрирования – пользовательский веб-интерфейс, который позволяет конфигурировать настройки, определяющие структуру маркеров; и API администрирования. Данный документ не обсуждает API администрирования, потому что сейчас он подвергается существенным изменениям. Но достаточно сказать, что все, что можно сделать через портал администрирования, можно будет делать через API администрирования, который будет включать как REST, так и SOAP конечные точки, а также набор .NET-классов для работы с этими конечными точками.

Начало работы с ACS

Чтобы начать использовать CTP-версию ACS, необходимо создать решение (как это делается рассказывается в вводном документе). Создавая решение, по сути, вы создаете собственную частную службу сертификации в ACS, имеющую собственный частный набор конечных точек и соответствующих URL. Имя решения становится частью URL, как будет показано позже.

ACS в действии: пример сервиса Calculator

Лучший способ во всем разобраться – увидеть ACS в действии. Итак, в данном разделе мы рассмотрим один из примеров, входящих в пакет .NET Services SDK, под названием UserNamePasswordCalculatorService.

В этом примере ACS используется для обеспечения безопасности простого WCF-сервиса, предлагающего четыре операции: Add (Сложение), Subtract (Вычитание), Multiply (Умножение) и Divide (Деление). Сервис вычислений в данном примере не интересует имя пользователя, адрес его электронной почты или другие личные данные. Для него важно лишь то, чтобы пользователь, выполняющий запрос на сложение (например), имел право выполнять сложение. Я покажу, как конфигурировать решение в ACS для управления доступом к этим операциям. Чтобы этот пример работал, необходимо сначала создать «решение» в ACS. Более подробно о том, какое это должно быть решение, поговорим немного позже. Пока что просто рассматривайте его как персональный издатель маркеров доступа в облаке. В качестве примера я буду использовать решение под именем «asolution».

Сервис вычислений – это приложение, которое принимает решения, связанные с безопасностью, на основании утверждений, изданных ACS. Таким образом, этот сервис, как любое другое работающее с утверждениями приложение, должен иметь собственный сертификат X.509, который может использоваться ACS для шифрования маркеров доступа, предоставляемых сервису. В примере предлагается простой тестовый сертификат localhost.cer. Именно его я буду использовать для начала.

В подкаталоге Utils данного примера содержится сертификат и командный файл (installcerts.bat), который устанавливает его в хранилище личного сертификата локального компьютера. Я выполнил этот командный файл, чтобы установить localhost.pfx на компьютер, на котором будет выполняться сервис, поскольку сервису потребуется доступ к закрытому ключу для дешифрования маркеров, выпускаемых ACS.

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

  1. Его имя (URI, который будут использовать клиенты для идентификации приложения)
  2. Его сертификат (ACS необходим открытый ключ для шифрования выпускаемых им маркеров)
  3. Правила, согласно которым ACS должен выпускать утверждения

Итак, я перешел к accesscontrol.windows.net и зарегистрировался. Затем выбрал свое решение («asolution»). Это позволило мне добавить новую область действия, как показано на рис. 7. Область действия представляет настройки приложения, более подробно поговорим о нем чуть позже. На данный момент необходимо просто знать, что для каждой области должен быть задан URI, что позволяет отличать ее от остальных областей действия приложения.

          

                                        Рис. 7: Добавление области действия в решение ACS

По нажатию кнопки Save (Сохранить) на экран выводится список имеющихся областей действия. После этого я выбрал «Manage» (Управлять) и «Encryption» (Шифрование), чтобы загрузить сертификат для своего приложения. Далее я перешел на страницу правил, на которой я настроил несколько очень простых правил для приложения. Клиентская программа сервиса Calculator для аутентификации в ACS использует имя пользователя и пароль. Как будет показано в данном документе далее, каждое решение ACS имеет пароль, т.е. для аутентификации в ACS имя решения может использоваться как имя пользователя, и его пароль – как пароль. Итак, задавая свои правила, я указываю ACS предоставлять разрешения на сложение, вычитание, умножение и деление только пользователям, предоставившим правильное имя пользователя и пароль решения.

На рис. 8 представлен результирующий набор правил.

                                     

                                                  Рис. 8: Правила для приложения Calculator

По сути своей, ACS – это механизм преобразования утверждений, и это можно увидеть, взглянув на правила на рис. 8. Все заданные правила ожидают одно и то же входящее утверждение: утверждение «UserName» (Имя пользователя) со значением «asolution», выпущенное ACS. Единственная возможность пользователю получить это утверждение от ACS – предоставить имя решения и соответствующий пароль при запросе маркера доступа. Эти четыре правила гарантируют, что любой пользователь, подтвердивший знание пароля для моего решения, получит четыре утверждения «Action» (Действие). Утверждение «Action» содержит строку, определяющую действие. Это может быть все, что угодно: «foo», «1234» или «Calculator.Divide».

Итак, как эти утверждения используются в сервисе Calculator? Сервис просто проверяет маркер доступа, предоставленный клиентом, и убеждается в наличии соответствующего действия (рис. 9).

public class CalculatorService : ICalculator
{
    public double Add(double n1, double n2)
    {
        AccessControlHelper.DemandActionClaim("Calculator.Add");
        return n1 + n2;
    }
    public double Subtract(double n1, double n2)
    {
        AccessControlHelper.DemandActionClaim("Calculator.Subtract");
        return n1 - n2;
    }
    public double Multiply(double n1, double n2)
    {
        AccessControlHelper.DemandActionClaim("Calculator.Multiply");
        return n1 * n2;
    }
    public double Divide(double n1, double n2)
    {
        AccessControlHelper.DemandActionClaim("Calculator.Divide");
        return n1 / n2;
    }
}

                                 Рис. 9: Код сервиса Calculator

Чуть ниже будет рассмотрен код вспомогательного метода DemandActionClaim (Утверждение требуемого действия), но, надеюсь, из рис. 9 понятно, что перед выполнением операции выполняется лишь поиск утверждения действия с определенным строковым значением. Если заданное утверждение не найдено, вспомогательный метод формирует исключение «access denied» (в доступе отказано). В конечном счете, если пользователь может подтвердить, что он знает пароль решения, ему будет разрешено выполнять сложение, вычитание, умножение или деление. Если нет, ему будет отказано в доступе ко всем этим операциям.

public static void DemandActionClaim(string claimValue)
{
    foreach (ClaimSet claimSet in OperationContext.Current
                                                   .ServiceSecurityContext
                                                   .AuthorizationContext
                                                   .ClaimSets)
    {
        foreach (Claim claim in claimSet)
        {
            if (AccessControlHelper.CheckClaim(claim.ClaimType,
            claim.Resource.ToString(),
            "http://docs.oasis-open.org/wsfed/authorization/200706/claims/action",
            claimValue))
            {
                if (AccessControlHelper.IsIssuedByIbn(claimSet))
                {
                    return;
                }
            }
        }
    }
    throw new FaultException("Access denied.");
}

                          Рис. 10: Код вспомогательного метода DemandActionClaim

На рис. 10 представлен вспомогательный метод DemandActionClaim. Возможно, вы не знаете этого, но WCF создавался с учетом утверждений. Видите, как OperationContext (Контекст операции) предоставляет доступ к ряду наборов утверждений? Каждый набор утверждений представляет маркер доступа. Данный цикл перебирает этот набор и находит маркер (в данном случае, он единственный, выпущенный ACS). Затем выполняется поиск конкретного типа (прописанный в коде URI, оканчивающийся на /action, идентифицирует утверждение Action) и проверяется наличие значения, указанного вызывающей стороной («Calculator.Add», например), и то, что утверждение выпущено ACS12. Если эти требования не выполняются, вспомогательный метод завершается формированием исключения «Access denied».

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

12 «Ibn» очевидно, старое внутреннее кодовое имя ACS, поэтому не дайте вспомогательному методу IsIssuedByIbn сбить вас с толку.

                                     

              Рис. 11: Выполнение клиента со всеми четырьмя утверждениями Action

Получив рабочее решение, возвращаемся к правилам и деактивируем Calculator.Divide, просто убирая соответствующий ему флажок (рис. 8). И опять выполняем клиент. На этот раз, он получил только три из четырех утверждений Action, и ему было отказано в доступе к операции Divide (рис. 12).

                                   

              Рис. 12: Выполнение клиента после деактивации одного из утверждений Action

Далее, попробуем ввести другое имя решения и пароль для ACS. На рис. 13 представлен результат.

                                   

              Рис. 13: Выполнение клиента с использованием другого имени пользователя

Как видите, я смог указать имя пользователя и пароль другого решения (xyzzy), но вернемся к рис. 8 и вспомним, что заданные правила ожидают именно утверждения UserName со значением «asolution», а не «xyzzy». Поэтому в результате я получил маркер без утверждений Action и не мог выполнять ни одну из операций сервиса Calculator (например, логика авторизации DemandActionClaim дала сбой, в данном случае).

Наконец, я задал «asolution» с неверным паролем, чтобы имитировать злоумышленника, который захочет использовать приложение, не зная пароля. Что в результате? WCF сформировала исключение, указывающее на то, что вызывающая сторона не может быть аутентифицирована. Итак, ACS даже не делал попытки выпустить маркер в данном случае, потому что он не смог установить достоверность предоставленных мною имени пользователя и пароля.

Если поэкспериментировать с этим примером SDK, можно заметить, что в нем используется модель программирования утверждений, встроенная в WCF в настоящий момент (System.IdentityModel). Вместо этого можно установить Geneva Framework и использовать ее модель программирования. Geneva Framework – это более современный подход к программированию работающих с утверждениями приложений. Он характеризуются большей гибкостью и более богатым набором возможностей, также он точнее представляет будущее программирования продуктов для работы с утверждениями, исходя из тенденций развития Microsoft .NET13. Поскольку ASP.NET 2.0 не поддерживает утверждения, Geneva Framework является наилучшим вариантом для организации работы с утверждениями в этом сценарии, как будет показано в примере в конце данного документа.

Настройка .NET Access Control Service

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

Учетные записи и решения

Каждая учетная запись в ACS ассоциирована с единственным Windows Live ID (WLID). Каждая учетная запись ACS имеет набор решений. В ACS решение может рассматриваться как виртуальная служба сертификации с собственным STS и набором веб-страниц, на которые перенаправляются браузеры для получения маркеров SAML (рис. 14).

                                                    

                                   Account

                            Учетная запись

                                   Solution

                                 Решение

                                     Scopes

                          Области действия

                                 Credentials

                           Учетные данные

            STS and web pages for passive clients

   STS и веб-страницы для пассивных клиентов

                                                Рис. 14: Учетные записи и решения

13 Команда ACS использовала модель программирования WCF в примере калькулятора лишь из соображений поставки (на момент поставки SDK они не могли распространять Geneva Framework).

Решение – это также то место, где создаются правила и определяется, какие утверждения будут включать SAML-маркеры, выпускаемые ACS. У каждого решения могут быть абсолютно разные правила.

В CTP-версии каждое решение включает набор учетных данных, в том числе пароль. Имя решения и пароль могут использоваться для аутентификации и запроса маркера SAML у встроенного издателя, но поскольку пара имя пользователя/пароль всего одна, поддержка множества пользователей невозможна. Не забывайте, что учетные данные решения, на самом деле, предназначены лишь для разработки и тестирования. Можно также провести тестирование с использованием сертификатов или информационных карточек, т.к. каждое решение в настоящее время позволяет ассоциировать личные (самостоятельно выдаваемые) информационные карточки, а также X.509-сертификаты клиентов. Несколько позже в данном документе мы поговорим об аутентификации пользователей с помощью таких провайдеров удостоверений, как Windows Live ID и Geneva Server.

Решение ACS содержит правила, которые могут управлять выпуском маркеров для множества разных приложений, но, как правило, приложения используют разные типы утверждений. Одному приложению необходимо отправлять пользователям сообщения по электронной почте, поэтому в выпущенный для него ACS маркер должен быть включен адрес электронной почты, тогда как другому не нужен адрес электронной почты пользователя, поэтому из соображений безопасности оно не должно иметь доступ к этой информации. Например, приложению для составления отчетов о расходах может понадобиться знать, является пользователь руководителем проекта (ProjectManager) или участником проекта (ProjectMember), поэтому ему должны быть предоставлены утверждения, представляющие эти роли. Но приложению для составления сводки погоды не важна роль пользователя, больший интерес для него представляет его текущее географическое местоположение.

Очевидно, что каждому приложению нужны вполне определенные утверждения и, следовательно, собственный набор правил, чтобы ACS мог формировать эти утверждения. Это настолько важная идея, что она отражена в спецификации WS-Trust. Согласно WS-Trust запрос на получение маркера доступа (RST) должен включать поле AppliesTo (Применяется к), значением которого является URI, определяющий логический адрес точки назначения маркера. ACS использует это, предоставляя возможность разработчику назначать URI для каждого создаваемого приложения.

Области действия решения

В ACS каждому приложению в рамках решения должен быть присвоен уникальный URI. Это URI, являющийся значением поля AppliesTo, о котором мы говорили в предыдущем разделе. Тогда как технически это может быть любая строка, скомпонованная по правилам построения URI14, обычно, для веб-приложений и сервисов используют URL, ассоциированный с приложением, например, http://www.fabrikam.com/expenseReportingService. Очевидное преимущество в том, что сразу видно, на какое приложение указывает имя, а также в этом случае практически невозможно по ошибке присвоить один и тот же URI двум разным приложениям.

14 Например, urn:foo – действительный URI, хотя и не уникальный.

Каждое ACS-решение может курировать несколько приложений. Отсюда следует, что у каждого приложения в решении должна быть собственная область действия с настройками, соответствующими данному приложению. Вот почему на рис. 14 у каждого решения можно видеть набор областей действия. Область действия это не что иное, как настройки для конкретного приложения.

Параметры области действия

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

                                                    

                                 Scope Settings

                 Параметры области действия

                                     Rules

                                 Правила

                              Identity Issuers

                     Издатели удостоверений

                                Claim Types

                          Типы утверждений

                       Encryption Preferences

                  Предпочтения шифрования

                       Expiration Preferences

                Предпочтения срока действия

                                Permissions

                              Разрешения

                                            Рис. 15: Параметры в области действия

Здесь будут рассмотрены самые простые настройки, и наиболее интересным из них посвящены отдельные разделы. Один из самых простых параметров – срок действия (expiration). Для улучшения производительности и повышения масштабируемости маркеры доступа обладают сроком действия. Клиент может многократно использовать маркер доступа, но лишь до истечения его срока действия. Таким образом, клиенту не приходится так часто обращаться к издателю за новым маркером, что снижает задержку для клиента и нагрузку на издателя. По умолчанию выпускаемые ACS SAML-маркеры действительны в течение 8 часов с моменты выпуска (или менее, если клиент запрашивает маркер на более короткий срок). Каждая область действия имеет настраиваемые параметры для задания максимально допустимого срока действия.

Другой важный параметр касается шифрования (encryption). ACS шифрует все выпускаемые маркеры доступа, но, конечно же, приложение, для которого выпускается маркер, должно суметь прочитать его. Параметры шифрования области действия позволяют загружать открытый ключ (формально, это сертификат X.509, содержащий открытый ключ) в ACS. Этот открытый ключ будет использоваться для шифрования всех маркеров, выпускаемых для приложения, представляемого данной областью действия. Для дешифровки маркеров приложению понадобится доступ к его закрытому ключу, и выбранная инфраструктура (WCF, Geneva Framework и т.д.) позволит пользователю выбирать закрытый ключ. Обычно это делается путем выбора сертификата из хранилища, включающего закрытый ключ15.

По определению, при создании области действия в рамках решения эта область действия принадлежит этому решению, и владелец решения всегда может редактировать данную область действия. Но если требуется предоставить разрешения на редактирование области действия кому-то еще, сделать это можно с помощью настройки разрешений области действия. Для этого в ACS определяется другое решение, которому предоставляются права на редактирование данной области действия. Это может показаться странным на первый взгляд, но не забывайте, что у каждого решения всего один Windows Live ID (WLID), таким образом, в итоге разрешение на редактирование получает WLID решения. После этого владелец данного решения может редактировать рассматриваемую область действия. С этой настройкой необходимо быть очень осторожным, потому что тот, кто получает права на редактирование, может как угодно изменять область действия, в том числе и правила.16

Издатели удостоверений

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

Как видно на рис. 16, ACS принимает WLID в качестве провайдера удостоверений по молчанию. Также не забываем, что в CTP-версии ACS есть собственный основанный на учетных данных решения провайдер удостоверений, который может использоваться для тестирования и обусловливает существование двух издателей, начинающихся с accesscontrol.windows.net. В окончательной версии их не будет, поэтому здесь мы не будем на них останавливаться.

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

16 Обратите внимание, что эта методика, позволяющая настраивать параметры создаваемых областей действия, используется и в .NET Service Bus, и в .NET Workflow Service.

Остановимся на Fabrikam – издателе, который я добавил самостоятельно, нажав кнопку «Add Issuers» (Добавить издателей). Для него можно было задать три вещи: отображаемое имя, URI и сертификат. URI определяет службу сертификации в Fabrikam Corporation, так же как URI каждой области действия идентифицирует приложение. Я получил сертификат от Fabrikam и предоставил его ACS на этой странице. Таким образом, когда пользователь из Fabrikam обращается за маркером для моего приложения, ACS будет знать, как проверить достоверность подписи SAML-маркера, присланного провайдером удостоверений Fabrikam.

                                              Рис. 16: Издатели удостоверений

Fabrikam и live.com являются доверенными издателями в этой области действия. Я хочу принимать SAML-маркеры от любого из них. Совершенно не важно, на какой платформе они выполняются, или какую технологию используют для формирования маркеров (хотя, вероятно, можно догадаться, что live.com использует одну из технологий Microsoft .NET, например, Geneva Framework). Поскольку провайдер удостоверений Fabrikam поддерживает WS-Trust 1.3 и формирует SAML-маркеры, которые может использовать ACS, он является прекрасным кандидатом на роль доверенного издателя. Если Fabrikam управляет учетными записями пользователей с помощью Windows и Active Directory, очевидным выбором в качестве провайдера удостоверений для них был бы Geneva Server, например.

Команда ACS четко обозначила возможность взаимодействия как одну из приоритетных целей своей работы. CTP-версия ACS в настоящее время поддерживает в качестве провайдеров удостоверений Windows Live ID и Geneva Server, но также ACS проходит тестирование с использованием продуктов для интегрированной идентификации, выпущенных другими ведущими производителями, включая Tivoli, Ping Identity, IBM и др.

Типы утверждений

Каждое утверждение имеет тип и значение. Тип утверждения определяется уникальным URI, и разработчик должен понимать, что обозначает конкретный тип утверждения, выпущенный издателем.

Обычно все довольно просто. Например, URI утверждения, содержащего адрес электронной почты, – «http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress». Значением этого утверждения является просто строка с адресом электронной почты. Утверждения могут быть абсолютно любой сложности, главное, чтобы значения и структура значений утверждений были согласованы между приложением, для которого они предназначены, и их издателем. ACS по умолчанию поддерживает несколько типов утверждений, как показано на рис. 17.

                                                Рис. 17: Типы утверждений в ACS

В CTP-версии вызывающая сторона может получать утверждение UserName (Имя пользователя), выпущенное accesscontrol.windows.net . В этом случае, UserName будет именем решения. Но, как упоминалось ранее, эта возможность будет устранена в следующей версии. Скорее всего, в будущем будут использоваться UserName или UPN17, выпущенные Geneva Server или Windows Live ID.

17 UPN == User Principal Name (основное имя пользователя), термин, пришедший из Active Directory и используемый для идентификации пользователя в конкретной области безопасности. Формат UPN аналогичен формату адреса электронной почты (например, alice@fabrikam.com).

Для персонализации приложения часто используются Email и Name (Имя). Name - это как правило что-то, что можно отображать для обозначения удостоверения, используемого пользователем18 для регистрации в приложении. Email имеет очевидное назначение: связь с пользователем.

Мы уже обсуждали утверждение Action. Оно может использоваться для предоставления доступа к определенным операциям. Его значением является произвольная строка, которую ожидает приложение. Действительно мощным является утверждение Group (Группа): обычно оно используется в сочетании с утверждениями Action для построения логики Role Based Access Control (RBAC). Пример этого будет представлен ниже, в разделе «Реализация управления доступом на основании ролей (RBAC)». Утверждения Group легко получить от Geneva Server, на котором группу Windows можно спроецировать в утверждение Group.

Как показано на рис. 17, также можно добавлять собственные специальные типы утверждений. Для этого необходимы лишь отображаемое имя и URI, а также реализация соответствующей логики в приложении для интерпретации поступающих утверждений.

Преобразование утверждений

В представленном ранее примере Calculator мы лишь слегка коснулись возможностей, обеспечиваемых правилами ACS. Скажем, издатель удостоверений желает предоставлять вам адрес электронной почты пользователя. Как показано на рис. 18, это значение может передаваться в приложение: здесь в приложение в качестве входящего утверждения передается утверждение Email, выпущенное издателем, которому я доверяю (fabrikam.com). Приложение рассматривает его и использует. Обратите внимание на применение символа *, что обеспечивает прием любого адреса электронной почты, и флажок «Copy input value» (Копировать входящее значение), обусловливающий копирование утверждения в выходной набор утверждений.

18 Всегда следует быть осторожным при использовании значений утверждений в своих программах, особенно утверждений, которые могут создаваться самими пользователями, таких как утверждения Name. Такие утверждения являются просто еще одной формой пользовательского ввода, поэтому необходимо предпринимать все меры предосторожности во избежание таких атак, как Cross Site Scripting (межсайтовый скриптинг), путем соответствующего кодирования этих значений для вывода.

                                  Рис. 18: Передача утверждения Email

Это простое преобразование: утверждение Email изначально было выпущено Fabrikam.com, но приложение получает его, как будто от ACS. Возможны и более интересные преобразования. Например, скажем, приложению требуется знать, является ли пользователь участником логической роли Managers (Управляющие). И, допустим, имеется несколько разных организаций, каждая из которых использует Geneva Server для интеграции удостоверения с вашим приложением. В каждой организации логическая категория, которая в вашем приложении названа «Manager», может называться по-разному.

На рис. 19 показано, как спроецировать все эти данные с учетом собственной терминологии каждого провайдера удостоверений в единое утверждение Group под названием «Manager». Преобразования такого рода позволяют разработчикам приложений спать спокойно! Просто проверить HttpContext.User.IsInRole(“Manager”) намного проще, чем выяснять, из какой организации пользователь, и затем соответственно этому выполнять проверку роли «Executives» или «Managers».

                                

               Рис. 19: Преобразования утверждений в применении к именам ролей

Реализация управления доступом на основании ролей (RBAC)

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

В предыдущем примере (рис. 19) были смоделированы роль «Manager» и утверждение Group. На рис. 20 представлен расширенный вариант этого примера, где роль «Manager» проецируется в несколько логических операций. Эти операции моделируются утверждениями Action. Таким образом, наше гипотетическое приложение для составления отчета о расходах будет вести поиск следующих утверждений:

                                  

Рис. 20: Преобразование утверждений Group в роль и затем в утверждения Action обеспечивает RBAC

Результатом данного примера является то, что пользователи из компании Contoso могут просматривать и утверждать отчеты о расходах, только если их провайдер удостоверений обозначил, что они входят в группу «Managers». Аналогично, чтобы просматривать и утверждать отчеты о расходах, пользователи из Fabrikam должны иметь утверждение «Executives». И опять же, разработчику приложения не приходится беспокоиться обо всех этих деталях: для принятия решения о предоставлении доступа он просто реализует поиск утверждения Action, соответствующего каждой операции.

Теоретически, глубина иерархии роль/операция не ограничена. Можно было бы добавить еще одну роль Employee (Сотрудник) и предоставлять ей ограниченные права доступа к приложению для составления отчетов. Затем, если потребовалось бы предоставить всем участникам роли Manager права, доступные любому Employee, мы бы просто добавили еще одно правило, обеспечивающее преобразование утверждений Manager (выпущенного ACS) в утверждения Employee.

Примеры пассивных сценариев

В данном разделе документа рассматривается интеграция ACS в выполняющееся в браузере веб-приложение с использованием ASP.NET и Geneva Framework.

Интеграция ACS в веб-приложение ASP.NET

Рассмотрим пример выполняющегося в браузере веб-приложения, которое использует ACS для аутентификации и авторизации пользователей. Приложение предельно простое: это клиентская часть компании Contoso Woodworking, занимающейся арендой инструментов. Данная компания предоставляет прокат таких инструментов, как отвертки, уровни, механические пилы и т.д., и хочет, чтобы арендовать инструменты могли лишь авторизованные пользователи. Более того, они должны быть уверены, что механические инструменты будут выдаваться только пользователям, подписавшим специальный документ. Компания стремится охватить широкий диапазон клиентов, от любителей и до больших корпораций, поэтому они остановили свой выбор на ACS.

Начнем с демонстрации использования Windows Live ID для аутентификации отдельных пользователей, таких как любители или пользователи из корпораций, не имеющих решений интегрированной идентификации. Просматривать или арендовать инструменты Contoso Woodworking могут только аутентифицированные пользователи, зарегистрированные для использования сервиса. И из этих пользователей только те, кто подписал специальный документ, могут просматривать и арендовать механические инструменты. Но просматривать главную страницу приложения может любой анонимный пользователь (рис. 21).

                             

                     Рис. 21: Главная страница, какой ее видят анонимные пользователи

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

                        

                             Рис. 22: Регистрация с использованием Windows Live ID

После успешной регистрации пользователя (пусть это будет Алиса) WLID возвращает браузер к ACS, который обрабатывает утверждения, предоставленные WLID, применяет правила соответствующей области действия для формирования утверждений для Алисы, которые имеют смысл для Contoso Woodworking, и затем посредством запроса POST передает эти утверждения в форме шифрованного SAML-маркера назад на главную страницу Contoso Woodworking. Эффекты, представляемые пользователю, очень естественны: Алиса нажимает кнопку входа и видит страницу регистрации WLID. После регистрации она возвращается на сайт Contoso Woodworking, который отражает ее зарегистрированное состояние (вместо кнопки «Login» появилась кнопка «Logout» (Выход)) (рис. 23).

                                      

                                     Рис. 23: Главная страница после регистрации

Поскольку Алиса ранее зарегистрировалась в Contoso для использования их сервиса, она может просматривать предлагаемые компанией инструменты, переходя по ссылке View Tools (Инструменты) (рис. 24). Но поскольку она еще не подписала документ на использование механических инструментов, их она видеть не может.

                                   

Рис. 24: Обычный пользователь может просматривать лишь «безопасные» инструменты

На рис. 25 представлено правило, применяемое Contoso после регистрации пользователя (Алисы, в данном случае) для работы с их сервисом. Оно обеспечивает поиск WLID Алисы и его проецирование в утверждение типа Action «ContosoWeb.ViewTools», которое Contoso Woodworking использует при принятии решения об отображении инструментов.

                                      

Рис. 25: Настройка ACS для предоставления Алисе разрешения на просмотр обычных инструментов

Как только Алиса подпишет документ об использовании механических инструментов, Contoso предоставит ей доступ к ним на Contoso Woodworking. Для этого требуется лишь обновить правила и предоставить Алисе утверждение типа Action «ContosoWeb.PowerTools», как показано на рис. 26.

                                 

Рис. 26: Добавление утверждения Action, которое обеспечивает Алисе возможность доступа к механическим инструментам

Когда Алиса зарегистрируется в следующий раз, она уже будет видеть и механические инструменты (рис. 27).

                                  

Рис. 27: После подписания соответствующего документа пользователь может видеть и механические инструменты

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

Хорошим решением является использование иерархического подхода, описанного в разделе, посвященном управлению доступом на основании ролей. Когда пользователи объединены в группы посредством ACS-утверждений типа Group, не составляет никакого труда добавить соответствующие утверждения Action в каждую из групп. Если правил довольно много, что делает портал ACS неудобным в использовании, можно обратиться к API администрирования и управлять правилами программно.19

До сих пор мы рассматривали, как аутентифицировать пользователей с помощью Windows Live ID. Такой подход хорош для отдельных любителей или корпораций, не имеющих инфраструктуры интегрированной идентификации. Но представим, что компания Fabrikam развернула Geneva Server (или любой другой продукт интеграции удостоверений) и подписала соглашение, соответственно которому определенные сотрудники Fabrikam могут арендовать инструменты Contoso Woodworking.

19 Я говорил ранее, что этот API претерпевает существенные изменения в данный момент, но если вы желаете увидеть некоторый код текущей версии, в подпапке Samples\AccessControl\ExploringFeatures\AccessControlManagement каталога .NET Services SDK можно найти два примера.

Чтобы реализовать это, Fabrikam настраивает свой сервер на выпуск утверждения Group для пользователей из Fabrikam, которым должно быть предоставлено право аренды инструментов. В данном примере назовем это утверждение «ToolUsers». Contoso необходимо конфигурировать ACS на прием SAML-маркеров, выпущенных издателем удостоверений Fabrikam (вернитесь к рис. 16, на котором показано, как установить это отношение доверия путем загрузки сертификата Fabrikam на ACS). Предположим, в Contoso приняли решение, что Fabrikam целесообразно самостоятельно управлять процессом подписи документа на использование механических инструментов. Таким образом, Fabrikam настраивает свой сервер на выпуск второго утверждения Group для пользователей, подписавших документ. На рис. 28 представлено, как должен быть конфигурирован ACS Contoso для проецирования этих утверждений Group, получаемых от Fabrikam, в соответствующие утверждения Action, понятные приложению.

                                      

Рис. 28: Проецирование утверждений Group от Fabrikam в утверждения Action Contoso Woodworking

Если Contoso решает реализовывать иерархическую схему RBAC, они могут просто проецировать утверждения Group Fabrikam в собственные утверждения Group, которые потом отображались бы в утверждения Action.

При такой настройке пользователи из Fabrikam получили бы доступ к веб-сайту Contoso Woodworking через единую регистрацию. Для аренды инструментов пользователям из Fabrikam не нужен Windows Live ID. Также Contoso Woodworking нет необходимости создавать имя пользователя или пароль ни для одного из его пользователей. А это огромная экономия, поскольку управлять удостоверениями пользователей может быть тяжело и дорого, и ACS помогает вывести разработчиков из этого процесса.

Код Contoso Woodworking

Код Contoso Woodworking не включен в пакет примеров .NET Services SDK, но его можно найти на блоге Джастина Смита (Justin Smith) (http://blogs.msdn.com/justinjsmith/).

ASP.NET 2.0 поставляется без поддержки интегрированной регистрации, поэтому логичным выбором для обеспечения этой поддержки является Geneva Framework. Если взглянуть на файл web.config веб-сайта Contoso Woodworking (рис. 29), можно увидеть, как включена Geneva Framework.

<configuration>

  <configSections>

    <sectionname="microsoft.identityModel"

             type="...MicrosoftIdentityModelSection..."/>

  </configSections>

  <system.web>

    <compilation>

      <assemblies>

        <!-- стандыртные сборки ASP.NET опущены для краткости -->

        <addassembly="Microsoft.IdentityModel, ..."/>

      </assemblies>

    </ compilation >

    <!-- аутентификацию будет выполнять ACS , не ASP . NET -->

    <authenticationmode="None"/>

  </system.web>

  <system.webServer>

    <modules>

      <addname="WSFederationAuthenticationModule"

           type="Microsoft.IdentityModel..."

           preCondition="managedHandler"/>

      <addname="SessionAuthenticationModule"

           type="Microsoft.IdentityModel..."

           preCondition="managedHandler"/>

    </modules>

  </system.webServer>

  <microsoft.identityModel>

    <serviceCertificate>

      <certificateReference

          findValue="CN=ContosoWoodworking"

          x509FindType="FindBySubjectDistinguishedName"

          storeLocation="LocalMachine"

          storeName="My"/>

    </serviceCertificate>

    <audienceUris>

      <addvalue="http://localhost/ContosoWoodworking/Default.aspx"/>

    </audienceUris>

    <federatedAuthenticationenabled="true"/>

    <issuerNameRegistrytype="...">

      <trustedIssuers>

        <addthumbprint="416e6fa5d982b096931fbf42c4a3dcd608856c95"

             name="http://accesscontrol.windows.net/asolution/"/>

      </trustedIssuers>

    </issuerNameRegistry>

  </microsoft.identityModel>

</configuration>

                 Рис. 29: Файл web.config сервиса Contoso Woodworking

Несколько интересных замечаний о конфигурационном файле:

  • <configSections> объявляет раздел для microsoft.IdentityModel (Geneva Framework)

       •  <assemblies> извлекает ссылку на сборку Geneva Framework из GAC20

  • <modules> подключает модуль WSFederationAuthenticationModule, который обеспечивает интегрированную аутентификацию, а также модуль SessionAuthenticationModule, который реализует основанный на cookie сеанс регистрации, что избавляет пользователя от необходимости постоянно обращаться за аутентификацией (оба этих модуля входят в состав Geneva Framework)
  • <serviceCertificate> указывает Geneva Framework, какой сертификат должен использоваться для дешифровки SAML-маркеров, полученных от ACS
  • <audienceUris> указывает Geneva Framework, куда отправлять (посредством запроса POST) SAML-маркеры
  • <issuerNameRegistry> указывает Geneva Framework на то, что можно доверять только SAML-маркерам, подписанным ACS и выпущенным специально для соответствующего решения (мое решение называется «asolution»; при воспроизведении этого примера используйте имя своего решения)

20 GAC == Global Assembly Cache (Глобальный кэш сборок)

Когда анонимный пользователь направляет свой браузер на Contoso Woodworking (или любой другой веб-сайт, использующий ACS в этих целях), браузер перенаправляется на ACS, который пересылает его еще раз к провайдеру удостоверений пользователя. Поскольку провайдеров удостоверений может быть множество (WLID – лишь один из возможных вариантов, в данном документе также упоминался издатель Fabrikam), выбор наиболее подходящего для конкретного пользователя провайдера удостоверений может представлять определенные сложности. Этот процесс называют исследованием «домашней» области, и в текущей версии ACS требуется предоставить подсказку посредством стандартного параметра whr строки запроса WS-Federation. Этот параметр указывает ACS, к какой «домашней» области относится пользователь.

Geneva Framework поддерживает параметр whr, но в настоящий момент использует для работы с ним несколько шаблонный код. Это означает невозможность применения встроенного в Geneva Framework элемента управления FederatedPassiveSignIn для перенаправления на ACS. Это должно быть исправлено в окончательной версии Geneva Framework (вероятно, через добавление в элемент управления параметра, позволяющего определять «домашнюю» область, но посмотрим, как это будет реализовано). На рис. 30 показан код в global.asax, используемый для обработки перенаправления на ACS для регистрации. Обратите внимание, что главная страница (Default.aspx) не входит в список перенаправления, что позволяет просматривать ее анонимным пользователям.

Возможно, вы заметили, что в данном примере параметру whr задано конкретное значение, «http://login.live.com». Сделано это потому, что аутентификация всех пользователей в этом примере выполняется с помощью WLID. Если бы потребовалось реализовать интеграцию удостоверений (скажем, для Fabrikam Corporation), понадобился бы некоторый способ, позволяющий пользователю указывать, имеет ли он учетные данные Fabrikam или использует Windows Live ID для доступа к сервису аренды инструментов.

Один из вариантов сделать это – обеспечить несколько кнопок для регистрации («Login using my Windows Live ID» (Зарегистрироваться с помощью Windows Live ID) и «Login using my Fabrikam ID» (Зарегистрироваться с помощью Fabrikam ID)). Однако более прозрачный подход – предоставить всем пользователям из Fabrikam отдельную ссылку на веб-сайт Contoso Woodworking, например, включая в нее с помощью аргумента строки запроса «домашнюю» область пользователя (realm=Fabrikam, например). Каждая компания, с которой выполняется интеграция, получала бы ссылку, включающую имя ее «домашней» области. Таким образом, теперь у нас есть все необходимое для правильного перенаправления пользователя на ACS и поддержки множества провайдеров удостоверений.

<%@ApplicationLanguage="C#"%>

<%@ImportNamespace="Microsoft.IdentityModel.Web"%>

<%@ImportNamespace="Microsoft.IdentityModel.Claims"%>

<%@ImportNamespace="Microsoft.IdentityModel.Protocols.WSFederation"%>

<scriptrunat="server">

void Application_AuthenticateRequest(Object sender, EventArgs e)

{

    IClaimsIdentity identity =

        HttpContext.Current.User.Identity asIClaimsIdentity;

    if (identity != null) return;

    WSFederationAuthenticationModule authModule =

        newWSFederationAuthenticationModule();

    // имя области действия

    authModule.Realm = "http://localhost/contosowoodworking/Default.aspx";

    // это URL моего собственного издателя для asoltuion

    authModule.Issuer = "https://accesscontrol.windows.net/" +

        "passivests/asolution/livefederation.aspx";

    String uniqueId = Guid.NewGuid().ToString();

    SignInRequestMessage signInMsg = authModule.CreateSignInRequest(

            uniqueId, authModule.Realm, false);

    // Причина, по которой пришлось делать все это вручную

    signInMsg.Parameters.Add("whr", "http://login.live.com");

    // Перенаправление на ACS , что, в свою очередь, приведет к перенаправлению на WLID

    Response.Redirect(signInMsg.RequestUrl);

}

          

</script>

Рис. 30: Global.asax для веб-сайта Contoso Woodworking

Рассмотрев процесс регистрации, перейдем к тому, где в данном примере используются учетные данные пользователя и утверждения для настройки внешнего вида и функциональности веб-сайта. Одно из таких мест – кнопка Login, которая после регистрации пользователя заменяется кнопкой Logout. Эта операция не зависит от предоставляемых утверждений. Фрагмент кода на рис. 31 демонстрирует, как Geneva Framework упрощает применение утверждений с ASP.NET-приложением за счет использования таких хорошо знакомых техник, как HttpContext.User.

protected void Page_Load(object sender, EventArgs e)
{
    loginButton.Text = Page.User.Identity.IsAuthenticated ?
        "Logout" : "Login";
}

             Рис. 31: Задание текста кнопки Login в пользовательском элементе управления

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

protected void Page_Load(object sender, EventArgs e)
{
    if (ClaimsVerification.ViewToolsPermission)
    {
        if (ClaimsVerification.PowerToolsPermission)
             toolList.DataSource = ToolUtility.AllTools();
        else toolList.DataSource = ToolUtility.HandTools();
        toolList.DataBind();
    }
}

                Рис. 32: Выборочное связывание с данными в зависимости от утверждений

В представленном выше фрагменте кода применяется вспомогательный класс ClaimsVerification, который использует Geneva Framework для поиска утверждений Action в маркере пользователя. Один из простых способов сделать это – использовать LINQ (рис. 33).

public static Boolean PowerToolsPermission
{
    get
    {
        IClaimsIdentity identity =
            Thread.CurrentPrincipal.Identity as IClaimsIdentity;
        if (identity == null) return false;
        return identity.Claims
            .Where(claim => claim.ClaimType.Equals(ActionClaim) &&
                   claim.Value.Equals("ContosoWeb.PowerTools"))
            .Count() > 0;
    }
}

    Рис. 33: Использование LINQ для поиска утверждения типа Action ContosoWeb.PowerTool

Как видите, на самом деле, совсем не так сложно начать использовать ACS в приложении ASP.NET уже сегодня. И будьте уверены, в будущем это будет еще проще, поскольку в Visual Studio появится больше инструментов для поддержки Geneva Framework и ACS.

Управление через AtomPub

 Портал ACS – замечательное средство для рассмотрения, изучения и начала работы с ACS. Для относительно простых приложений он может быть единственным необходимым инструментом. Но для нетривиальных систем с сотнями или тысячами пользователей и, возможно, аналогичным количеством правил использование портала становится громоздким. В таких случаях программный интерфейс – более предпочтительный вариант, поэтому ACS также предоставляет интерфейс AtomPub для программного администрирования.

AtomPub – это протокол RESTful, который стандартизует базовые операции CRUD (Create, Retrieve, Update и Delete) для управления удаленными ресурсами. В конечном счете, область действия в ACS состоит из целого ряда различных типов ресурсов. Правило – один пример; доверенные издатели – другой. Поскольку для извлечения данных REST использует HTTP-команду GET, познакомиться с интерфейсом управления и научиться работать с ним можно прямо в браузере.

Корневая конечная точка сервиса управления ACS для моего решения формируется следующим образом:

https://asolution.accesscontrol.windows.net/mgmt/v0.1/scopes

Заметьте, имя решения является первой частью имени хоста. Замените «asolution» именем своего решения, для организации доступа к его конечной точке управления. Также обратите внимание на использование HTTPS вместо HTTP. Для защиты передаваемых учетных данных интерфейс управления ACS требует безопасного соединения. При переходе в браузере по этому URL на экран выводится диалоговое окно, предлагающее ввести учетные данные. Я ввожу имя моего решения и пароль:

                        

Рис. 34: Для доступа к интерфейсу управления используйте имя и пароль своего решения

После введения пароля браузер представляет список областей действия в виде канала Atom. При выполнении этого пример в моем решении было определено три области действия. Все три можно увидеть на рис. 35.

                         Рис. 35: Просмотр областей действия в Internet Explorer

К сожалению это максимум, что я мог получить, используя браузер, потому что содержимое этих ресурсов форматировано не как HTML, а как XML. На момент написания данного документа браузеры не умеют правильно отображать документы atom, включающие XML-содержимое. Но формат atom спроектирован с обеспечением возможности просмотра, поэтому я добавил небольшое WPF-приложение, которое позволит просматривать ресурсы. Это приложение называется Feed Browser, его можно скачать здесь.

Проникнув в одну из этих областей с помощью Feed Browser (рис. 36), я немедленно обнаружил несколько настроек, которые можно просматривать или изменять через интерфейс управления.

 

               Рис. 36: Просмотр области действия с помощью приложения Feed Browser

Feed Browser имеет две панели для представления информационного ресурса. Справа представлен необработанный XML-ответ. Этот ответ очень просто получить программно, в .NET Framework для этого потребуется лишь несколько строк кода, они будут показаны ниже. Обратите внимание, что в каждом ответе имеются метаданные, включающие id, заголовок, дату последнего обновления, некоторые ссылки и само содержимое узла. Feed Browser просматривает эти данные и выводит ссылки в панели слева, чтобы обеспечить пользователю возможность без труда переходить по иерархии ресурсов. Я не занимался декорированием вывода содержимого, но и в этом случае для области действия можно увидеть ее имя, Uri (который мы видим на портале ACS) и решение, которому она принадлежит.

Щелкнув ссылку Rules (Правила), вы попадаете в канал, содержащий записи для всех правил области действия (рис. 37). Отсюда можно переходить в каждое правило в отдельности, но сам канал уже представляет все данные правил. Каждое правило содержит входное и выходное утверждения. Их можно также увидеть и на портале, но использование интерфейса AtomPub позволяет писать собственный код для просмотра и изменения правил. Feed Browser – инструмент исключительно для чтения, поэтому не может использоваться для обновления правила, но позднее я приведу пример того, как это делается.

                               Рис. 37: Список правил для области действия

Для доступа к интерфейсу управления не обязательно использовать такой инструмент, как Feed Browser. Любая библиотека, умеющая посылать HTTP-запрос GET, может извлекать эти данные. На рис. 38 представлен код небольшого консольного приложения, извлекающего atom-данные, показанные в Feed Browser на панели справа. Использование клиентской библиотеки HTTP упрощает эту задачу, и этот подход применяет Feed Browser.

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(
    "https://asolution.accesscontrol.windows.net/mgmt/" +
    "v0.1/scopes/sa275fb535eaa4493a36994377634fb6f/rules");
// SolutionName и Password – переменные, предоставляемые пользователем
request.Credentials = new NetworkCredential(SolutionName, Password);
request.Method = "GET";
request.KeepAlive = false;
using (Stream stream = request.GetResponse().GetResponseStream())
    PrettyPrintResponse(stream);

Рис. 38: Извлечение списка правил программно, с помощью .NET Framework

Возможно, не вполне очевидно, как я выявил URL для получения правил определенной области действия. Я начал с HTTP-запроса GET по корневому URL своего решения, https://asolution.accesscontrol.windows.net/mgmt/v0.1/scopes, в результате которого был возвращен список областей действия решения. В этот список вошли Uri и ID каждой области, а также ряд элементов link (ссылка), указывающие, как найти ресурсы, связанные с каждой областью действия. Под интересующей меня областью я нашел ссылку Rules (Правила). Ее атрибут href и являлся тем URL, который требовался для запроса на рис. 38.

<link rel="rules" title="Rules" href="https://asolution.accesscontrol.windows.net/mgmt/v0.1/scopes/sa275fb535eaa4493a36994377634fb6f/rules" />

Рис. 39: Использование элементов <link> для выяснения URL ресурсов

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

https://[solution].accesscontrol.windows.net/mgmt/v0.1/scopes/[scopeId]/rules

На данный момент мы рассмотрели, как читать настройки из сервиса управления доступом, и я посоветовал скачать приложение Feed Browser, которое позволит вам просматривать собственные решения с целью выяснения структуры URL, используемой в интерфейсе управления. Далее я покажу, как создавать, обновлять и удалять ресурсы ACS программно.

Удалить что-то из ACS очень просто. Выяснив URL ресурса, который требуется удалить, просто отправляем HTTP-запрос DELETE на этот URL и ожидаем возвращения кода состояния200, свидетельствующего об успешности операции. Например, на рис. 37 представлен список правил, каждое правило имеет ID. Чтобы удалить первое правило из этого списка, отправляем HTTP-запрос DELETE по следующему URL:

https://asolution.accesscontrol.windows.net/mgmt/v0.1/scopes/sa275fb535eaa4493a36994377634fb6f/rules/r59a7b1033b30443e879921a2fedf4363

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

Не намного сложнее обновить ресурс в ACS. Если известен URL ресурса, просто посылаем HTTP-запрос UPDATE на этот URL. Тело этого запроса должно включать atom-элемент с содержимым, которое является обновленной версией элемента. Избежать конфликтов помогут HTTP ETag и HTTP-заголовок If-Modified-Since, которые обеспечат обновление элемента только в том случае, если он не был изменен с момента последнего просмотра. Детальное описание этого процесса выходит за рамки рассмотрения данного документа, но я рекомендую ознакомиться с примерами, приведенными в спецификации AtomPub specification.

Если требуется создать новый ресурс в ACS, прежде всего, необходимо выяснить URL родительского узла, в котором предполагается разместить этот ресурс. Это просто, если вы разобрались со структурой URL. Например, чтобы добавить новое правило, я должен был бы скомпоновать URL /rules, как описывалось ранее. Затем я бы послал HTTP-запрос POST на этот URL, и тело этого запроса выглядело бы аналогично телу запроса на обновление: atom-элемент с содержимым, представляющим то, что требуется создать. В AtomPub за присвоение ID создаваемым ресурсам отвечает не клиент, а сервис. ID возвращается в ответе в HTTP-заголовке Location. Кодом ответа, свидетельствующим об успешном выполнении операции, является код 201 Created.

.NET Services SDK включает пример AtomClient, демонстрирующий извлечение, создание и удаление ресурсов в ACS. Я смог выполнить сборку и запустить пример AtomClient прямо в том виде, в каком он поставляется. Программа сначала предложила мне ввести имя моего решения и пароль и использовала эти учетные данные для установления безопасного соединения с сервисом ACS AtomPub. Затем был выведен список обнаруженных в решении областей действия (на момент выполнения этого примера в моем решении была одна область, так что результаты, представленные ниже, правильные). Затем AtomClient добавил собственную область действия, чтобы иметь возможность вносить изменения, не оказывая влияния на существующие в решении области.

В этой новой области с помощью AtomPub была добавлена новая роль, составлен список правил, добавлен новый издатель, задан сертификат шифрования для области действия, а также политика прекращения действия. После этого данная область была удалена. Вывод представлен на рис. 40 (AtomClient – консольное приложение):

                           

                                       Рис. 40: Выполнение примера AtomClient

Вы можете использовать этот пример как основу для построения собственного клиента управления в .NET Framework.

Заключение

Создание программных продуктов для работы с утверждениями – будущее идентификации на платформе Microsoft Windows, и ACS – замечательное средство для начала. Принимая подход идентификации на основании утверждений, ваши приложения смогут использовать преимущества единой регистрации, а разработчикам больше не придется беспокоиться об аутентификации пользователей, что является сложной и дорогой задачей. ACS может в дальнейшем упростить приложения, взяв на себя обработку большей части (если не всей) логики авторизации. Но начинать использовать эту технологию можно уже сегодня, разрабатывая приложения, которые проводят аутентификацию не самостоятельно, а применяют для этого утверждения!

Дополнительные ресурсы

Ниже представлены ссылки на некоторые ресурсы, которые помогут продолжить изучение в области Microsoft® .NET Services в целом и .NET Access Control Service в частности.

Пакеты документов по Microsoft® .NET Services

     •     Введение в Microsoft .NET Services для разработчиков

          o     http://go.microsoft.com/?linkid=9638347

     •     Руководство по Microsoft® .NET Service Bus для разработчиков

          o     http://go.microsoft.com/?linkid=9638348

     •     Руководство по Microsoft® .NET Access Control Service для разработчиков (данный документ)

          o     http://go.microsoft.com/?linkid=9638349

     •     Руководство по Microsoft .NET Workflow Service для разработчиков

          o     http://go.microsoft.com/?linkid=9638350

Ресурсы .NET Access Control Service

     •     Microsoft Code Name «Geneva» Framework Whitepaper for Developers21

          o     http://download.microsoft.com/download/7/d/0/7d0b5166-6a8a-418a-addd-95ee9b046994/GenevaFrameworkWhitepaperForDevelopers.pdf

     •     Блог Джастина Смита (Justin Smith)

          o     http://blogs.msdn.com/justinjsmith/

Об авторе

Кейт Браун является соучредителем Pluralsight и ведущим разработчиком учебных курсов Microsoft .NET, как обычных, так и онлайн. Кейт является автором многочисленных книг по безопасности Windows и 8 лет вел колонку, посвященную безопасности, в журналах MSJ и MSDN. Уже более десяти лет Кейт занимается разработкой курсов, выступает на конференциях и обучает разработчиков в области безопасности. Его можно найти по адресу http://www.pluralsight.com/keith.

Благодарности

Создание данного документа было бы невозможным без огромной помощи сотрудника компании Microsoft Джастина Смита. Его выступления на PDC, а также личные рекомендации и полезные замечания в процессе редактирования, определили содержимое данного документа. Массу замечательных отзывов по данному документу предоставил также Аарон Сконнард из Pluralsight. Спасибо, ребята!

21 Инфраструктура Microsoft под кодовым названием «Geneva». Документация для разработчиков (прим. переводчика).

Показ: