Microsoft. Net Access Services. Идентификация на основе утверждений - Введение в облачные решения Microsoft

Как уже упоминалось в предыдущих лекция, .Net Access Control Services обеспечивает управление доступом к приложениям и сервисам и интеграцию с имеющимися у заказчика средствами авторизации. Поддерживаются стандартные механизмы аутентификации (к примеруWindows Live ID, Active Directory ). Основой сервиса Access Control является Windows Identity Foundation.

С. Net Access Control Services "облачные" и локальные приложения могут объединяться (в т. н. федерации) и позволяет использовать сервисы через firewall. Azure - приложение использует ту же систему безопасности каталогов, что и Active Directory, т. е. приложениебудет считать, что учетная запись пользователя управляется локально.

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

Основной целью данной лекции является знакомство с идентификацией на основе утверждений.

Идентификация на основе утверждения

Особенностью идентификации на основе утверждений является централизованная реализация сервисов аутентификации и авторизации вне локальной инфраструктуры, вне организации. Собственно, именно эти сервисы и предоставляет. Net Access Control.

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

Для обеспечения заявленного, приложения используют SAML (Security Assertion Markup Language). Утверждения передаются SAML - маркерами, каждый маркер несет часть информации о пользователе. Маркеры генерируются STS - программой.

STS (security token service), или сервис маркеров доступа - создает, подписывает и выдает маркеры доступа. STS принимает запросы на получение маркера (RST - request for token) и возвращает ответ (RSTR).

По сути, STS является элементом службы сертификации.

Однако, не все так просто, как кажется на первый взгляд. SAML маркер может не содержать утверждений, ожидаемых приложением и сервис, генерирующий маркером может не быть доверенным, с точки зрения приложения. Для решения этой проблемы в процесс идентификации вовлекается еще один STS - сервис, гарантирующий, что SAML - маркеры будут содержать всю требуемую информацию. При этом, .Net Access Control Services, использую федеративные механизмы, устанавливает доверенную связь между новым STS и сервисом, генерирующим маркеры.

Рис. 24.1 Показывает, как. Net Access Control Services обеспечивает преобразование утверждений и федеративную идентификацию.

На первом шаге клиент знакомится с политикой приложения, т. е. куда необходимо обращаться для аутентификации.

Генерируется запрос на получения SAML - маркера к STS службам, формирующим маркеры на основе ряда правил.

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

Рис. 24.1.

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

Пользователь посылает HTTP - запрос веб - приложению.

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

Служба сертификации управляет процессом аутентификации пользователя.

После аутентификации службой сертификации определяются необходимые утверждения и формируется SAML - маркер.

SAML - маркер включается в состав ответа с java - сценарием.

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

Используемые стандарты

Возможность взаимодействия всех этих элементов обеспечивается несколькими WS - стандартами (см п.№8 списка материалов для самостоятельного изучения).

WSDL извлекается с помощью WS-MetadataExchange или простого HTTP-запроса GET, и политика в WSDL структурирована соответственно спецификации WS-Policy.

STS службы сертификации предоставляют конечную точку, реализующую спецификацию WS-Trust, которая описывает процессы запроса и получения маркеров доступа.

SAML - словарь XML, который может использоваться для представления утверждений в форме, обеспечивающей возможность

Основной задачей. Net Service Bus является обеспечение коммуникаций между приложениями. Использование данных служб решает проблемы:

Передачи запросов через брандмауэр;

Определения конечных точек (endpoints) сервисов.

На сегодняшний день, наиболее популярным способом решения вышеобозначенных проблем являются веб - службы, базирующиеся наSOAP - протоколах. Клиентские приложения используют WSDL для генерации прокси - классов, для определения конечных точек и получения доступа к сервисам через firewall.

Вторым способом решения данных проблем является Windows Communication Foundation (WCF), использующий основанные веб-протоколы передачи данных, в т. ч. SOAP.

Предприятия, как правило, используют два подхода для решения данных проблем. Первый заключается в том, чтобы выборочно позволять приложениям открывать входящие порты на локальных и сетевых брандмауэрах. Второй - заключается в использовании промежуточных служб, находящихся между брандмауэрами и клиентскими приложениями, и являющихся, по сути, "мостом"", обеспечивающим обмен сообщениями.

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

Рассмотрим более подробно. Net Service Bus, чтобы понять, как данный сервис справляется с обеспечением эффективного обмена сообщениями.

Концепция. Net Service Bus

Первоначально для того, чтобы воспользоваться возможностями. Net Service Bus, приложения должны зарегистрироваться в соответствующем реестре. Когда приложение обращается к службе, находящейся за брандмауэром, с помощью, Net Service Busопределяется конечная точка службы и с ней устанавливается связь., т. е. непосредственно сам сервис выполняется за брандмауэром, а соединение с ним обеспечивает Service Bus. Клиенты видят только IP адрес, предоставляемый Service Bus, а не IP, предоставляемый компанией. Данный подход использует возможности. Net Access Control для обеспечения безопасности доступа.

Фактически, приложение использующее. Net Service Bus, реализует WCF функционал, но это не является обязательным. Приложение, обращающееся к сервисам за брандмауэром также может сформировать SOAP или REST - запрос.

Шаблон Enterprise Service Bus (ESB)

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

(источник -книга

Рис. 25.1. (Источник - книга " Introducing Windows Azure" Henry Li)

Шаблон ESB требует:

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

Механизма присваивания имен сервисам

Общей среды обмена сообщениями

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

К продуктам и технологиям реализации ESB можно отнести:

Active Directory

UDDI

BizTalk Server

MSMQ

WCF

Сервисная шина Интернета (Internet Service Bus - ISB)

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

ISB сделала бы возможным интегрировать вашу локальную ESB с вашими сервисами, выполняющимися в "облаке", с различными сервисами сторонних производителей, RIA и веб - приложениями.

Проблемы реализации двусторонней Интернет связи:

Нехватка IPv4-адресов;

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

Тем не менее на сегодняшний день можно говорить о наличии двунаправленных приложений, таких как:

Сервисы мгновенного обмена сообщениями (ICQ, MSN)

Сетевые игры

Приложения совместного использования файлов (torrent - клиенты)

Обмен сообщениями

Центральной частью. Net Services Bus является сервис ретрансляции, обеспечивающий возможность обмена сообщениями.

Сервис ретрансляции поддерживает:

Однонаправленный обмен сообщениями;

Синхронный обмен сообщениями;

Обмен сообщениями между равноправными участниками сети.

В этом случае вашим сервисам больше нет необходимости создавать локальных слушателей транспортного уровня; они полностью полагаются на сервис ретрансляции в вопросах обработки указанных транспортных аспектов связи. Сервис ретрансляции просто пересылает входящие сообщения на ваш локальный сервис.

Похожие статьи




Microsoft. Net Access Services. Идентификация на основе утверждений - Введение в облачные решения Microsoft

Предыдущая | Следующая