Проверка подлинности и авторизация приложения с помощью идентификатора 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 доступ к ресурсу является двухэтапным процессом.
- Сначала проверяется подлинность субъекта безопасности и возвращается токен OAuth 2.0. Имя ресурса для запроса токена —
https://servicebus.azure.net. - Затем маркер передается как часть запроса к службе служебной шины для авторизации доступа к указанному ресурсу.
Для этапа аутентификации требуется, чтобы запрос от приложения содержал маркер доступа 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 на уровне подписки раздела.
служебная шина пространстве имен: назначение ролей охватывает всю топологию служебная шина в пространстве имен, а также в подписку на очередь или раздел, связанную с ней.
Группа ресурсов: назначение ролей применяется ко всем ресурсам служебной шины в группе ресурсов.
Подписка 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. Эти значения понадобятся вам для запуска приложения.
Дополнительные сведения о регистрации приложения с помощью идентификатора Microsoft Entra см. в разделе "Интеграция приложений с идентификатором Microsoft Entra".
Создание секрета клиента
Приложению требуется секрет клиента для подтверждения своей личности при запросе токена. Чтобы добавить секрет клиента, выполните следующие действия.
Перейдите к регистрации своего приложения на портале Azure, если вы еще не на этой странице.
В меню слева выберите Сертификаты и секреты.
В разделе Секреты клиента выберите Новый секрет клиента, чтобы создать новый секрет.
Введите описание секрета и выберите желаемый интервал истечения срока действия, а затем нажмите Добавить.
Немедленно скопируйте значение нового секрета в безопасное место. Значение заполнения отображается вам только один раз.
Разрешения для API служебной шины
Если ваше приложение является консольным, вы должны зарегистрировать собственное приложение и добавить разрешения API для Microsoft.ServiceBus в набор требуемых разрешений. Собственные приложения также нуждаются в URI перенаправления в идентификаторе Microsoft Entra, который служит идентификатором. Универсальный код ресурса (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, ознакомьтесь с примерами RoleBasedAccessControl в репозитории примеров служебной шины Azure.
Следующие шаги
- Дополнительные сведения о Azure RBAC см. в статье Что такое управление доступом на основе ролей (Azure RBAC)?
- Сведения о назначении ролей Azure и управлении ими с помощью Azure PowerShell, Azure CLI или REST API см. в следующих статьях:
Дополнительную информацию об обмене сообщениями через служебную шину см. в следующих разделах.