Сервис 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, разберём пример с уже настроенной инфраструктурой. В инфраструктуре установлены: домен уровня 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.0wtrealm=https%3a%2f%2ftechdaysdemo.cloudapp.net%2fwctx=rm%3d0%26id%3dpassive%26ru%3d%252fwct=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 для начала сессии. В течении сессии этот процесс не повторяется.
Процесс проверки и разбора токена безопасности на утверждения состоит из следующих этапов:
(рис 6.2) Перенаправление на URL
После завершения всех процедур по проверке и обработке утверждений и токена и перенаправления токена на веб-приложение, запускается модуль SessionAuthentificationModule, который перехватывает коллекцию cookie и преобразовывает их в объект ClaimsPrincipal. Процесс состоит из нескольких этапов:
SessionSecurityToken. При этом коллекция расшифровывается и распаковывается.ClaimsPrincipal с утверждениями.HttpContext.User как ClaimsPrincipal.В модели утверждений несколько пользователей или каких-либо объектов, обладающих утверждениями, могут быть объединены в единую сущность. Интерфейс IClaimsPrincipalInterface определяет данные и поведение личностей одного аутентифицированного объекта в рамках текущего контекста выполнения.
IClaimsPrincipal предоставляет метод IsInRole, возвращающий булевый тип в зависимости от того, есть ли в утверждениях объекта утверждение типа Role и является ли значение этого утверждения равным чему-то (например, Domain Admins в контексте Windows-домена). Также интерфейс предоставляет коллекцию личностей, каждая из которых реализует IClaimsIdentity. В общем случае в контексте выполнения находится один издатель и один токен, полученный от него, и коллекция Identity содержит только один элемент.
Интерфейс ClaimsIdentity определяет базовую функциональность объекта ClaimsIdentity и рекомендуется для использования и обеспечения доступа к методам и свойствам ClaimsIdentity вместо использования непосредственно ClaimsIdentity. Все объекты типа ClaimsIdentity реализуют интерфейс IClaimsIdentity, который расширяет стандартный IIdentity, оставляя при этом базовую функциональность IIdentity. IClaimsIdentity содержит коллекцию Claims – утверждений, привязанных к личности (например, имя или e-mail).
– тип, описывающий значение имени) и Claim.ValueType (и Claim.Value), содержащие тип значения и значение соответственно.
ClaimsPrincipal предоставляет статическое свойство Current, которое является IClaimsPrincipal, ассоциированным с текущим контекстом выполнения.
Одним из главных преимуществ аутентификации на основе утверждений является возможность децентрализации – вместо того, чтобы возлагать на 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 состоит из следующих компонентов:
Адреса конечных точек для 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.
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 может в процессе произвести некоторые преобразования утверждений, в том числе, например, добавив некоторые сведения о принадлежности пользователя к определенной группе.
Центральное место в 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 сервер (серверы) либо другие провайдеры идентификации.
Летом 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, обеспечивают еще один слой безопасности, которым может воспользоваться разработчик для предоставления опций пользователю.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.