Авторизация и безопасность с Windows Azure Active Directory

Программная модель Windows Identity Foundation

IClaimsPrincipal

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

IClaimsPrincipal предоставляет метод IsInRole, возвращающий булевый тип в зависимости от того, есть ли в утверждениях объекта утверждение типа Role и является ли значение этого утверждения равным чему-то (например, Domain Admins в контексте Windows-домена). Также интерфейс предоставляет коллекцию личностей, каждая из которых реализует IClaimsIdentity. В общем случае в контексте выполнения находится один издатель и один токен, полученный от него, и коллекция Identity содержит только один элемент.

ClaimsIdentity

Интерфейс ClaimsIdentity определяет базовую функциональность объекта ClaimsIdentity и рекомендуется для использования и обеспечения доступа к методам и свойствам ClaimsIdentity вместо использования непосредственно ClaimsIdentity. Все объекты типа ClaimsIdentity реализуют интерфейс IClaimsIdentity, который расширяет стандартный IIdentity, оставляя при этом базовую функциональность IIdentity. IClaimsIdentity содержит коллекцию Claims – утверждений, привязанных к личности (например, имя или e-mail).

Claim

Claim определяет свойство аутентифицированного объекта, которое было выпущено провайдером идентификации – например, членство в определенной группе, возраст и так далее. Содержит поля Claim.ClaimType (строка, обычно URI на описание типа утверждения. например http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name – тип, описывающий значение имени) и Claim.ValueType (и Claim.Value), содержащие тип значения и значение соответственно.

ClaimsPrincipal

ClaimsPrincipal предоставляет статическое свойство Current, которое является IClaimsPrincipal, ассоциированным с текущим контекстом выполнения.

Windows Azure Access Control Service

Одним из главных преимуществ аутентификации на основе утверждений является возможность децентрализации – вместо того, чтобы возлагать на STS обязанность аутентифицировать удаленных пользователей (в компании Б) настраиваются отношения доверия с STS в компании Б, что будет означать, что STS будет доверять STS компании Б в вопросах аутентификации в Realm компании Б. Таким образом можно обойтись без дополнительных учетных данных для удаленных пользователей – они продолжат пользоваться учетными данными своего домена. Преимущества подобного подхода очевидны – архитектура не претерпевает принципиальных изменений, специалистам, занимающимся STS в компании А, нет необходимости отслеживать активность учетных данных, для новых Realm-ов же просто настраиваются отношения доверия с соответствующими STS (в терминологии федеративной аутентификации настройка доверия заключается в обмене специального формата генерируемыми XML-файлами).

Таким образом, Windows Azure Access Control Service предоставляет сервис для обеспечения федеративной безопасности и контроля доступа к облачным или локальным приложениями. Windows Azure Access Control Service предоставляет возможность создания облачные и локальные приложения, работающие с множеством провайдеров идентификации, с использованием открытых стандартов и протоколов (WS-Federation, WS-Trust, SAML, OAuth 2.0, SWT, JWT).

Windows Azure Access Control Service состоит из следующих компонентов:

1. Security Token Service. Набор конечных точек, которые могут выдавать токены для RP-приложений, реализовывая федеративную аутентификацию для этих приложений. Поддерживаются самые популярные протоколы и платформы – .NET Framework, WCF, Silverlight, ASP.NET , Java, Python, Ruby, PHP, Flash, OAth WRAP, OAuth 2.0, WS-Trust, WS-Federation.

   Адреса конечных точек для Windows Azure Access Control Service STS можно получить с портала управления Windows Azure Access Control Service – для точки WS-Federation Metadata, которая используется для интеграции веб-приложений с Windows Azure Access Control Service (эти метаданные могут быть использованы приложением с WIF) – и для точки Windows Azure Access Control Service Management Service, которая используется для программного управления Windows Azure Access Control Service.
2. Портал управления Windows Azure Access Control. Портал, с которого происходит управление пространством имен Windows Azure Access Control Service. Предоставляет основную функциональность.
3. Сервис управления (Management Service). Сервис для программного управления Windows Azure Access Control Service с использованием протокола OData.
4. Движок трансформации токена по правилам (Token Transformation Rule Engine). В своей работе Windows Azure Access Control Service может манипулировать состоянием утверждений. Основная задача – получить утверждения во входящем токене, обработать их согласно настроенным правилам, выпустить выходящие утверждения и инкапсулировать их в токен для RP-приложения.
5. Провайдеры идентификации. Токены безопасности для Windows Azure Access Control Service предоставляются заранее настроенным набором провайдеров идентификации, которые могут быть как публичными, так и локальными для организации (с использованием AD FS).

Windows Azure Access Control Service создает список преднастроенных провайдеров идентификации, из которого разработчик выбирает те, через которые хочет аутентифицироваться, и может создать собственную страницу с этим список и список правил, по которым Windows Azure Access Control Service будет обрабатывать утверждения провайдера идентификации.

При первом запросе наприложения определяется, что пользователь не аутентифицирован, и его браузер перенаправляется на Windows Azure Access Control Service, который создаёт и отдаёт браузеру список доступных провайдеров идентификации, который может содержать любых провайдеров идентификации, от публичных до локальных каталогов Active Directory, предоставляющих данные через AD FS 2.0. Пользователь выбирает необходимого провайдера идентификации, после чего перенаправляется на страницу входа в систему соответствующего провайдера идентификации. После входа в систему пользователя провайдер идентификации возвращает токен Windows Azure Access Control Service с утверждением о том, что пользователь аутентифицирован. Windows Azure Access Control Service выпускает утверждения на основе того, что передал ему провайдер идентификации, и токен безопасности, после чего перенаправляет пользователя на приложение. Приложение использует полученный от Windows Azure Access Control Service токен безопасности для определения набора привилегий пользователя. Таким образом, в реальном режиме меняется приоритет участников – сначала провайдер идентификации (Live ID) определяет то, что пользователь имеет право на вход в систему, и возвращает утверждения, после этого приоритет переходит к Windows Azure Access Control Service, и браузер пользователя "предъявляет" токен безопасности Live ID, и Windows Azure Access Control Service создаёт новый токен безопасности на основе этих же утверждений (режим copy claim), при этом Windows Azure Access Control Service может в процессе произвести некоторые преобразования утверждений, в том числе, например, добавив некоторые сведения о принадлежности пользователя к определенной группе.

Active Directory Federation Services 2.0

Центральное место в ADFS 2.0 занимает сервис токенов безопасности (Security Token Service, STS), который использует Active Directory как хранилище, из которого получаются учетные данные пользователей, Lightweight Directory Access Protocol (LDAP), SQL или собственный источник данных как хранилище атрибутов. STS в ADFS 2.0 может выдавать маркеры защиты по различным протоколам, в том числе WS-Trust, WS-Federation и Security Assertion Markup Language (SAML) 2.0. ADFS 2.0 STS также поддерживает форматы маркеров SAML 1.1 и SAML 2.0.

ADFS 2.0 может применяться в нескольких распространенных случаях, например, использование ADFS 2.0 в качестве провайдера идентификации. AD FS прозрачно интегрируется с платформой Windows Azure, позволяя аутентифицировать внутренних пользователей любым набором их учетных данных. С помощью AD FS можно реализовать принцип Single Sign-On, как с собственным приложением, размещенным в облаке, так и интегрировав его с другими продуктами Microsoft – Office 365 и Sharepoint. AD FS использует аутентификацию на основе утверждений, позволяя манипулировать ими – принимать на вход, например, пользователя с ролью администратор (согласно ролевой модели в Active Directory) и выдавая на выход в токен утверждение о том, что это – пользователь с уровнем доступа, например, Privileged. Лицензия на AD FS 2.0 автоматически предоставляется владельцу лицензии на Windows Server 2008 R2 Enterprise Edition.

Принципиально AD FS не отличается от обсуждённых выше провайдеров идентификации, добавляя лишь дополнительную инфраструктурную и программную гибкость. Например, если сервер AD FS 2.0 расположен во внутренней сети и не может получать запросы извне, можно расположить в демилитаризованной зоне сервер Federation Service Proxy, который будет маршрутизировать запросы на утверждения на внутренний AD FS сервер (серверы) либо другие провайдеры идентификации.

Многофакторная проверка подлинности Windows Azure

Летом 2013 года в систему безопасности Windows Azure была внедрена новая опциональная функциональность – многофакторная проверка подлинности. Данная функциональность предназначена для защиты учетных записей и облачных сервисов Microsoft, решений сторонних компаний или приложений и сервисов, которые используют в качестве системы аутентификации сервис Windows Azure Active Directory. Многофакторная проверка подлинности Windows Azure предоставляет дополнительный слой проверки подлинности в дополнение к учетным данным пользователя. При этом многофакторную проверку подлинности можно использовать для защиты доступа как к расположенным on-premise, так и облачным приложениям. К возможным опциям многофакторной проверки подлинности относятся мобильные приложения, телефонные звонки и текстовые сообщения, при этом пользователи могут выбрать то, что наиболее удобно для них. В контексте защиты локальных приложений многофакторную проверку подлинности можно использовать для защиты VPN удаленного доступа и Web-приложений с помощью специального SDK. Если облачное приложение использует Active Directory Federation Services, то разработчик может настроить синхронизацию с Windows Server Active Directory или другим каталогом LDAP. Что же касается других сервисов Microsoft, то многофакторная проверка подлинности будет полезна для защиты доступа к Windows Azure, Microsoft Online Services, Office 365 и Dynamics CRM Online.

Заключение

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

Программные средства обеспечения аутентификации и авторизации, такие как Windows Identity Foundation, Active Directory, Active Directory Federation Services, Windows Azure Active Directory и MFA, обеспечивают еще один слой безопасности, которым может воспользоваться разработчик для предоставления опций пользователю.