Экспорт (0) Печать
Развернуть все

Проверка подлинности и авторизация в Service Bus с помощью Access Control Service

Windows Azure Service Bus поддерживает использование Windows Azure Active Directory Access Control (также известна как Access Control Service или ACS) для авторизации операций Service Bus.

Windows Azure Active Directory Access Control (также известна как Access Control Service или ACS)

ACS занимается проверкой подлинности, т. е. проверяет удостоверение вызывающего. У ACS есть два способа для этого. Удостоверение устанавливается на основе списка удостоверений (или учетных записей) служб в пространстве имен с помощью классической схемы имени пользователя и пароля или эта операция делегируется внешнему поставщику удостоверений, такому как службы федерации Active Directory (ADFS), Windows Live ID, Facebook, Google ID, Yahoo ID или OpenID.

После определения удостоверения ACS получает ряд заявок о нем. Эти заявки представляют информацию о пользователе (или учетной записи), они подписаны поставщиком удостоверений, выдавшим заявки, с помощь цифровой подписи, что дает ACS гарантии того, что заявки корректны или по крайней мере соответствуют правилам их издателя. Другими словами, набор утверждений, указывающий на то, что представленное удостоверение относится к «Биллу Гейтсу, председателю, корпорация Майкрософт», больше достоин доверия, если он был издан шлюзом Microsoft ADFS, а не сторонней организацией. Заявки, которые согласованы для всех поставщиков удостоверений и удостоверений встроенной службы ACS, являются заявками поставщика (идентифицирующие самого поставщика), а заявка "nameidentifier", связанная с поставщиком представляющая уникальный идентификатор для указанного удостоверения.

Во-вторых, ACS выполняет авторизацию, позволяя сопоставлять заявки, выданные поставщиками удостоверений, с заявками, которые принимает проверяющая сторона. Такой проверяющей стороной является Service Bus, использующая ACS для проверки подлинности и авторизации. Сопоставление заявок необходимо для двух целей: во-первых, для нормализации утверждений на нескольких различных «жаргонах» в один набор утверждений, понятный службе, а во-вторых, сопоставление действует как набор правил авторизации. Если заданное удостоверение не сопоставляется с набором утверждений, понятных службе, то у удостоверения нет доступа к службе.

Проверка подлинности и авторизация всегда затрагивают клиента, а клиент — это единственный компонент, который должен быть виден по сети для всех сторон. Например, можно использовать службу ADFS, которая недоступна за пределами корпоративного брандмауэра вместе с ACS, так как ACS и ADFS никогда не взаимодействуют друг с другом напрямую. Когда клиенту требуется выполнить операцию с защищенным ресурсом, например отправить сообщение в очередь Service Bus, необходимо получить доказательство того, что у клиента есть для этого полномочия. Это доказательство получается от ACS в форме "маркера". Маркер — это просто контейнер для набора заявок, который подписывается издателем. Если служба ACS настроена для определения удостоверения с помощью внешнего поставщика удостоверений, такого как ADFS, используется по крайней мере два маркера. Первый маркер передает поставщик удостоверений, например ADFS, предоставляя одно из доказательств личности пользователя в качестве входных данных. Этот маркер затем передается службе ACS, которая оценивает его, выполняет правила и выдает маркер для проверяющей стороны.

Service Bus и ACS

Между Service Bus и ACS существует специальная связь, при этом каждый пространство имен службы службы Service Bus связан с соответствующим пространство имен службы службы ACS с таким же именем, к которому добавлен суффикс "–sb". Эта связь используется из-за того, как Service Bus и ACS управляют отношением взаимного доверия и связанными криптографическими секретами.

Service Bus может образовывать федерацию с ACS версии 1 и ACS версии 2. Все пространство имен службы, созданные до выпуска Service Bus в сентябре 2011 г., образуют федерацию с ACS версии 1, а все пространство имен службы, созданные после обновления, образуют федерацию с ACS версии 2. В этом разделе описывается только ACS версии 2, последний выпуск службы ACS.

В  пространство имен службы ACS с суффиксом "-sb", который можно просмотреть на портале Windows Azure, выбрав пространство имен службы Service Bus и щелкнув значок ACS на ленте, расположено определение проверяющей стороны "ServiceBus" после раздела "Приложения проверяющей стороны". Определение проверяющей стороны содержит сопоставление значения "Область" с корнем соответствующего пространство имен службы Service Bus (по схеме "http") и задает тип маркера "SWT" и срок действия маркеров, равный 1200 секундам. Кроме того, ключами подписи нельзя управлять через портал или API, как и получать доступ к ним.

С определением проверяющей стороны "ServiceBus" связан элемент "Группа правил по умолчанию для Service Bus", который содержит базовое сопоставление, позволяющее владельцу пространство имен службы работать с пространство имен службы как суперпользователь. Эта группа правил содержит по умолчанию три простых правила, сопоставляющих входную заявку "nameidentifier" для удостоверения службы "владелец" с тремя заявками разрешений, понятными для Service Bus: "Отправка" для всех операций отправки,"Прослушивание" для открытия прослушивателей и получения сообщений и "Управление" для просмотра состояния клиента Service Bus и управления им. Service Bus пропускает все остальные заявки в выданных маркерах. Удостоверение службы "владелец" — это обычное удостоверение в пространство имен службы службы ACS. Можно и рекомендуется создать дополнительные удостоверения. Кроме того, использование удостоверения «владелец» должно быть ограничено только для выполнения административных задач.

Определения проверяющей стороны и область действия

Когда клиент запрашивает маркер авторизации для отправки сообщения в очередь, например, по адресу https://tenant.servicebus.windows.net/my/test, запрос маркера будет содержать нормализованную форму конечного адреса в качестве конечной области. При нормализации просто используется общая схема универсальных кодов ресурсов (URI) для всех протоколов. Поэтому запрос маркера для взаимодействия с сущностью Service Bus по адресу https://tenant.servicebus.windows.net/my/test или sb://tenant.servicebus.windows.net/my/test всегда осуществляется с использованием URI области и схемы "http" (http://tenant.servicebus.windows.net/foo/bar). Следовательно, во всех определениях проверяющей стороны также должен использоваться HTTP-адрес нормализованной схемы универсальных кодов ресурсов (URI) для универсального кода ресурса (URI) области определения.

Когда в ACS поступает запрос, ACS сопоставляет URI области с определениями проверяющей стороны с помощью "самого длительного совпадения префиксов", что означает, что выбирается и запускается проверяющая сторона, адрес области URI которой является самым длинным доступным префиксом адреса, для которого запрошен маркер, и связанные с ней определения правил. Определение проверяющей стороны "ServiceBus" по умолчанию действует для всего пространство имен службы службы Service Bus, т. е. URI области, соответствующий корневому адресу пространство имен службы Service Bus, является префиксом для всех возможных адресов в пространство имен службы службы Service Bus. Например, определения правил в определении проверяющей стороны предоставляют полный доступ ко всему пространство имен службы службы Service Bus.

Способ создания набора правил авторизации с определенной областью действия для очереди, например, по адресу https://tenant.servicebus.windows.net/my/test заключается в создании нового определения проверяющей стороны с указанием адреса очереди или префикса этого адреса как URI области нового определения с помощью портала ACS ил API управления ACS. Для портала необходимо выполнить следующие действия.

  • На странице Приложения проверяющей стороны нажмите кнопку Добавить.

  • Введите отображаемое имя, например MyTest.

  • Введите http://tenant.servicebus.windows.net/MyTest в качестве универсального кода ресурса (URI) области действия.

  • Выберите SWT в качестве формата маркера.

  • Задайте для параметра Политика шифрования значение "Нет".

  • Задайте для параметра Срок действия маркера значение 1200 секунд.

  • Выберите Сохранить.

В результате вы получите эксклюзивное определение проверяющей стороны для этого адреса. Так как его URI области является суффиксом встроенного определения проверяющей стороны "ServiceBus", определение автоматически наследует правильные ключи для подписи, чтобы служба Service Bus доверял маркерам, выданным на основе нового определения. Но так как правил для нового определения проверяющей стороны пока нет, никто не сможет получить доступ к очереди, даже «владелец», так как не существует неявного наследования правил между определения проверяющей стороны, если они формируют иерархию.

После создания нового определения в разделе "Группы правил" портала ACS для параметра <displayname> отображается "Группа правил по умолчанию". Эта новая группа по умолчанию пуста. Чтобы разрешить доступ к очереди, необходимо добавить в группу правила, что описывается в следующем разделе. Или же можно включить существующую группу правил для определения проверяющей стороны. Каждую группу правил можно рассматривать как отдельный список управления доступом, который можно включить в любом месте иерархии проверяющих сторон. Чтобы включить наследование наподобие файловой системы, например для наследования правил корня пространство имен службы Service Bus по умолчанию, соответствующую группу "Группа правил по умолчанию для ServiceBus" и любую другую группу правил можно включить в определении проверяющей стороны. Для этого необходимо установить нужный флажок в разделе "Группы правил" определения проверяющей стороны портала. В ситуациях, в которых требуется применить один набор правил доступа ко множеству ресурсов, например одинаковые правила для набора параллельных ресурсов, таких как сдвоенные очереди по адресу http://tenant.servicebus.windows.net/my/test и http://tenant.servicebus.windows.net/my/zoo, для определения проверяющей стороны также можно задать область действия для общей ветвипространство имен службы, например http://tenant.servicebus.windows.net/my.

В других случаях управление доступом должно осуществляться по-разному для аспектов одной сущности Service Bus, например могут использоваться разные разрешения для различных подписок раздела. В этих случаях можно создать определение проверяющей стороны для определенного имени подписки, например http://tenant.servicebus.windows.net/my/test/subscriptions/sub1/, и включить в него правила, применимые только к определенной подписке.

Определение правил

Правила задаются в группах правил и обычно сопоставляют входную заявку с выходной. Все правила в группе формируют объединенный результат, поэтому если для указанного набора входных заявок есть три совпадающих правила, которые дают три разные выходные заявки, выданный маркер авторизации будет содержать все три заявки. В Service Bus существует три утверждения разрешения: «Отправка» для всех операций отправки, «Прослушивание» для открытия прослушивателей и получения сообщений и «Управление» для просмотра состояния клиента Service Bus или управления им. Если быть точным, «Отправка», «Прослушивание» и «Управление» являются разрешенными значениями типа утверждения «net.windows.servicebus.action». Для создания правила для Service Bus необходимо сопоставить входную заявку, например nameidentifier удостоверения службы, с требуемой заявкой разрешения. Чтобы предоставить удостоверению службы «contoso» разрешение на «отправку» в очередь, правило определения сопоставит удостоверение nameidentifier издателя со значением «contoso» и настраиваемое выходное удостоверение типа «net.windows.servicebus.action» со значением «Отправка». Для предоставления удостоверению службы всех трех заявок разрешений требуется три отдельных правила. Цель использования всего трех заявок разрешений — упростить определение правил.

Использование поставщиков маркеров

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

  • Общий секрет – позволяет получить маркер на основе удостоверения службы (и общий ключ, связанным с этим удостоверением), который был определен в пространстве имен Service Bus пространство имен службы "-sb" в ACS. Предварительно подготовленное удостоверение службы, сформированное при создании пространство имен службы, называется "владельцем", его общий секрет доступен на портале управления.

  • Simple Web Token (SWT) – позволяет получить маркер на основе ранее полученного маркера SWT, переданного ACS через поставщика маркеров. Маркер передается ACS в виде двоичного маркера с помощью запроса WS-Trust/WS-Federation RST/RSTR. Сведения о настройке поставщиков WS-Federation см. в документации по ACS.

  • SAML – позволяет получить маркер на основе ранее полученного маркера SAML , переданного ACS через поставщика маркеров. Маркер передается ACS с помощью запроса WS-Trust/WS-Federation RST/RSTR. Сведения о настройке поставщиков WS-Federation см. в документации по ACS.

Интерфейсы API Service Bus MessagingFactory, NamespaceManager и TransportClientEndpointBehavior принимают экземпляры TokenProvider. Поставщик маркеров вызывается, если требуются маркеры. К этим сценариям относятся ситуации, когда старое подключение должно получить новый маркер, если срок действия существующего маркера истек (по умолчанию он равен 1200 секунд). Для сценариев федерации, для которых требуется взаимодействие с пользователем, необходимо реализовать настраиваемый поставщик маркеров.

Например, чтобы позволить определенному пользователю Facebook отправлять сообщения в конкретную очередь, настраиваемый поставщик маркеров должен представить пользователю через ACS соответствующий интерфейс Facebook, чтобы установить удостоверение Facebook, перенаправить пользователя через ACS, чтобы обменять маркер Facebook на маркер ACS для Service Bus, а затем извлечь маркер ACS при перенаправлении запроса в локальное приложение. Сайт Service Bus Codeplex будет содержать растущую коллекцию примеров поставщиков маркеров, которые вы сможете настроить.

Добавления сообщества

Показ:
© 2014 Microsoft