Проверка подлинности и авторизация приложения с помощью идентификатора Microsoft Entra для доступа к сущностям Служебная шина Azure

  • Статья

Служебная шина Azure поддерживает использование идентификатора Microsoft Entra для авторизации запросов к сущностям служебная шина (очереди, разделы, подписки или фильтры). С помощью идентификатора Microsoft Entra можно использовать управление доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности, который может быть пользователем, группой, субъектом-службой приложений или управляемым удостоверением для ресурсов Azure. Ключевым преимуществом использования идентификатора Microsoft Entra с Служебная шина Azure является то, что вам больше не нужно хранить учетные данные в коде. Вместо этого можно запросить маркер доступа 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, оно может использовать управляемое удостоверение для доступа к ресурсам. Сведения о проверке подлинности запросов, сделанных управляемым удостоверением в службе служебная шина, см. в статье "Проверка подлинности доступа к ресурсам Служебная шина Azure с помощью идентификатора Microsoft Entra и управляемых удостоверений для ресурсов Azure".

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

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

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

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

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

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

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

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

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

  • Очередь, тема или подписка: назначение роли применяется к определенному объекту служебной шины. В настоящее время портал Azure не поддерживает назначение пользователей/групп/управляемых удостоверений ролям служебной шины Azure на уровне подписки.
  • Пространство имен служебной шины: назначение роли охватывает всю топологию служебной шины в пространстве имен и связанной с ней группе потребителей.
  • Группа ресурсов: назначение ролей применяется ко всем ресурсам служебной шины в группе ресурсов.
  • Подписка: назначение ролей применяется ко всем ресурсам служебной шины во всех группах ресурсов в подписке.

Примечание.

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

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

Аутентификация из приложения

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

В следующих разделах показано, как настроить собственное приложение или веб-приложение для аутентификации с помощью Платформы удостоверений Майкрософт 2.0. Дополнительные сведения о платформе удостоверений Майкрософт 2.0 см. в разделе Обзор Платформы удостоверений Майкрософт (v2.0).

Общие сведения о потоке предоставления кода OAuth 2.0 см. в разделе "Авторизация доступа к веб-приложениям Microsoft Entra" с помощью потока предоставления кода OAuth 2.0.

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

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

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

Примечание.

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

После регистрации приложения вы увидите идентификатор приложения (клиента) и идентификатор каталога (клиента) в Параметры:

Внимание

Обратите внимание на TenantId и ApplicationId. Эти значения понадобятся вам для запуска приложения.

Screenshot showing the App registration page showing the Application ID and Tenant ID.

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

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

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

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

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

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

    Screenshot showing the Certificates and secrets page with New client secret button selected.

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

    Screenshot showing the Add a client secret page.

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

    Screenshot showing the Client secrets section with the secret you added.

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

Если ваше приложение является консольным, вы должны зарегистрировать собственное приложение и добавить разрешения API для Microsoft.ServiceBus в набор требуемых разрешений. Собственные приложения также нуждаются в URI перенаправления в идентификаторе Microsoft Entra, который служит идентификатором. Универсальный код ресурса (URI) не должен быть назначением сети. В этом примере используйте https://servicebus.microsoft.com, так как в образце кода уже используется этот URI.

Назначение ролей 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, ознакомьтесь с примерами RoleBasedAccessControl в репозитории примеров служебной шины Azure.

Следующие шаги

Дополнительную информацию об обмене сообщениями через служебную шину см. в следующих разделах.