从 Azure Active Directory 访问控制服务迁移到共享访问签名授权

以前,服务总线应用程序有两种不同的授权模型可以选择。一种是服务总线直接提供的共享访问签名 (SAS) 令牌模型。另一种是联合模型,其中授权规则是由 Azure Active Directory 访问控制服务 (ACS) 在内部进行管理,从 ACS 获取的令牌会传递到服务总线,以授予对所需功能的访问权限。

ACS 授权模型一直以来都被首选模型 SAS 授权取代。目前,所有文档、指南和示例都只使用 SAS。 此外,无法再新建与 ACS 配对的服务总线命名空间。

SAS 的优势在于,不直接依赖另一服务,但可以授予客户端对 SAS 规则名称和规则密钥的访问权限,因此可以直接从客户端使用,而无需使用任何中介。 SAS 还可以与下列方法轻松集成:客户端必须先使用另一服务通过授权检查,再颁发令牌。 后一种方法类似于 ACS 使用模式,不同之处在于允许根据很难在 ACS 中表达的应用程序专属条件颁发访问令牌。

对于所有依赖 ACS 的现有应用程序,要求客户将应用程序迁移为依赖 SAS。

迁移方案

ACS 和服务总线是通过签名密钥这一共用概念进行集成。 ACS 命名空间使用签名密钥对授权令牌进行签名;服务总线使用签名密钥验证令牌是否已由配对的 ACS 命名空间颁发。 ACS 命名空间包含服务标识和授权规则。 授权规则定义了哪个服务标识或外部标识提供者颁发的哪个令牌拥有对部分服务总线命名空间图的何种访问权限(采用最长前缀匹配形式)。

例如,ACS 规则可能会向服务标识颁发“发送”声明(路径前缀为 /)。也就是说,ACS 根据此规则颁发的令牌授权客户端,允许其向命名空间中的所有实体发送内容。 如果路径前缀为 /abc,标识只能向名为 abc 的实体或整理到此前缀下的实体发送内容。 为了能够理解此迁移指南,读者必须先熟悉这些概念。

迁移方案分为三大类:

  1. 未更改默认值: 一些客户使用 SharedSecretTokenProvider 对象,同时传递为 ACS 命名空间(与服务总线命名空间配对)自动生成的所有者服务标识及其密钥,,未添加新规则。

  2. 包含简单规则的自定义服务标识: 一些客户添加新的服务标识,并授予每个新服务标识对一个特定实体的“发送”、“侦听”和“管理”权限。

  3. 包含复杂规则的自定义服务标识。 很少有客户使用复杂规则集。在这些集中,外部颁发的令牌映射到中继上的权限,或在多个命名空间路径上通过多个规则为一个服务标识分配不同的权限。

有关复杂规则集迁移方面的帮助,可以联系 Azure 支持部门。 前两个方案启用的是直接迁移。

未更改默认值

如果应用程序未更改 ACS 默认值,可以将使用的所有 SharedSecretTokenProvider 替换为 SharedAccessSignatureTokenProvider 对象,并使用命名空间预配置的 RootManageSharedAccessKey,而不是 ACS 所有者帐户。 请注意,即使使用 ACS 所有者帐户,通常也都不建议使用这种配置(现在仍不建议),因为此帐户/规则提供对命名空间的完整管理权限,包括删除任何实体的权限。

简单规则

如果应用程序使用包含简单规则的自定义服务标识,那么在创建 ACS 服务标识以提供对特定队列的访问控制时,迁移非常简单。 SaaS 式解决方案通常会出现这种情况。在此类解决方案中,每个队列被用作与租户网站或分支机构的桥梁,并且会为特定网站创建服务标识。 在这种情况下,可以直接在队列上将各自的服务标识迁移到共享访问签名规则。 服务标识名称可能会变成 SAS 规则名称,服务标识密钥可能会变成 SAS 规则密钥。 然后,将 SAS 规则的权限配置为相当于实体的各自适用 ACS 规则。

可以在与 ACS 联合的任何现有命名空间上就地额外配置新 SAS,随后使用 SharedAccessSignatureTokenProvider(而不是 SharedSecretTokenProvider)从 ACS 迁移。 命名空间不需要与 ACS 取消关联。

复杂规则

SAS 规则并不是帐户,而是与权限相关联的命名签名密钥。 因此,在应用程序创建多个服务标识并向其授予访问多个实体或整个命名空间权限的情况下,仍需要令牌颁发中介。 若要获取此类中介的相关指南,可以联系支持部门

后续步骤

若要详细了解服务总线身份验证,请参阅以下主题: