使用 Microsoft Entra ID 对应用程序进行身份验证和授权，使之能够访问 Azure 服务总线实体

Azure 服务总线支持使用 Microsoft Entra ID 授权对服务总线实体（队列、主题、订阅或筛选器）的请求。 使用 Microsoft Entra ID，可以使用 Azure 基于角色的访问控制（Azure RBAC）向安全主体授予权限。 安全主体可以是 Azure 资源的用户、组、应用程序服务主体或 托管标识。

将 Microsoft Entra ID 与 Azure 服务总线配合使用的主要优势在于，不再需要将凭据存储在代码中。 你可以从 Microsoft 标识平台请求 OAuth 2.0 访问令牌。 如果身份验证成功，Microsoft Entra ID 将访问令牌返回到应用程序。 然后，应用程序可以使用访问令牌来授权对服务总线资源的请求。

可以为服务总线命名空间禁用本地或共享访问签名（SAS）密钥身份验证，并仅允许Microsoft Entra 身份验证。 有关分步说明，请参阅禁用本地身份验证。

概述

当某个安全主体（用户、组或应用程序）尝试访问服务总线实体时，请求必须获得授权。 使用 Microsoft Entra ID 时，访问资源的过程分为两个步骤：

  1. 安全主体的标识经过身份验证，并返回 OAuth 2.0 令牌。 用于请求令牌的资源名称为 https://servicebus.azure.net。

  2. 令牌作为请求的一部分传递给服务总线服务，以授权访问指定资源。

身份验证步骤要求应用程序请求包含在运行时使用的 OAuth 2.0 访问令牌。 如果应用程序在 Azure 实体（例如 Azure 虚拟机、虚拟机规模集或函数应用）中运行，则可以使用托管标识访问资源。 若要了解如何对托管标识向服务总线服务发出的请求进行身份验证，请参阅 将托管标识与 Azure 服务总线配合使用。

授权步骤需要将一个或多个 Azure 角色分配给安全主体。 服务总线提供 Azure 角色，这些角色涵盖了针对服务总线资源的一组权限。 分配给安全主体的角色确定主体对服务总线资源拥有的权限。 若要详细了解如何将 Azure 角色分配到服务总线，请参阅 Azure 服务总线的 Azure 内置角色。

向服务总线发出请求的本机应用程序和 Web 应用程序也可以使用 Microsoft Entra ID 进行授权。 本文介绍如何请求访问令牌，并使用它针对服务总线资源进行请求授权。

适用于 Azure 服务总线的 Azure 内置角色

Microsoft Entra 通过 Azure RBAC 授权访问受保护的资源。 Azure 服务总线定义了一组 Azure 内置角色，它们包含用于访问服务总线实体的通用权限集。 还可以定义自定义角色来访问这些数据。

将 Azure 角色分配到 Microsoft Entra 安全主体后，Azure 会向该安全主体授予对这些资源的访问权限。 访问权限可以限定为订阅、资源组、服务总线命名空间或实体（队列、主题或订阅）级别。 Microsoft Entra 安全主体可以是用户、组、应用程序服务主体，也可以是 Azure 资源的托管标识。

对于 Azure 服务总线，Azure RBAC 模型通过 Azure 门户和 Azure 资源管理 API 帮助保护命名空间和所有相关资源的管理。 Azure 提供了以下内置角色，用于授予对服务总线命名空间的访问权限：

资源范围

向安全主体分配 Azure 角色之前，请确定安全主体应具有的访问权限的范围。 最佳做法指出，最好是授予尽可能小的范围。

以下列表描述了可将服务总线资源访问权限限定到哪些级别，从最小的范围开始：

  • 队列、主题或订阅：角色分配适用于特定的 服务总线 实体。 目前，Azure 门户不支持将用户、组或托管身份分配到主题订阅级别的 服务总线 Azure 角色。

  • 服务总线命名空间：角色分配覆盖命名空间中的服务总线的整个拓扑，并延伸到与之关联的队列或主题订阅。

  • 资源组：角色分配适用于资源组下的所有服务总线资源。

  • Azure 订阅：角色分配适用于订阅中所有资源组中的所有服务总线资源。

请记住，Azure 角色分配可能需要最多五分钟的时间进行传播。

有关如何定义内置角色的详细信息，请参阅 了解 Azure 角色定义。 若要了解如何创建 Azure 自定义角色，请参阅 Azure 自定义角色。

从应用程序进行身份验证

将 Microsoft Entra ID 与 Azure 服务总线配合使用的主要优势之一在于，不再需要在代码中存储凭据。 你可以从 Microsoft 标识平台请求 OAuth 2.0 访问令牌。

Microsoft Entra 对在应用程序中运行的安全主体（用户、组、服务主体或 Azure 资源的托管标识）进行身份验证。 如果身份验证成功，Microsoft Entra ID 会将访问令牌返回到应用程序。 然后，应用程序可以使用访问令牌来授权对服务总线的请求。

以下部分演示如何配置本机应用程序或 Web 应用程序以使用 Microsoft 标识平台 2.0 进行身份验证。 有关平台的详细信息，请参阅什么是Microsoft标识平台？

有关 OAuth 2.0 代码授予流的概述，请参阅 Microsoft标识平台和 OAuth 2.0 授权代码流。

在 Microsoft Entra 租户中注册应用程序

使用 Microsoft Entra ID 授权访问服务总线实体的第一步是，通过 Azure 门户在 Microsoft Entra 租户中注册客户端应用程序。 注册客户端应用程序时，会将有关应用程序的信息提供给 Active Directory。 Microsoft Entra ID 然后提供客户端 ID（也称为应用程序 ID），可用于将应用程序与 Microsoft Entra 运行时相关联。 若要了解有关客户端 ID 的详细信息，请参阅 Microsoft Entra ID 中的应用程序对象和服务主体对象。

若要使用 Microsoft Entra ID 注册应用程序，请按照 Microsoft Entra ID 中的应用程序注册步骤操作。

注意

如果将应用程序注册为本机应用程序，则可以为重定向 URI 指定任何有效的 URI。 对于本机应用程序，此值不必是实际 URL。 对于 Web 应用程序，重定向 URI 必须是有效的 URI，因为它指定了要向哪个 URL 提供令牌。

注册应用程序后， 应用程序（客户端）ID 和 目录（租户）ID 将显示在 “设置”下。 记下这些值。 需要使用它们来运行应用程序。

显示应用注册窗格中的应用程序 ID 和租户 ID 的屏幕截图。

创建客户端机密

请求令牌时，应用程序需要使用客户端机密来证明其身份。 若要添加客户端密码，请执行以下步骤：

  1. 如果您尚未在页面上，请在 Azure 门户中转到您的应用注册。

  2. 在左侧菜单中，选择 “证书和机密”。

  3. 在“客户端机密”下，选择“新建客户端机密”以创建新的机密。

    显示用于在证书和机密的窗格中创建客户端机密的按钮的屏幕截图。

  4. 提供机密的说明，选择过期间隔，然后选择“ 添加”。

    显示用于添加客户端机密的窗格的屏幕截图。

  5. 请立即将新密钥值复制到安全位置。 完整值仅显示一次。

    显示客户端机密的区域以及用于复制机密的按钮的屏幕截图。

添加服务总线 API 的权限

如果应用程序是控制台应用程序，则必须注册本机应用程序，并将 API 权限 Microsoft.ServiceBus 添加到所需权限集。

本机应用程序在 Microsoft Entra ID 中还需要一个用作标识符的 重定向 URI。 URI 不需要是网络目标。 对于此示例请使用 https://servicebus.microsoft.com，因为示例代码已使用了该 URI。

通过 Azure 门户分配 Azure 角色

在所需范围（实体、服务总线命名空间、资源组或 Azure 订阅）将其中一个 服务总线角色 分配给应用程序的服务主体。 有关详细步骤，请参阅使用 Azure 门户分配 Azure 角色。

定义角色及其范围后，可以使用 GitHub 上的示例测试此行为。

服务总线客户端的身份验证

注册应用程序并向其授予在 Azure 服务总线中发送/接收数据的权限后，可以使用客户端机密凭据对客户端进行身份验证。 通过此身份验证，可以针对 Azure 服务总线发出请求。

若要了解支持获取令牌的方案列表，请参阅“方案”部分，位于适用于 .NET 的 Microsoft 身份验证库 (MSAL) GitHub 存储库。

通过使用最新的 Azure.Messaging.ServiceBus 库，可以使用 Azure.Identity 库中定义的 ClientSecretCredential 对 ServiceBusClient 进行身份验证。

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

如果使用较旧的 .NET 包，请参阅 GitHub 上的服务总线的 Azure RBAC 示例。

相关内容

  • Last updated on