使用 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，访问资源流程需要两步。
- 首先，验证安全主体的身份并返回 OAuth 2.0 令牌。 用于请求令牌的资源名称为
https://servicebus.chinacloudapi.cn。 - 接下来，将该令牌作为请求的一部分传递给服务总线服务，用于授权访问指定的资源。
身份验证步骤要求应用程序请求包含在运行时使用的 OAuth 2.0 访问令牌。 如果某个应用程序在 Azure 实体（例如 Azure VM、虚拟机规模集或 Azure 函数应用）中运行，那么，它就可以使用托管标识来访问这些资源。 若要了解如何对托管标识向服务总线服务发出的请求进行身份验证，请参阅对使用 Microsoft Entra ID 和 Azure 资源的托管标识访问 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 门户和 Azure 资源管理 API 对命名空间和所有相关资源的管理已使用 Azure RBAC 模型进行了保护。 Azure 提供了以下内置角色，用于授予对服务总线命名空间的访问权限：
- Azure 服务总线数据所有者：使用此角色可以授予对服务总线资源的完全访问权限。
- Azure 服务总线数据发送者：使用此角色可以为服务总线命名空间及其实体提供发送访问权限。
- Azure 服务总线数据接收者：使用此角色可以为服务总线命名空间及其实体提供接收访问权限。
资源范围
向安全主体分配 Azure 角色之前，请确定安全主体应具有的访问权限的范围。 最佳做法指出，最好是授予尽可能小的范围。
以下列表描述了可将服务总线资源访问权限限定到哪些级别，从最小的范围开始：
- 队列、主题或订阅：角色分配适用于特定的服务总线实体。 目前，Azure 门户不支持在主题订阅级别为服务总线 Azure 角色分配用户/组/托管标识。
- 服务总线命名空间：角色分配横跨命名空间中服务总线的整个拓扑，并延伸至与之关联的使用者组。
- 资源组：角色分配适用于资源组下的所有服务总线资源。
- Azure 订阅：角色分配适用于订阅的所有资源组中的所有服务总线资源。
注意
请记住，Azure 角色分配可能需要最多五分钟的时间进行传播。
有关如何定义内置角色的详细信息，请参阅了解角色定义。 若要了解如何创建 Azure 自定义角色，请参阅 Azure 自定义角色。
通过应用程序进行身份验证
将 Microsoft Entra ID 与 Azure 服务总线配合使用的主要优势之一在于，不再需要在代码中存储凭据。 可以从 Microsoft 标识平台请求 OAuth 2.0 访问令牌。 Microsoft Entra 对在应用程序中运行的安全主体（用户、组、服务主体或 Azure 资源的托管标识）进行身份验证。 如果身份验证成功，Microsoft Entra ID 会将访问令牌返回应用程序，应用程序可随之使用访问令牌对 Azure 服务总线请求授权。
以下部分介绍如何配置本机应用程序或 Web 应用程序，以便在 Microsoft 标识平台 2.0 中进行身份验证。 有关 Microsoft 标识平台 2.0 的详细信息，请参阅 Microsoft 标识平台 (v2.0) 概述。
有关 OAuth 2.0 代码授权流的概述，请参阅使用 OAuth 2.0 代码授权流来授权访问 Microsoft Entra Web 应用程序。
在 Microsoft Entra 租户中注册应用程序
使用 Microsoft Entra ID 授权访问服务总线实体的第一步是，通过 Azure 门户在 Microsoft Entra 租户中注册客户端应用程序。 注册客户端应用程序时，需要向 AD 提供关于应用程序的信息。 Microsoft Entra ID 随后会提供客户端 ID（也称为应用程序 ID）。在运行时，可以使用该 ID 将应用程序与 Microsoft Entra 关联。 若要了解有关客户端 ID 的详细信息，请参阅 Microsoft Entra ID 中的应用程序对象和服务主体对象。
按照快速入门：将应用程序注册到 Microsoft 标识平台中的步骤向 Microsoft Entra ID 注册应用程序。
注意
如果将应用程序注册为本机应用程序，可以为重定向 URI 指定任何有效的 URI。 对于本机应用程序，此值不一定要是实际的 URL。 对于 Web 应用程序，重定向 URI 必须是有效的 URI，因为它指定了要向哪个 URL 提供令牌。
注册应用程序后，你将在“设置”下看到“应用程序(客户端) ID”和“目录(租户) ID”：
重要
记下 TenantId 和 ApplicationId。 将需要这些值来运行应用程序。
有关向 Microsoft Entra ID 注册应用程序的详细信息，请参阅将应用程序与 Microsoft Entra ID 集成。
创建客户端机密
请求令牌时，应用程序需要使用客户端机密来证明其身份。 若要添加客户端机密，请执行以下步骤。
在 Azure 门户中导航到你的应用注册（如果尚未转到此页上）。
在左侧菜单上，选择“证书和机密”。
在“客户端机密”下，选择“新建客户端机密”以创建新的机密。
提供机密说明，并选择所需的过期时间间隔，然后选择“添加”。
请马上将新机密的值复制到安全位置。 填充值只会显示一次。
服务总线 API 的权限
如果应用程序是一个控制台应用程序，则必须注册一个本机应用程序并将 Microsoft.ServiceBus 的 API 权限添加到“必需的权限”集。 本机应用程序在 Microsoft Entra ID 中还需要有一个充当标识符的 redirect-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 包，请参阅 azure-service-bus 示例存储库中的 RoleBasedAccessControl 示例。
后续步骤
- 若要详细了解 Azure RBAC，请参阅什么是 Azure 基于角色的访问控制 (Azure RBAC)？
- 若要了解如何使用 Azure PowerShell、Azure CLI 或 REST API 分配和管理 Azure 角色分配，请参阅以下文章：
若要了解有关服务总线消息传送的详细信息，请参阅以下主题。