Аутентификация и авторизация приложения с помощью Microsoft Entra ID для доступа к сущностям Azure Service Bus

Служебная шина Azure поддерживает использование Microsoft Entra ID для авторизации запросов к сущностям служебной шины, таким как очереди, топики, подписки или фильтры. С помощью идентификатора Microsoft Entra можно использовать управление доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности. Субъект безопасности может быть пользователем, группой, принципалом службы приложений или управляемым удостоверением для ресурсов Azure.

Ключевым преимуществом использования Microsoft Entra ID с Azure Service Bus является то, что вам больше не нужно хранить учетные данные в коде. Вместо этого можно запросить маркер доступа OAuth 2.0 из платформы удостоверений Майкрософт. Если проверка подлинности выполнена успешно, идентификатор Microsoft Entra возвращает маркер доступа приложению. Затем приложение может использовать маркер доступа для авторизации запросов к ресурсам служебной шины.

Вы можете отключить проверку подлинности ключа локальной или общей подписи доступа (SAS) для пространства имен служебной шины и разрешить только проверку подлинности Microsoft Entra. Пошаговые инструкции см. в разделе Отключение локальной проверки подлинности.

Обзор

Когда участник безопасности (пользователь, группа или приложение) пытается получить доступ к объекту служебной шины, запрос должен быть авторизован. С идентификатором Microsoft Entra доступ к ресурсу является двухэтапным процессом:

  1. Удостоверение субъекта безопасности проверяется, и возвращается токен OAuth 2.0. Имя ресурса для запроса токена — https://servicebus.azure.net.
  2. Маркер передается в рамках запроса в службу служебной шины для авторизации доступа к указанному ресурсу.

Для этапа аутентификации требуется, чтобы запрос от приложения содержал токен доступа OAuth 2.0 во время выполнения. Если приложение выполняется в сущности Azure, такой как виртуальная машина Azure, масштабируемый набор виртуальных машин или приложение-функция, оно может использовать управляемое удостоверение для доступа к ресурсам. Чтобы узнать, как выполнять проверку подлинности запросов, инициируемых управляемым удостоверением для службы Azure Service Bus, см. Использование управляемых удостоверений с Azure Service Bus.

Шаг авторизации требует назначения одной или нескольких ролей Azure субъекту безопасности. Служба Service Bus предоставляет роли Azure, охватывающие наборы разрешений для ресурсов Service Bus. Роли, назначенные субъекту безопасности, определяют разрешения, которые субъект имеет на ресурсы Service Bus. Дополнительные сведения о назначении ролей Azure служебной шине см. в статье о встроенных ролях Azure для служебной шины Azure.

Собственные и веб-приложения, которые выполняют запросы к Service Bus, также могут авторизоваться с помощью Microsoft Entra ID. В этой статье показано, как запросить маркер доступа и использовать его для авторизации запросов к ресурсам служебной шины.

Встроенные роли Azure для служебной шины Azure

Microsoft Entra разрешает доступ к защищенным ресурсам через Azure RBAC. Служба шины Azure определяет набор встроенных ролей Azure, охватывающих общие наборы разрешений, используемых для доступа к сущностям Службы шины. Вы также можете определить настраиваемые роли для доступа к данным.

Когда роль Azure назначается субъекту безопасности Microsoft Entra, Azure предоставляет доступ к этим ресурсам для этого субъекта безопасности. Доступ можно ограничить на уровне подписки, группы ресурсов, пространства имен служебной шины или сущности (очередь, раздел или подписку). Субъект безопасности Microsoft Entra может быть пользователем, группой, служебным принципалом приложений или управляемым удостоверением для ресурсов Azure.

Для служебной шины Azure модель Azure RBAC помогает защитить управление пространствами имен и всеми связанными ресурсами с помощью портала Azure и API управления ресурсами Azure. Azure предоставляет следующие встроенные роли для авторизации доступа к пространству имен служебная шина:

Область ресурса

Прежде чем назначить роль Azure субъекту безопасности, определите для него область доступа. Лучшей практикой считается предоставление максимально узких полномочий.

В следующем списке описаны уровни, на которых вы можете определить доступ к ресурсам Service Bus, начиная с самой узкой области:

  • Очередь, тема или подписка: назначение ролей применяется к определенной сущности Service Bus. В настоящее время портал Azure не поддерживает назначение пользователей, групп или управляемых удостоверений к ролям Azure Service Bus на уровне подписки на топик.

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

  • Ресурсная группа: назначение ролей применяется ко всем ресурсам Service Bus в ресурсной группе.

  • Подписка Azure: назначение ролей применяется ко всем ресурсам служебной шины во всех группах ресурсов в подписке.

Помните, что для распространения назначений ролей Azure может потребоваться до пяти минут.

Дополнительные сведения о том, как определяются встроенные роли, см. в статье "Общие сведения о определениях ролей Azure". Дополнительные сведения о создании настраиваемых ролей Azure см. в разделе Настраиваемые роли Azure.

Проверка подлинности из приложения

Ключевым преимуществом использования Microsoft Entra ID с Service Bus является то, что ваши учетные данные больше не нужно хранить в коде. Вместо этого можно запросить маркер доступа OAuth 2.0 из платформы удостоверений Майкрософт.

Microsoft Entra выполняет проверку подлинности субъекта безопасности (пользователя, группы, субъекта-службы или управляемого удостоверения для ресурсов Azure), работающего с приложением. Если проверка подлинности выполнена успешно, идентификатор Microsoft Entra возвращает маркер доступа приложению. Затем приложение может использовать маркер доступа для авторизации запросов к служебной шине.

В следующих разделах показано, как настроить собственное приложение или веб-приложение для проверки подлинности с помощью платформы удостоверений Майкрософт 2.0. Дополнительные сведения о платформе см. в статье "Что такое платформа удостоверений Майкрософт?".

Общие сведения о потоке предоставления кода OAuth 2.0 см. на платформе удостоверений Майкрософт и потоке кода авторизации OAuth 2.0.

Регистрация приложения в клиенте Microsoft Entra

Первым шагом в использовании Microsoft Entra ID для авторизации сущностей служебной шины является регистрация клиентского приложения с клиентом Microsoft Entra через портале Azure. При регистрации клиентского приложения вы предоставляете сведения о приложении в Active Directory. Затем идентификатор Microsoft Entra предоставляет идентификатор клиента (также называемый идентификатором приложения), который можно использовать для связывания приложения с средой выполнения Microsoft Entra. Дополнительные сведения об идентификаторе клиента см. в разделе Объекты приложения и службы-принципала в Microsoft Entra ID.

Чтобы зарегистрировать приложение с помощью идентификатора Microsoft Entra, выполните действия, описанные в разделе "Регистрация приложения в идентификаторе Microsoft Entra".

Примечание.

Если вы регистрируете приложение в качестве собственного приложения, можно указать любой допустимый URI для URI перенаправления. Для собственных приложений это значение не должно быть реальным URL-адресом. Для веб-приложений URI перенаправления должен быть допустимым URI, так как он указывает URL-адрес, на который предоставляются токены.

После регистрации приложения идентификатор приложения (клиента) и идентификатор каталога (клиента) появится в разделе "Параметры". Запишите эти значения. Им потребуется запустить приложение.

Снимок экрана: идентификатор приложения и идентификатор клиента в области регистрации приложений.

Создание секрета клиента

Приложению требуется секрет клиента для подтверждения своей личности при запросе токена. Чтобы добавить секрет клиента, выполните следующие действия.

  1. На портале Azure перейдите к регистрации приложения, если вы еще не на странице.

  2. В меню слева выберите сертификаты и секреты.

  3. В разделе Секреты клиента выберите Новый секрет клиента, чтобы создать новый секрет.

    Снимок экрана: кнопка создания секрета клиента в области сертификатов и секретов.

  4. Укажите описание секрета, выберите интервал истечения срока действия и нажмите кнопку "Добавить".

    Снимок экрана: панель добавления секрета клиента.

  5. Немедленно скопируйте значение нового секрета в безопасное место. Полное значение отображается только один раз.

    Снимок экрана: область секретов клиента, а также кнопка для копирования секрета.

Добавление разрешений для API служебной шины

Если ваше приложение является консольным приложением, необходимо зарегистрировать родное приложение и добавить разрешения API для Microsoft.ServiceBus в набор необходимых разрешений.

Собственные приложения также требуют URI перенаправления в Microsoft Entra ID, который служит идентификатором. URI не обязательно должен быть сетевым адресом. В этом примере используйте https://servicebus.microsoft.com, так как в образце кода уже используется этот URI.

Назначение ролей Azure с помощью портала Azure

Назначьте одну из ролей служебной шины основному сервису приложения в нужной области (сущности, пространстве имен служебной шины, группе ресурсов или подписке Azure). Подробные инструкции см. в статье Назначение ролей Azure с помощью портала Microsoft Azure.

После того как вы определите роль и её область применения, вы можете протестировать это поведение с помощью примера на GitHub.

Проверка подлинности клиента Службы шины

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

Список сценариев, для которых поддерживается получение маркеров, см. в разделе "Сценарии" библиотеки проверки подлинности Майкрософт (MSAL) для репозитория .NET GitHub.

Используя последнюю библиотеку Azure.Messaging.ServiceBus , вы можете пройти проверку подлинности ServiceBusClient с помощью ClientSecretCredential, которая определена в библиотеке Azure.Identity .

TokenCredential credential = new ClientSecretCredential("<tenant_id>", "<client_id>", "<client_secret>");
var client = new ServiceBusClient("<fully_qualified_namespace>", credential);

Если вы используете старые пакеты .NET, ознакомьтесь с примерами Azure RBAC для служебной шины на GitHub.

Связанный контент

  • Last updated on