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

Аутентификация на базе утверждений

Сервис Windows Azure Active Directory предлагает возможность управления процессом аутентификации, доступом к приложениям с помощью аутентификации на основе утверждений. С помощью этого сервиса можно обеспечить единый вход (Single SignOn), повышенную безопасность и простое взаимодействие с уже развернутыми в Active Directory приложениями, а также выполнить интеграцию приложения с другими популярными провайдерами аутентификации (Microsoft Account, Google, Facebook и т.д.). Windows Azure Active Directory — это полноценная реализация каталога в облаке. При этом сервис поддерживает популярные открытые стандарты обеспечения федеративной аутентификации: SAML 2.0, OData, WS-FED, OAuth 2.0/OpenID, JSON Web Token (JWT), SWT. Авторизация происходит иначе, Windows Azure Active Directory предоставляет возможность аутентификации. Авторизация в этом случае подразумевает под собой определение прав объекта, аутентификация – определение, имеет ли объект право на вход в систему.

Методы обеспечения аутентификации на основе утверждений позволяют реализовать различные сценарии доверия между несколькими системами для осуществления обмена информацией, в том числе конфиденциальной, например, Email-адресами или информацией о заказах, используя для этого набор стандартов WS-*, описывающих токен Security Assertion Markup Language. Аутентификация на основе утверждений предлагает упрощение процесса аутентификации за счёт использования привычных пользователю провайдеров идентификации, таких как Windows Live ID, Facebook и локальный доменный каталог Active Directory.

Любая система, использующая аутентификацию на основе утверждений, пользуется определенным набором терминов. Утверждение является некоторой информацией об объекте, которую предоставляет провайдер идентификации. Например, есть некоторое предложение, что "Уважаемая компания А, моё имя – Александр, фамилия – Иванов, и это подтверждается паспортом, который был выдан компанией Б". В данном случае утверждением будет являться набор данных Имя-Фамилия. Вторая часть о паспорте – это токен безопасности (Security token), объект с электронной подписью, который и содержит утверждение (-я). Третьей частью является провайдер идентификации (Security Token Service) – доверенная компания/объект, который имеет право выпускать токены безопасности, содержащие утверждения. "Компания А" – это объект, которому требуется получить токен безопасности для предоставления входа в систему либо доступа к защищённой функциональности системы (Relying Party).

В отдельных сценариях может также присутствовать провайдер федерации (Federation Provider) – провайдер идентификации и брокер между приложением и личностью в провайдере идентификации (Facebook, Live ID, и так далее). Разработчик настраивает аутентификацию таким образом, что конечное приложение, которым пользуется пользователь, доверяет только провайдеру федерации (в контексте отношений приложение-провайдер федерации является провайдером идентификации), провайдер федерации же доверяет набору провайдеров идентификации, также настроенному разработчиком, и в контексте данных отношений провайдер федерации является приложением relying party, получающим токен безопасности от провайдеров идентификации. Таким образом, конечное приложение знает только о провайдере федерации, который скрывает от него детали реализации аутентификации с использованием реальных провайдеров идентификации.

Федеративная аутентификация в Windows Azure с использованием публичных провайдеров идентификации и доменного каталога Active Directory

Для того, чтобы лучше понять федеративную аутентификацию с использованием Windows Azure, разберём пример с уже настроенной инфраструктурой. В инфраструктуре установлены: домен уровня Windows Server 2008 R2, AD FS 2.0, WIF, WIF SDK 4.0, Windows Azure Access Control Service, приложение в облаке Windows Azure с адресом https://techdaysdemo.cloudapp.net.

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

Придя на работу, пользователь ввел свои учетные данные на компьютере в домене. В этот момент происходит взаимодействие с контроллером домена Active Directory – проверяются учетные данные, и контроллер домена отправляет пользователю два сообщения – Client/TGS Session Key, зашифрованный секретным ключом пользователя, и Ticket Granting Ticket (который включает в себя служебные данные – сетевой адрес, период жизни тикета и так далее), зашифрованный секретным ключом Ticket Granting Service (TGS, сервиса выдачи тикетов). Пользователь, получив оба сообщения, расшифровывает первое сообщение секретным ключом, сгенерированным из пароля, и получает Clients/TGS Sesion Key, который используется для дальнейших коммуникаций с TGS. Второе сообщение он прочитать не может, так как не знает ключа TGS. Если в процессе аутентификации не произошло ошибок, то пользователь становится аутентифицирован в домене.

Через несколько часов пользователь запускает браузер и переходит на https://techdaysdemo.cloudapp.net. Приложение настроено для Windows Azure Access Control Service как Relying Party. Для приложения Windows Azure Access Control Service является провайдером идентификации. Однако Windows Azure Access Control Service не является провайдером идентификации по своей сути – для него настроены доверенные отношения с сервером AD FS 2.0, расположенным в организации пользователя. Windows Azure Access Control Service выступает для AD FS 2.0 как Relying Party, таким образом AD FS выступает в роли провайдера идентификации.

Теперь, когда пользователь заходит на сайт https://techdaysdemo.cloudapp.net, его автоматически перенаправляет сначала на Windows Azure Access Control Service, который запускает процесс Home Realm Discovery. У Windows Azure Access Control Service есть список Home Realm, с которыми у него есть доверенные отношения. Определяющим для Home Realm Discovery является аргумент, который предоставляется пользователем в URL.

Строка запроса при редиректе (302) на сервис Windows Azure Access Control Service выглядит так: https://ahrimanacs.accesscontrol.windows.net/v2/wsfederation?wa=wsignin1.0&wtrealm=https%3a%2f%2ftechdaysdemo.cloudapp.net%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252f&wct=2012-05-07T11%3a06%3a15Z GET 302

Где wa – описание действия (signin – либо вход, либо signout – выход), wtrealm – URL доверенного Realm, куда направляется токен - приложение, wctx – контекст, передающийся странице (в данном случае контекст является пассивным). В данном запросе отсутствует дополнительное значение wreply, содержащее указание на то, куда пользователь должен быть перенаправлен с полученным RSTR. Часть ссылки до wsfederation – точка вхождения для пассивного STS WS-Federation в Windows Azure Access Control Service.

Далее Windows Azure Access Control Service перенаправляет пользователя на сервер AD FS 2.0.

На сервер Active Directory отправляется выданный пользователю TGT, сервер создаёт Service Ticket и передает пользователю. Этот тикет используется в коммуникациях с сервером AD FS 2.0. Сервер AD FS 2.0 определяет, что пользователь аутентифицирован, и обращается к серверу Active Directory за атрибутами для этого пользователя. На сервере AD FS 2.0 происходит создание SAML-токена с полученными атрибутами (утверждениями) и его подписание. SAML-токен выдается веб-браузеру пользователя для передачи его Windows Azure Access Control Service. Теперь Windows Azure Access Control Service может определить, что подпись верна, и создать собственный SAML-токен путем либо копирования из первичного SAML-токена атрибутов, либо с использованием механизма под названием Rules Engine, который копирует атрибуты, но позволяет производить над ними манипуляции. Windows Azure Access Control Service пересылает свой SAML-токен веб-браузеру, и только после этого веб-браузер попадает снова в веб-приложение (с SAML-токеном). На уровне приложения используется WIF HTTP модуль WSFederationAuthentificationModule (FAM), который перехватывает POST-запрос от веб-браузера с токеном и производит проверку этого токена, проверяя список слушателей и дату истечения токена. Список слушателей – Audience Restriction, определяется в web.config, и содержит список URL, который может получать приложение.

Рис. 6.1. Федеративная аутентификация в Windows Azure с использованием публичных провайдеров идентификации и доменного каталога Active Directory

Программная реализация проверки токенов безопасности на стороне клиента

Проверкой токенов на уровне приложения занимается набор классов Windows Identity Foundation (WIF), который позволяет создавать приложения, работающие на основе утверждений и обрабатывать соответствующим образом запросы WS-Trust, WS-Security и WS-Federation, основанный на первых двух.

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

Проверка токенов безопасности происходит с использованием специального WIF HTTP-модуля WSFederationAuthentificationModule (FAM). Модуль перехватывает пришедший в приложение POST-запрос, прослушивая событие AuthenticateRequest, и, перехватив запрос, начинает проверку токена – периода действия, списка слушателей и целостности токена (используя публичный ключ STS для проверки того, является ли доверенным STS и не был ли изменен в процессе передачи токен). Модуль разбирает утверждения в токене и использует HttpContext.User.Identity для того, чтобы представить IClaimsPrincipal, после чего выдает cookie для начала сессии. В течении сессии этот процесс не повторяется.

Процесс проверки и разбора токена безопасности на утверждения состоит из следующих этапов:

1. Определение обработчика для токена согласно его типу – SAML 1.1, SAML 2.0, и так далее.
2. Создание объекта типа ClaimsPrincipal с утверждениями.
3. При необходимости изменения утверждений вызов ClaimsAuthentificationManager.
4. Создание объекта SessionSecurityToken.
5. Создание сессии. В процессе утверждения в виде ClaimsPrincipal транслируются в коллекцию cookie FedAuth[x], при этом cookie разбиваются на части с целью не превышать определенных лимитов.
6. Перенаправление на URL, если он указан.

Рис. 6.2. Перенаправление на URL

После завершения всех процедур по проверке и обработке утверждений и токена и перенаправления токена на веб-приложение, запускается модуль SessionAuthentificationModule, который перехватывает коллекцию cookie и преобразовывает их в объект ClaimsPrincipal. Процесс состоит из нескольких этапов:

1. Проверка наличия cookie. Если коллекция обнаружена, она используется для создания SessionSecurityToken. При этом коллекция расшифровывается и распаковывается.
2. Проверка периода действия токена.
3. Создание объекта ClaimsPrincipal с утверждениями.
4. Определение контекста HttpContext.User как ClaimsPrincipal.