服务总线 - 从 Azure Active Directory 访问控制服务迁移到共享访问签名授权Service Bus - Migrate from Azure Active Directory Access Control Service to Shared Access Signature authorization

以前,服务总线应用程序有两种不同的授权模型可以选择。一种是服务总线直接提供的共享访问签名 (SAS) 令牌模型。另一种是联合模型,其中授权规则是由 Azure Active Directory 访问控制服务 (ACS) 在内部进行管理,从 ACS 获取的令牌会传递到服务总线,以授予对所需功能的访问权限。Service Bus applications have previously had a choice of using two different authorization models: the Shared Access Signature (SAS) token model provided directly by Service Bus, and a federated model where the management of authorization rules is managed inside by the Azure Active Directory Access Control Service (ACS), and tokens obtained from ACS are passed to Service Bus for authorizing access to the desired features.

ACS 授权模型一直以来都被首选模型 SAS 授权取代。目前,所有文档、指南和示例都只使用 SAS。The ACS authorization model has long been superseded by SAS authorization as the preferred model, and all documentation, guidance, and samples exclusively use SAS today. 此外,无法再新建与 ACS 配对的服务总线命名空间。Moreover, it is no longer possible to create new Service Bus namespaces that are paired with ACS.

SAS 的优势在于,不直接依赖另一服务,但可以授予客户端对 SAS 规则名称和规则密钥的访问权限,因此可以直接从客户端使用,而无需使用任何中介。SAS has the advantage in that it is not immediately dependent on another service, but can be used directly from a client without any intermediaries by giving the client access to the SAS rule name and rule key. SAS 还可以与下列方法轻松集成:客户端必须先使用另一服务通过授权检查,再颁发令牌。SAS can also be easily integrated with an approach in which a client has to first pass an authorization check with another service and then is issued a token. 后一种方法类似于 ACS 使用模式,不同之处在于允许根据很难在 ACS 中表达的应用程序专属条件颁发访问令牌。The latter approach is similar to the ACS usage pattern, but enables issuing access tokens based on application-specific conditions that are difficult to express in ACS.

对于所有依赖 ACS 的现有应用程序,要求客户将应用程序迁移为依赖 SAS。For all existing applications that are dependent on ACS, we urge customers to migrate their applications to rely on SAS instead.

迁移方案Migration scenarios

ACS 和服务总线是通过签名密钥 这一共用概念进行集成。ACS and Service Bus are integrated through the shared knowledge of a signing key. ACS 命名空间使用签名密钥对授权令牌进行签名;服务总线使用签名密钥验证令牌是否已由配对的 ACS 命名空间颁发。The signing key is used by an ACS namespace to sign authorization tokens, and it's used by Service Bus to verify that the token has been issued by the paired ACS namespace. ACS 命名空间包含服务标识和授权规则。The ACS namespace holds service identities and authorization rules. 授权规则定义了哪个服务标识或外部标识提供者颁发的哪个令牌拥有对部分服务总线命名空间图的何种访问权限(采用最长前缀匹配形式)。The authorization rules define which service identity or which token issued by an external identity provider gets which type of access to a part of the Service Bus namespace graph, in the form of a longest-prefix match.

例如,ACS 规则可能会向服务标识颁发“发送” 声明(路径前缀为 /)。也就是说,ACS 根据此规则颁发的令牌授权客户端,允许其向命名空间中的所有实体发送内容。For example, an ACS rule might grant the Send claim on the path prefix / to a service identity, which means that a token issued by ACS based on that rule grants the client rights to send to all entities in the namespace. 如果路径前缀为 /abc,标识只能向名为 abc 的实体或整理到此前缀下的实体发送内容。If the path prefix is /abc, the identity is restricted to sending to entities named abc or organized beneath that prefix. 为了能够理解此迁移指南,读者必须先熟悉这些概念。It is assumed that readers of this migration guidance are already familiar with these concepts.

迁移方案分为三大类:The migration scenarios fall into three broad categories:

  1. 未更改默认值Unchanged defaults. 一些客户使用 SharedSecretTokenProvider 对象,同时传递为 ACS 命名空间(与服务总线命名空间配对)自动生成的所有者 服务标识及其密钥,,未添加新规则。Some customers use a SharedSecretTokenProvider object, passing the automatically generated owner service identity and its secret key for the ACS namespace, paired with the Service Bus namespace, and do not add new rules.

  2. 包含简单规则的自定义服务标识Custom service identities with simple rules. 一些客户添加新的服务标识,并授予每个新服务标识对一个特定实体的“发送” 、“侦听” 和“管理” 权限。Some customers add new service identities and grant each new service identity Send, Listen, and Manage permissions for one specific entity.

  3. 包含复杂规则的自定义服务标识Custom service identities with complex rules. 很少有客户使用复杂规则集。在这些集中,外部颁发的令牌映射到中继上的权限,或在多个命名空间路径上通过多个规则为一个服务标识分配不同的权限。Very few customers have complex rule sets in which externally issued tokens are mapped to rights on Relay, or where a single service identity is assigned differentiated rights on several namespace paths through multiple rules.

有关复杂规则集迁移方面的帮助,可以联系 Azure 支持部门For assistance with the migration of complex rule sets, you can contact Azure support. 前两个方案启用的是直接迁移。The other two scenarios enable straightforward migration.

未更改默认值Unchanged defaults

如果应用程序未更改 ACS 默认值,可以将使用的所有 SharedSecretTokenProvider 替换为 SharedAccessSignatureTokenProvider 对象,并使用命名空间预配置的 RootManageSharedAccessKey ,而不是 ACS 所有者 帐户。If your application has not changed ACS defaults, you can replace all SharedSecretTokenProvider usage with a SharedAccessSignatureTokenProvider object, and use the namespace preconfigured RootManageSharedAccessKey instead of the ACS owner account. 请注意,即使使用 ACS 所有者 帐户,通常也都不建议使用这种配置(现在仍不建议),因为此帐户/规则提供对命名空间的完整管理权限,包括删除任何实体的权限。Note that even with the ACS owner account, this configuration was (and still is) not generally recommended, because this account/rule provides full management authority over the namespace, including permission to delete any entities.

简单规则Simple rules

如果应用程序使用包含简单规则的自定义服务标识,那么在创建 ACS 服务标识以提供对特定队列的访问控制时,迁移非常简单。If the application uses custom service identities with simple rules, the migration is straightforward in the case where an ACS service identity was created to provide access control on a specific queue. SaaS 式解决方案通常会出现这种情况。在此类解决方案中,每个队列被用作与租户网站或分支机构的桥梁,并且会为特定网站创建服务标识。This scenario is often the case in SaaS-style solutions where each queue is used as a bridge to a tenant site or branch office, and the service identity is created for that particular site. 在这种情况下,可以直接在队列上将各自的服务标识迁移到共享访问签名规则。In this case, the respective service identity can be migrated to a Shared Access Signature rule, directly on the queue. 服务标识名称可能会变成 SAS 规则名称,服务标识密钥可能会变成 SAS 规则密钥。The service identity name can become the SAS rule name and the service identity key can become the SAS rule key. 然后,将 SAS 规则的权限配置为相当于实体的各自适用 ACS 规则。The rights of the SAS rule are then configured equivalent to the respectively applicable ACS rule for the entity.

可以在与 ACS 联合的任何现有命名空间上就地额外配置新 SAS,随后使用 SharedAccessSignatureTokenProvider(而不是 SharedSecretTokenProvider)从 ACS 迁移。You can make this new and additional configuration of SAS in-place on any existing namespace that is federated with ACS, and the migration away from ACS is subsequently performed by using SharedAccessSignatureTokenProvider instead of SharedSecretTokenProvider. 命名空间不需要与 ACS 取消关联。The namespace does not need to be unlinked from ACS.

复杂规则Complex rules

SAS 规则并不是帐户,而是与权限相关联的命名签名密钥。SAS rules are not meant to be accounts, but are named signing keys associated with rights. 因此,在应用程序创建多个服务标识并向其授予访问多个实体或整个命名空间权限的情况下,仍需要令牌颁发中介。As such, scenarios in which the application creates many service identities and grants them access rights for several entities or the whole namespace still require a token-issuing intermediary. 若要获取此类中介的相关指南,可以联系支持部门You can obtain guidance for such an intermediary by contacting support.

后续步骤Next steps

若要详细了解服务总线身份验证,请参阅以下主题:To learn more about Service Bus authentication, see the following topics: