Обзор .NET Access Control Service

Руководство по Microsoft® .NET Access
Control Service для разработчиков
Управление доступом в облаке
Кейт Браун, Pluralsight
Май 2009
Содержание
Аннотация ........................................................................................................................................4
Обзор .NET Access Control Service .....................................................................................................4
Вопросы идентификации........................................................................................................................ 5
Лучший вариант решения – Microsoft .NET Access Control Service...................................................... 5
Модель идентификации на основании утверждений ......................................................................... 6
Введение в идентификацию на основании утверждений ...............................................................6
Терминология идентификации на основании утверждений .............................................................. 7
Удостоверение/идентификация ........................................................................................................ 7
Утверждение........................................................................................................................................ 7
Маркер доступа ................................................................................................................................... 7
Служба сертификации и провайдер удостоверений ....................................................................... 8
Сервис маркеров доступа (STS) .......................................................................................................... 9
Участвующая сторона (RP) .................................................................................................................. 9
Простой сценарий с использованием утверждений и SOAP ............................................................. 10
Стандарты .............................................................................................................................................. 11
Приложения, выполняющиеся в браузере ......................................................................................... 11
Связанные издатели ............................................................................................................................. 13
Интеграция удостоверений для разных областей безопасности ..................................................... 14
Понимание .NET Access Control Service .......................................................................................... 18
Начало работы с ACS ............................................................................................................................. 18
ACS в действии: пример сервиса Calculator ........................................................................................ 18
Настройка .NET Access Control Service ............................................................................................ 24
Учетные записи и решения................................................................................................................... 24
Области действия решения .................................................................................................................. 25
Параметры области действия .............................................................................................................. 26
Издатели удостоверений...................................................................................................................... 27
Типы утверждений ................................................................................................................................ 29
Преобразование утверждений ............................................................................................................ 30
Реализация управления доступом на основании ролей (RBAC) .................................................... 31
Примеры пассивных сценариев ..................................................................................................... 32
Интеграция ACS в веб-приложение ASP.NET....................................................................................... 33
Код Contoso Woodworking .................................................................................................................... 37
Управление через AtomPub ........................................................................................................... 42
Заключение .................................................................................................................................... 49
Дополнительные ресурсы .............................................................................................................. 49
Пакеты документов по Microsoft® .NET Services................................................................................. 49
Ресурсы .NET Access Control Service ..................................................................................................... 50
Об авторе ....................................................................................................................................... 50
Благодарности................................................................................................................................ 50
Аннотация
Цель этого документа – показать разработчикам, как с помощью модели идентификации на
основании утверждений и 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.
Более подробно Microsoft® .NET Services, .NET Access Control Service и .NET Workflow Service рассматриваются в
сопутствующих документах серии «Пакеты документов по Microsoft .NET Services», ссылки на которые можно найти в
конце данного документа.
2
Вопросы идентификации
Первые два вопроса, на которые сегодня приходится отвечать большинству приложений, касаются
идентификации: кем является пользователь и что ему разрешено делать? Аутентификация и
авторизация необходимы различным типам приложений, начиная от веб-сервисов и приложений,
выполняющихся в браузере, заканчивая насыщенными настольными приложениями Windows и
консольными приложениями командной строки. Но несмотря на такую глобальную потребность в
этих возможностях, зачастую приложения используют собственные специальные решения.
Большинство разработчиков не являются экспертами в области безопасности и чувствуют себя
неуверенно при реализации задач по аутентификации, авторизации и персонификации
пользователей. Эти вопросы не рассматриваются в обычном курсе программирования и часто
игнорируются во всем процессе разработки вплоть до самых поздних этапов.
В наши дни не вызывает удивления компания, работающая с десятками или сотнями приложений
и сервисов, многие из которых имеют собственные разрозненные хранилища удостоверений
пользователей, и большинство из которых реализованы аппаратно на использование одного
единственного средства аутентификации. Разработчики знают, как тяжело реализовать поддержку
идентификации в отдельно взятом приложении, и ИТ-специалистам известно, как дорого
обходится обслуживание получающегося в результате набора приложений.
Повсеместное использование паролей привело к широкому распространению фишинг-атак 3 .
Также в условиях, когда многие приложения реализуют собственные решения для
аутентификации и авторизации, зачастую сложно реализовать единую регистрацию или
интегрировать идентификацию для нескольких областей безопасности.
Лучший вариант решения – Microsoft .NET Access Control Service
Решение идентификации, реализацией которого занимается Microsoft в течение последних
нескольких лет, базируется не идее утверждений. Модель идентификации на основании
утверждений позволяет вынести общие функции аутентификации и авторизации из приложений и
реализовать их централизованно во внешних сервисах, написанных и обслуживаемых экспертами
в области безопасности и идентификации, от чего выигрывают все вовлеченные в этот процесс
стороны.
Microsoft® .NET Access Control Service – это сервис в облаке, выполняющий именно это. Вместо
того чтобы создавать собственную базу данных учетных записей и ролей, можно поручить ACS
управление аутентификацией и авторизацией своих пользователей. ACS использует
существующие хранилища учетных записей пользователей, такие как Windows Live ID, Active
3
Фишинг заключается в вынуждении пользователя к разглашению конфиденциальных данных (таких как пароли).
Обычно это делается путем отправки электронного письма, якобы от лица легальной компании, в которой пользователь
может иметь учетную запись. Это электронное письмо включает ссылку, которая приводит на веб-сайт
злоумышленников, внешне похожий на официальный веб-сайт данной компании. Когда пользователь
«регистрируется», его пароли и другая информация, которую удастся выманить, попадает к злоумышленникам.
Directory, а также любые другие хранилища, поддерживающие стандартные протоколы
интеграции, о которых мы поговорим немного позже. Это делает естественным использование
единой регистрации для всех приложений, а также является замечательным способом
централизации логики аутентификации и управления доступом, что упрощает приложения.
Модель идентификации на основании утверждений
При работе с приложениями, поддерживающими утверждения, пользователь предоставляет
удостоверения в виде набора утверждений (рис. 1). Одно утверждение может быть именем
пользователя, другое – адресом его электронной почты, и т.д. Эти утверждения предоставляются
службой сертификации, которая знает, как аутентифицировать пользователя и где взять его
атрибуты. Клиентское приложение, в роли которого может выступать браузер или насыщенный
клиент, прозрачно взаимодействует с этой службой, получая эти утверждения и передавая их в
ваше приложение. В конечном итоге, ваше приложение получает все необходимые данные
удостоверения пользователя в виде набора утверждений. Кроме того, утверждения подписаны,
что обеспечивает криптографическую гарантию их происхождения.
User Name:
Roles:
Email:
IsOfLegalVotingAge:
Alice
Manager, Staff
alice@fabrikam.com
True
Web App/Service
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 (чаще всего как SAML 4 ), и подписанный цифровой
подписью службой сертификации. Подпись имеет важное значение, потому что является гарантом
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.
ACS также включает конечные точки SOAP и REST для программного администрирования, а также набор классов .NET,
упрощающих использование этих конечных точек. Таким образом, можно создать собственную консоль
администрирования, если вас не устраивает предоставляемая ACS или если есть желание провести настройку
соответственно предметной области.
6
Рис. 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
После рассмотрения терминологии можно перейти к примеру универсальной системы,
использующей утверждения, в действии.
2. Get Claims
Issuing
Authority
Smart
Client
STS
1. Get WSDL
Application
3. Send Claims (Web Service)
Active Client
(WS-Trust)
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-Trust 8 , которая описывает
процессы запроса и получения маркеров доступа.
Еще один важный стандарт – 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, чтобы пользователю не
приходилось обращаться к провайдеру удостоверений при каждом запросе. Спецификация WSFederation включает раздел 10 , в котором описывается, как сделать все это, обеспечивая
взаимодействие.
Находите на рис. 3 сходные моменты с примером веб-сервиса? Клиент точно так же обращается к
службе сертификации для получения утверждений и затем отправляет их приложению.
В этот пример добавлена лишь потенциальная возможность наличия нескольких служб
сертификации. Например, приложение могло бы сначала перенаправляться на ACS, который затем
направлял бы его к Windows Live ID. Это может применяться и к веб-сервисам. В этом случае, путь,
преодолеваемый смарт-клиентом, определялся бы политикой приложения и всех участвующих
издателей.
10
Чтобы быть точным, раздел 13. Вероятно, вы встречали, что ранее его называли профилем пассивной
запрашивающей стороны (passive requestor profile), но на момент написания данного документа последняя версия WSFederation больше не использует этот термин.
2. Redirect
Issuing
Authority
Web
Page
1. HTTP GET
Browser
3. HTTP POST
Application
(Web App)
Passive Client
(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
Fabrikam
Bob’s Issuer
Fabrikam
Issuer
STS
STS
1
Client
2
3
Application
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
.NET Apps
Java Issuer
.NET Issuer
STS
STS
1
Client
2
3
.NET
Application
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 включает три основных составляющих: сервис
маркеров доступа, который выпускает маркеры
Любопытно отметить, что при
доступа;
портал
администрирования
–
пользовательский
веб-интерфейс,
который
регистрации на портале Azure
позволяет
конфигурировать
настройки,
Services Portal вы, фактически,
определяющие структуру маркеров; и API
используете ACS! Для
администрирования. Данный документ не
аутентификации и авторизации
обсуждает API администрирования, потому что
доступа веб-приложение портала
сейчас
он
подвергается
существенным
полагается на Windows Live ID и ACS.
изменениям. Но достаточно сказать, что все, что
можно сделать через портал администрирования,
можно будет делать через 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.");
}
Рис. 7: Код вспомогательного метода DemandActionClaim
На рис. 10 представлен вспомогательный метод DemandActionClaim. Возможно, вы не знаете
этого, но WCF создавался с учетом утверждений. Видите, как OperationContext (Контекст
операции) предоставляет доступ к ряду наборов утверждений? Каждый набор утверждений
представляет маркер доступа. Данный цикл перебирает этот набор и находит маркер (в данном
случае, он единственный, выпущенный ACS). Затем выполняется поиск конкретного типа
(прописанный в коде URI, оканчивающийся на /action, идентифицирует утверждение Action) и
проверяется наличие значения, указанного вызывающей стороной («Calculator.Add», например), и
то, что утверждение выпущено ACS12. Если эти требования не выполняются, вспомогательный
метод завершается формированием исключения «Access denied».
На рис. 11 представлен результат выполнения клиентского приложения, для которого настроены
все эти четыре правила. Я убедился в том, что правильно ввел имя решения и пароль, т.е. могу
получить доступ. Если бы пароль был введен неправильно, было бы выведено исключение,
сообщающее о невозможности аутентифицировать меня на ACS.
«Ibn» очевидно, старое внутреннее кодовое имя ACS, поэтому не дайте вспомогательному методу
IsIssuedByIbn сбить вас с толку.
12
Рис. 8: Выполнение клиента со всеми четырьмя утверждениями Action
Получив рабочее решение, возвращаемся к правилам и деактивируем Calculator.Divide, просто
убирая соответствующий ему флажок (рис. 8). И опять выполняем клиент. На этот раз, он получил
только три из четырех утверждений Action, и ему было отказано в доступе к операции Divide
(рис. 12).
Рис. 9: Выполнение клиента после деактивации одного из утверждений Action
Далее, попробуем ввести другое имя решения и пароль для ACS. На рис. 13 представлен
результат.
Рис. 10: Выполнение клиента с использованием другого имени пользователя
Как видите, я смог указать имя пользователя и пароль другого решения (xyzzy), но вернемся к
рис. 8 и вспомним, что заданные правила ожидают именно утверждения UserName со значением
«asolution», а не «xyzzy». Поэтому в результате я получил маркер без утверждений Action и не мог
выполнять ни одну из операций сервиса Calculator (например, логика авторизации
DemandActionClaim дала сбой, в данном случае).
Наконец, я задал «asolution» с неверным паролем, чтобы имитировать злоумышленника, который
захочет использовать приложение, не зная пароля. Что в результате? WCF сформировала
исключение, указывающее на то, что вызывающая сторона не может быть аутентифицирована.
Итак, ACS даже не делал попытки выпустить маркер в данном случае, потому что он не смог
установить достоверность предоставленных мною имени пользователя и пароля.
Если поэкспериментировать с этим примером SDK, можно заметить, что в нем используется
модель программирования утверждений, встроенная в WCF в настоящий момент
(System.IdentityModel). Вместо этого можно установить Geneva Framework и использовать ее
модель программирования. Geneva Framework – это более современный подход к
программированию работающих с утверждениями приложений. Он характеризуются большей
гибкостью и более богатым набором возможностей, также он точнее представляет будущее
программирования продуктов для работы с утверждениями, исходя из тенденций развития
Microsoft .NET 13 . Поскольку ASP.NET 2.0 не поддерживает утверждения, Geneva Framework
является наилучшим вариантом для организации работы с утверждениями в этом сценарии, как
будет показано в примере в конце данного документа.
Настройка .NET Access Control Service
В данном разделе подробно рассматриваются различные варианты настройки ACS и
продолжается обсуждение принципов идентификации.
Учетные записи и решения
Каждая учетная запись в ACS ассоциирована с единственным Windows Live ID (WLID). Каждая
учетная запись ACS имеет набор решений. В ACS решение может рассматриваться как виртуальная
служба сертификации с собственным STS и набором веб-страниц, на которые перенаправляются
браузеры для получения маркеров SAML (рис. 14).
Account
WLID: bob@fabrikam.com
Solution
Name: BobsFirstSolution
Rules Solution
Credentials
Name: BobsSecondSolution
Endpoints
Scopes
Credentials
STS and
web pages
for passive
clients
Account
Учетная запись
Solution
Решение
Scopes
Области действия
Credentials
Учетные данные
STS and web pages for passive clients
STS и веб-страницы для пассивных клиентов
Рис. 11: Учетные записи и решения
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, ассоциированный с приложением, например,
14
Например, urn:foo – действительный URI, хотя и не уникальный.
http://www.fabrikam.com/expenseReportingService. Очевидное преимущество в том, что сразу
видно, на какое приложение указывает имя, а также в этом случае практически невозможно по
ошибке присвоить один и тот же URI двум разным приложениям.
Каждое ACS-решение может курировать несколько приложений. Отсюда следует, что у каждого
приложения в решении должна быть собственная область действия с настройками,
соответствующими данному приложению. Вот почему на рис. 14 у каждого решения можно
видеть набор областей действия. Область действия это не что иное, как настройки для
конкретного приложения.
Параметры области действия
Настройки области действия включают правила, определяющие, как ACS формирует утверждения
для приложения, но также и другие важные элементы, такие как открытый ключ, используемый
ACS для подписи маркеров доступа.
Scope Settings
Параметры области действия
Rules
Правила
Identity Issuers
Издатели удостоверений
Claim Types
Типы утверждений
Encryption Preferences
Предпочтения шифрования
Expiration Preferences
Предпочтения срока действия
Permissions
Разрешения
Рис. 12: Параметры в области действия
Здесь будут рассмотрены самые простые настройки, и наиболее интересным из них посвящены
отдельные разделы. Один из самых простых параметров – срок действия (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.
Рис. 13: Издатели удостоверений
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.
Рис. 14: Типы утверждений в 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».
Рис. 15: Преобразования утверждений в применении к именам ролей
Реализация управления доступом на основании ролей (RBAC)
Как выясняется, ACS реализует прямое построение цепочки правил. Таким образом, утверждения
могут преобразовываться в несколько этапов, благодаря чему очень просто реализовать
иерархическую систему RBAC. Эти системы обычно принимают группы пользователей в качестве
входящих данных, отображают их в роли и затем проецируют эти роли на логические операции,
которые имеют право выполнять данные пользователи. Для этого используются утверждения
Group и Action.
В предыдущем примере (рис. 19) были смоделированы роль «Manager» и утверждение Group. На
рис. 20 представлен расширенный вариант этого примера, где роль «Manager» проецируется в
несколько логических операций. Эти операции моделируются утверждениями Action. Таким
образом, наше гипотетическое приложение для составления отчета о расходах будет вести поиск
следующих утверждений:
Рис. 16: Преобразование утверждений 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).
Рис. 17: Главная страница, какой ее видят анонимные пользователи
Попав на главную страницу, пользователь, желающий использовать сервис, должен
зарегистрироваться. Для этого необходимо нажать кнопку Login. Это обеспечит переход
пользователя на ACS, который немедленно перенаправит пользователя на WLID для регистрации
(рис. 22).
Рис. 18: Регистрация с использованием Windows Live ID
После успешной регистрации пользователя (пусть это будет Алиса) WLID возвращает браузер к
ACS, который обрабатывает утверждения, предоставленные WLID, применяет правила
соответствующей области действия для формирования утверждений для Алисы, которые имеют
смысл для Contoso Woodworking, и затем посредством запроса POST передает эти утверждения в
форме шифрованного SAML-маркера назад на главную страницу Contoso Woodworking. Эффекты,
представляемые пользователю, очень естественны: Алиса нажимает кнопку входа и видит
страницу регистрации WLID. После регистрации она возвращается на сайт Contoso Woodworking,
который отражает ее зарегистрированное состояние (вместо кнопки «Login» появилась кнопка
«Logout» (Выход)) (рис. 23).
Рис. 19: Главная страница после регистрации
Поскольку Алиса ранее зарегистрировалась в Contoso для использования их сервиса, она может
просматривать предлагаемые компанией инструменты, переходя по ссылке View Tools
(Инструменты) (рис. 24). Но поскольку она еще не подписала документ на использование
механических инструментов, их она видеть не может.
Рис. 20: Обычный пользователь может просматривать лишь «безопасные» инструменты
На рис. 25 представлено правило, применяемое Contoso после регистрации пользователя (Алисы,
в данном случае) для работы с их сервисом. Оно обеспечивает поиск WLID Алисы и его
проецирование в утверждение типа Action «ContosoWeb.ViewTools», которое Contoso
Woodworking использует при принятии решения об отображении инструментов.
Рис. 21: Настройка ACS для предоставления Алисе разрешения на просмотр обычных
инструментов
Как только Алиса подпишет документ об использовании механических инструментов, Contoso
предоставит ей доступ к ним на Contoso Woodworking. Для этого требуется лишь обновить
правила и предоставить Алисе утверждение типа Action «ContosoWeb.PowerTools», как показано
на рис. 26.
Рис. 22: Добавление утверждения Action, которое обеспечивает Алисе возможность доступа к
механическим инструментам
Когда Алиса зарегистрируется в следующий раз, она уже будет видеть и механические
инструменты (рис. 27).
Рис. 23: После подписания соответствующего документа пользователь может видеть и
механические инструменты
Это очень простой пример, разработанный для наглядной демонстрации возможности
использования ACS для реализации аутентификации и управления доступом в веб-приложении.
Этот прямой подход предоставления утверждений Action отдельным пользователям не обладает
достаточной масштабируемостью и может стать довольно громоздким, если таким образом
потребуется управлять тысячами пользователей. Но ACS может обеспечить масштабируемость в
случае необходимости.
Хорошим решением является использование иерархического подхода, описанного в разделе,
посвященном управлению доступом на основании ролей. Когда пользователи объединены в
группы посредством ACS-утверждений типа Group, не составляет никакого труда добавить
соответствующие утверждения Action в каждую из групп. Если правил довольно много, что делает
портал ACS неудобным в использовании, можно обратиться к API администрирования и управлять
правилами программно.19
До сих пор мы рассматривали, как аутентифицировать пользователей с помощью Windows Live ID.
Такой подход хорош для отдельных любителей или корпораций, не имеющих инфраструктуры
интегрированной идентификации. Но представим, что компания Fabrikam развернула Geneva
Server (или любой другой продукт интеграции удостоверений) и подписала соглашение,
19
Я говорил ранее, что этот API претерпевает существенные изменения в данный момент, но если вы желаете увидеть
некоторый код текущей версии, в подпапке Samples\AccessControl\ExploringFeatures\AccessControlManagement каталога
.NET Services SDK можно найти два примера.
соответственно которому определенные сотрудники Fabrikam могут арендовать инструменты
Contoso Woodworking.
Чтобы реализовать это, 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>
<section name="microsoft.identityModel"
type="...MicrosoftIdentityModelSection..."/>
</configSections>
<system.web>
<compilation>
<assemblies>
<!-- стандыртные сборки ASP.NET опущены для краткости -->
<add assembly="Microsoft.IdentityModel, ..."/>
</assemblies>
</compilation>
<!-- аутентификацию будет выполнять ACS, не ASP.NET -->
<authentication mode="None"/>
</system.web>
<system.webServer>
<modules>
<add name="WSFederationAuthenticationModule"
type="Microsoft.IdentityModel..."
preCondition="managedHandler"/>
<add name="SessionAuthenticationModule"
type="Microsoft.IdentityModel..."
preCondition="managedHandler"/>
</modules>
</system.webServer>
<microsoft.identityModel>
<serviceCertificate>
<certificateReference
findValue="CN=ContosoWoodworking"
x509FindType="FindBySubjectDistinguishedName"
storeLocation="LocalMachine"
storeName="My"/>
</serviceCertificate>
<audienceUris>
<add value="http://localhost/ContosoWoodworking/Default.aspx"/>
</audienceUris>
<federatedAuthentication enabled="true"/>
<issuerNameRegistry type="...">
<trustedIssuers>
<add thumbprint="416e6fa5d982b096931fbf42c4a3dcd608856c95"
name="http://accesscontrol.windows.net/asolution/"/>
</trustedIssuers>
</issuerNameRegistry>
</microsoft.identityModel>
</configuration>
Рис. 24: Файл web.config сервиса Contoso Woodworking
Несколько интересных замечаний о конфигурационном файле:


20
<configSections> объявляет раздел для microsoft.IdentityModel (Geneva Framework)
<assemblies> извлекает ссылку на сборку Geneva Framework из GAC20
GAC == Global Assembly Cache (Глобальный кэш сборок)




<modules> подключает модуль WSFederationAuthenticationModule, который обеспечивает
интегрированную аутентификацию, а также модуль SessionAuthenticationModule, который
реализует основанный на cookie сеанс регистрации, что избавляет пользователя от
необходимости постоянно обращаться за аутентификацией (оба этих модуля входят в
состав Geneva Framework)
<serviceCertificate> указывает Geneva Framework, какой сертификат должен использоваться
для дешифровки SAML-маркеров, полученных от ACS
<audienceUris> указывает Geneva Framework, куда отправлять (посредством запроса POST)
SAML-маркеры
<issuerNameRegistry> указывает Geneva Framework на то, что можно доверять только
SAML-маркерам, подписанным ACS и выпущенным специально для соответствующего
решения (мое решение называется «asolution»; при воспроизведении этого примера
используйте имя своего решения)
Когда анонимный пользователь направляет свой браузер на 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 и поддержки множества
провайдеров удостоверений.
<%@
<%@
<%@
<%@
Application Language="C#" %>
Import Namespace="Microsoft.IdentityModel.Web" %>
Import Namespace="Microsoft.IdentityModel.Claims" %>
Import Namespace="Microsoft.IdentityModel.Protocols.WSFederation" %>
<script runat="server">
void Application_AuthenticateRequest(Object sender, EventArgs e)
{
IClaimsIdentity identity =
HttpContext.Current.User.Identity as IClaimsIdentity;
if (identity != null) return;
WSFederationAuthenticationModule authModule =
new WSFederationAuthenticationModule();
// имя области действия
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>
Рис. 25: 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";
}
Рис. 26: Задание текста кнопки 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();
}
}
Рис. 27: Выборочное связывание с данными в зависимости от утверждений
В представленном выше фрагменте кода применяется вспомогательный класс 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;
}
}
Рис. 28: Использование LINQ для поиска утверждения типа Action ContosoWeb.PowerTool
Как видите, на самом деле, совсем не так сложно начать использовать ACS в приложении ASP.NET
уже сегодня. И будьте уверены, в будущем это будет еще проще, поскольку в Visual Studio
появится больше инструментов для поддержки Geneva Framework и ACS.
Управление через AtomPub
В моих примерах считайте,
что URL и URI
эквивалентны. Различия
между ними не так важны
для вопросов,
рассматриваемых данным
документом.
Портал 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 на экран
выводится диалоговое окно, предлагающее ввести учетные данные. Я ввожу имя моего решения и
пароль:
Рис. 29: Для доступа к интерфейсу управления используйте имя и пароль своего решения
После введения пароля браузер представляет список областей действия в виде канала Atom. При
выполнении этого пример в моем решении было определено три области действия. Все три
можно увидеть на рис. 35.
Рис. 30: Просмотр областей действия в Internet Explorer
К сожалению это максимум, что я мог получить, используя браузер, потому что содержимое этих
ресурсов форматировано не как HTML, а как XML. На момент написания данного документа
браузеры не умеют правильно отображать документы atom, включающие XML-содержимое. Но
формат atom спроектирован с обеспечением возможности просмотра, поэтому я добавил
небольшое WPF-приложение, которое позволит просматривать ресурсы. Это приложение
называется Feed Browser, его можно скачать здесь.
Проникнув в одну из этих областей с помощью Feed Browser (рис. 36), я немедленно обнаружил
несколько настроек, которые можно просматривать или изменять через интерфейс управления.
Рис. 31: Просмотр области действия с помощью приложения Feed Browser
Feed Browser имеет две панели для представления информационного ресурса. Справа
представлен необработанный XML-ответ. Этот ответ очень просто получить программно, в .NET
Framework для этого потребуется лишь несколько строк кода, они будут показаны ниже. Обратите
внимание, что в каждом ответе имеются метаданные, включающие id, заголовок, дату последнего
обновления, некоторые ссылки и само содержимое узла. Feed Browser просматривает эти данные
и выводит ссылки в панели слева, чтобы обеспечить пользователю возможность без труда
переходить по иерархии ресурсов. Я не занимался декорированием вывода содержимого, но и в
этом случае для области действия можно увидеть ее имя, Uri (который мы видим на портале ACS)
и решение, которому она принадлежит.
Щелкнув ссылку Rules (Правила), вы попадаете в канал, содержащий записи для всех правил
области действия (рис. 37). Отсюда можно переходить в каждое правило в отдельности, но сам
канал уже представляет все данные правил. Каждое правило содержит входное и выходное
утверждения. Их можно также увидеть и на портале, но использование интерфейса AtomPub
позволяет писать собственный код для просмотра и изменения правил. Feed Browser – инструмент
исключительно для чтения, поэтому не может использоваться для обновления правила, но
позднее я приведу пример того, как это делается.
Рис. 32: Список правил для области действия
Для доступа к интерфейсу управления не обязательно использовать такой инструмент, как 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);
Рис. 33: Извлечение списка правил программно, с помощью .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/s
a275fb535eaa4493a36994377634fb6f/rules" />
Рис. 34: Использование элементов <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 – консольное приложение):
Рис. 35: Выполнение примера 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-addd95ee9b046994/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». Документация для разработчиков (прим.
переводчика).