如何：从 Azure 访问控制服务迁移

Microsoft Azure 访问控制服务（ACS）是 Azure Active Directory（Azure AD）的一项服务，将于 2018 年 11 月 7 日停用。 目前使用访问控制的应用程序和服务必须完全迁移到不同的身份验证机制。 本文为当前的用户提供在你计划弃用访问控制功能时的建议。 如果当前不使用访问控制，则无需执行任何作。

概述

访问控制是一种云身份验证服务，提供一种简单的方式来对用户进行身份验证和授权，以便访问 Web 应用程序和服务。 它允许将身份验证和授权的许多功能从代码中考虑出来。 访问控制主要用于Microsoft .NET 客户端、ASP.NET Web 应用程序和 Windows Communication Foundation （WCF） Web 服务的开发人员和架构师。

访问控制的用例可以分为三个主要类别：

• 对某些 Microsoft 云服务进行认证，包括 Azure 服务总线和 Dynamics CRM。 客户端应用程序从访问控制获取令牌，以对这些服务进行身份验证以执行各种作。
• 将身份验证添加到 Web 应用程序（如自定义和预打包）（如 SharePoint）。 通过使用访问控制“被动”身份验证，Web 应用程序可以支持使用 Microsoft 帐户（以前是 Live ID）登录，以及 Google、Facebook、Yahoo、Azure AD 和 Active Directory 联合身份验证服务（AD FS）中的帐户登录。
• 使用访问控制颁发的令牌保护自定义 Web 服务。 通过使用“活动”身份验证，Web 服务可以确保它们仅允许访问使用访问控制进行身份验证的已知客户端。

以下各节将讨论上述每个用例及其建议的迁移策略。

访问控制具有以下组件：

• 一个安全令牌服务（STS），它接收身份验证请求，并在返回时颁发安全令牌。
• Azure 经典门户，可在其中创建、删除和启用和禁用访问控制命名空间。
• 一个单独的访问控制管理门户，可在其中自定义和配置访问控制命名空间。
• 管理服务，可用于自动执行门户的功能。
• 令牌转换规则引擎，您可以使用它定义复杂逻辑以操作访问控制颁发的令牌的输出格式。

若要使用这些组件，必须创建一个或多个访问控制命名空间。 命名空间是应用程序和服务与之通信的访问控制的专用实例。 命名空间与所有其他访问控制客户隔离。 其他访问控制客户使用自己的命名空间。 访问控制中的命名空间具有如下所示的专用 URL：

https://<mynamespace>.accesscontrol.windows.net

与 STS 和管理操作的所有通信都在此 URL 上完成。 将不同的路径用于不同的目的。 若要确定应用程序或服务是否使用访问控制，请监视 https://<namespace>.accesscontrol.windows.net 的任何流量。 访问此 URL 的任何流量都由访问控制处理，需要停止。

此例外情况是指发送到 https://accounts.accesscontrol.windows.net 的任何流量。 到此 URL 的流量已由其他服务处理， 不受 访问控制弃用的影响。

有关访问控制的详细信息，请参阅访问控制服务 2.0（已存档）。

了解哪些应用将受到影响

按照本部分中的步骤确定哪些应用将受到 ACS 停用的影响。

下载并安装 ACS PowerShell

1. 访问 PowerShell 库并下载 Acs.Namespaces。

2. 通过运行来安装模块

   Install-Module -Name Acs.Namespaces
   

3. 通过运行获取所有可能命令的列表

   Get-Command -Module Acs.Namespaces
   

   若要获取有关特定命令的帮助，请运行：

    Get-Help [Command-Name] -Full
   

   其中 [Command-Name] 是 ACS 命令的名称。

列出 ACS 命名空间

1. 使用 Connect-AcsAccount cmdlet 连接到 ACS。

   可能需要先运行 Set-ExecutionPolicy -ExecutionPolicy Bypass，并且成为这些订阅的管理员，然后才能执行命令。

2. 使用 Get-AcsSubscription cmdlet 列出可用的 Azure 订阅。

3. 使用 Get-AcsNamespace cmdlet 列出 ACS 命名空间。

检查哪些应用程序将受到影响

1. 使用上一步中的命名空间并转到 https://<namespace>.accesscontrol.windows.net

   例如，如果其中一个命名空间是 contoso-test，请转到 https://contoso-test.accesscontrol.windows.net

2. 在 “信任关系”下，选择 “信赖方应用程序 ”以查看受 ACS 停用影响的应用列表。

3. 对拥有的任何其他 ACS 命名空间重复步骤 1-2。

退休计划

自 2017 年 11 月起，所有访问控制组件都完全受支持并正常运行。 唯一的限制是 无法通过 Azure 经典门户创建新的访问控制命名空间。

下面是弃用访问控制组件的计划：

• 2017 年 11 月：Azure 经典门户中的 Azure AD 管理员体验 已停用。 此时，访问控制的命名空间管理在新的专用 URL 中可用： https://manage.windowsazure.com?restoreClassic=true 使用此 URL 可以查看现有命名空间、启用或禁用命名空间，以及删除命名空间（如果选择）。
• 2018 年 4 月 2 日：Azure 经典门户已完全停用，这意味着访问控制命名空间管理不再可通过任何 URL 使用。 此时，无法禁用或启用、删除或枚举访问控制命名空间。 但是，访问控制管理门户将完全正常运行，并且位于 https://<namespace>.accesscontrol.windows.net。 访问控制的所有其他组件继续正常运行。
• 2018 年 11 月 7 日：所有访问控制组件都会永久关闭。 这包括访问控制管理门户、管理服务、STS 和令牌转换规则引擎。 此时，发送到访问控制（位于） <namespace>.accesscontrol.windows.net的任何请求都失败。 在此之前，你应该已将所有现有应用和服务迁移到其他技术。

迁移策略

以下部分介绍了从访问控制迁移到其他Microsoft技术的高级建议。

Microsoft云服务的客户端

接受访问控制颁发的令牌的每个Microsoft云服务现在至少支持一种备用身份验证形式。 每个服务的正确身份验证机制各不相同。 建议参考每个服务的特定文档以获取官方指导。 为方便起见，此处提供了每组文档：

SharePoint 客户

SharePoint 2013、2016 和 SharePoint Online 客户长期以来一直将 ACS 用于云、本地和混合方案中的身份验证目的。 某些 SharePoint 功能和用例将受到 ACS 停用的影响，而另一些则不会。 下表总结了一些利用 ACS 的最常用 SharePoint 功能的迁移指南：

使用被动身份验证的 Web 应用程序

对于使用访问控制进行身份验证的 Web 应用程序，访问控制为 Web 应用程序开发人员和架构师提供以下特性和功能：

• 与 Windows Identity Foundation（WIF）的深度集成。
• 与 Google、Facebook、Yahoo、Azure Active Directory、AD FS 帐户以及 Microsoft 帐户集成。
• 支持以下身份验证协议：OAuth 2.0 草稿 13、WS 信任和 Web 服务联合身份验证（WS-Federation）。
• 支持以下令牌格式：JSON Web 令牌（JWT）、SAML 1.1、SAML 2.0 和简单 Web 令牌（SWT）。
• 集成到 WIF 中的家域发现体验，允许用户选择登录所用的帐户类型。 此体验由 Web 应用程序托管，可完全自定义。
• 令牌转换允许对从访问控制接收到的 Web 应用程序声明进行丰富的自定义，包括：
  • 从身份提供者传递声明。
  • 添加附加的自定义声明。
  • 简单的 if-then 逻辑，用于在特定条件下发出声明。

遗憾的是，没有一项服务提供所有这些等效功能。 应评估所需的访问控制功能，然后在使用 Microsoft Entra ID、 Azure Active Directory B2C（Azure AD B2C ）或其他云身份验证服务之间进行选择。

迁移到 Microsoft Entra ID

要考虑的路径是将应用和服务直接与 Microsoft Entra ID 集成。 Microsoft Entra ID 是Microsoft工作或学校帐户的基于云的标识提供者。 Microsoft Entra ID 是用于 Microsoft 365、Azure 等的标识提供者。 它提供与访问控制类似的联合身份验证功能，但不支持所有访问控制功能。

主要示例是与社交标识提供者（如 Facebook、Google 和 Yahoo）联合。 如果用户使用这些类型的凭据登录，Microsoft Entra ID 不是解决方案。

Microsoft Entra ID 也不一定支持与访问控制完全相同的身份验证协议。 例如，尽管访问控制和Microsoft Entra ID 都支持 OAuth，但每个实现之间存在细微的差异。 不同的实现要求在迁移过程中修改代码。

但是，Microsoft Entra ID 确实为访问控制客户提供了几个潜在优势。 它原生支持 Microsoft 在云端托管的工作或学校帐户，这些帐户通常由访问控制的客户使用。

Microsoft Entra 租户也可以通过 AD FS 联合到本地 Active Directory 的一个或多个实例。 这样，应用就可以对本地托管的基于云的用户和用户进行身份验证。 它还支持 WS-Federation 协议，这使得使用 WIF 与 Web 应用程序集成相对简单。

下表比较了与 Web 应用程序相关的访问控制功能，以及 Microsoft Entra ID 中提供的这些功能。

概括而言， 如果允许用户仅使用其Microsoft工作或学校帐户登录，Microsoft Entra ID 可能是迁移的最佳选择。

如果确定Microsoft Entra ID 是应用程序和服务的最佳迁移路径，则应了解将应用与 Microsoft Entra ID 集成的两种方法。

使用 WS-Federation 或 WIF 与 Microsoft Entra ID 集成时，建议遵循为非展示应用程序配置联合单点登录中所述的方法。 本文介绍如何为基于 SAML 的单一登录配置 Microsoft Entra ID，同时该配置也适用于 WS-Federation。 遵循此方法需要Microsoft Entra ID P1 或 P2 许可证。 此方法有两个优点：

• 你可以完全灵活地自定义 Microsoft Entra 令牌。 可以自定义由 Microsoft Entra ID 颁发的声明，以匹配访问控制颁发的声明。 这尤其包括用户 ID 或名称标识符声明。 若要在更改技术后继续为用户接收一致的用户 IDentifier，请确保Microsoft Entra ID 颁发的用户 ID 与访问控制颁发的 ID 匹配。
• 您可以配置一个专用于您应用程序的令牌签名证书，并设定您可以控制的有效期。

另一种方法是遵循 此代码示例，其中提供了有关设置 WS-Federation 的略有不同的说明。 此代码示例不使用 WIF，而是 ASP.NET 4.5 OWIN 中间件。 但是，有关应用注册的说明对于使用 WIF 的应用有效，并且不需要Microsoft Entra ID P1 或 P2 许可证。

如果选择此方法，则需要了解 Microsoft Entra ID 中的签名密钥切换。 此方法使用 Microsoft Entra 全局签名密钥颁发令牌。 默认情况下，WIF 不会自动刷新签名密钥。 当Microsoft Entra ID 轮换其全局签名密钥时，WIF 实现需要准备好接受这些更改。 有关详细信息，请参阅 Microsoft Entra ID 中签名密钥轮换的重要信息。

如果可以通过 OpenID Connect 或 OAuth 协议与 Microsoft Entra ID 集成，我们建议这样做。 我们的 Microsoft Entra 开发人员指南中提供了有关如何将 Microsoft Entra ID 集成到 Web 应用程序中的广泛文档和指南。

迁移到 Azure Active Directory B2C

要考虑的另一个迁移路径是 Azure AD B2C。 Azure AD B2C 是一种云身份验证服务，如访问控制，允许开发人员将其身份验证和标识管理逻辑外包给云服务。 它是一项付费服务（具有免费层和高级层），专为面向消费者的应用程序设计，可能拥有多达数百万活跃用户。

与访问控制一样，Azure AD B2C 最有吸引力的功能之一是它支持许多不同类型的帐户。 使用 Azure AD B2C，可以使用其Microsoft帐户或 Facebook、Google、LinkedIn、GitHub 或 Yahoo 帐户等登录用户。 Azure AD B2C 还支持用户专门为应用程序创建的“本地帐户”或用户名和密码。 Azure AD B2C 还提供丰富的扩展性，可用于自定义登录流。

但是，Azure AD B2C 不支持访问控制客户可能需要的身份验证协议和令牌格式的广度。 不能使用 Azure AD B2C 从身份提供者获取令牌并查询用户的其他信息，无论是 Microsoft 还是其他身份提供者。

下表将与 Web 应用程序相关的访问控制功能与 Azure AD B2C 中可用的功能进行比较。 在高级别上， 如果应用程序面向使用者，或者它支持许多不同类型的帐户，Azure AD B2C 可能是迁移的正确选择。

如果确定 Azure AD B2C 是应用程序和服务的最佳迁移路径，请从以下资源开始：

• Azure AD B2C 文档
• Azure AD B2C 自定义策略
• Azure AD B2C 定价

迁移到 Ping Identity 或 Auth0

在某些情况下，你可能会发现，Microsoft Entra ID 和 Azure AD B2C 不足以替换 Web 应用程序中的访问控制，而无需进行重大代码更改。 一些常见示例可能包括：

• 使用 WIF 或 WS-Federation 通过社交标识提供者（如 Google 或 Facebook）登录的 Web 应用程序。
• 通过 WS-Federation 协议直接联合到企业标识提供者的 Web 应用程序。
• Web 应用程序需要社交身份提供者（如 Google 或 Facebook）颁发的访问令牌，并在访问控制颁发的令牌中作为声明使用。
• 具有复杂令牌转换规则的 Web 应用程序，Microsoft Entra ID 或 Azure AD B2C 无法实现。
• 使用 ACS 对多个不同身份提供商进行集中管理的多租户 Web 应用程序

在这些情况下，可能需要考虑将 Web 应用程序迁移到另一个云身份验证服务。 建议浏览以下选项。 以下每个选项都提供类似于访问控制的功能：

Auth0 是一种灵活的云标识服务， 它为访问控制的客户创建了高级迁移指南，并支持 ACS 执行的每个功能。

Ping 标识 提供两个类似于 ACS 的解决方案。 PingOne 是一种云标识服务，支持与 ACS 相同的许多功能，PingFederate 是一种类似的本地标识产品，可提供更大的灵活性。 有关使用这些产品的更多详细信息，请参阅 Ping 的 ACS 停用指南。

我们的目标是使用 Ping Identity 和 Auth0，以确保所有访问控制客户都有其应用和服务迁移路径，从而最大程度地减少从访问控制移动所需的工作量。

使用活动身份验证的 Web 服务

对于使用访问控制颁发的令牌进行保护的 Web 服务，访问控制提供以下特性和功能：

• 能够在访问控制命名空间中注册一个或多个 服务标识 。 服务标识可用于请求令牌。
• 支持 OAuth WRAP 和 OAuth 2.0 草稿 13 协议来请求令牌，方法是使用以下类型的凭据：
  • 为服务标识创建的简单密码
  • 使用对称密钥或 X509 证书签名的 SWT
  • 受信任的标识提供者颁发的 SAML 令牌（通常为 AD FS 实例）
• 支持以下令牌格式：JWT、SAML 1.1、SAML 2.0 和 SWT。
• 简单的令牌转换规则。

访问控制中的服务标识通常用于实现服务器到服务器身份验证。

迁移到 Microsoft Entra ID

对于这种类型的身份验证流，建议迁移到 Microsoft Entra ID。 Microsoft Entra ID 是Microsoft工作或学校帐户的基于云的标识提供者。 Microsoft Entra ID 是用于 Microsoft 365、Azure 等的标识提供者。

还可以通过 Microsoft Entra 对 OAuth 客户端凭据授权的实现方式，使用 Microsoft Entra ID 进行服务器到服务器的身份验证。 下表比较了服务器到服务器身份验证中的访问控制功能与 Microsoft Entra ID 中可用的功能。

有关实现服务器到服务器方案的指南，请参阅以下资源：

• Microsoft Entra 开发人员指南的“服务对服务”部分
• 使用简单密码客户端凭据的守护程序代码示例
• 使用证书客户端凭据的守护程序代码示例

迁移到 Ping Identity 或 Auth0

在某些情况下，你可能会发现，Microsoft Entra 客户端凭据和 OAuth 授予实现不足以替换体系结构中的访问控制，而无需更改主要代码。 一些常见示例可能包括：

• 使用除 JWT 之外的令牌格式进行服务器到服务器的身份验证。
• 使用外部标识提供者提供的输入令牌进行服务器到服务器身份验证。
• 使用Microsoft Entra ID 无法重现的令牌转换规则的服务器到服务器身份验证。

在这些情况下，可以考虑将 Web 应用程序迁移到另一个云身份验证服务。 建议浏览以下选项。 以下每个选项都提供类似于访问控制的功能：

Auth0 是一种灵活的云标识服务， 它为访问控制的客户创建了高级迁移指南，并支持 ACS 执行的每个功能。

Ping Identity 提供两种类似于 ACS 的解决方案。 PingOne 是一种云标识服务，支持与 ACS 相同的许多功能，PingFederate 是一种类似的本地标识产品，可提供更大的灵活性。 有关使用这些产品的更多详细信息，请参阅 Ping 的 ACS 停用指南。

我们的目标是使用 Ping Identity 和 Auth0，以确保所有访问控制客户都有其应用和服务迁移路径，从而最大程度地减少从访问控制移动所需的工作量。

透传身份验证

对于使用任意令牌转换的直通式身份验证，没有相当于 ACS 的 Microsoft 技术。 如果这是你的客户所需的，Auth0 可能是提供最接近近似解决方案的人。

问题、顾虑和反馈

我们知道，阅读本文后，许多访问控制客户不会找到明确的迁移路径。 在确定正确的计划时，可能需要一些帮助或指导。 若要讨论迁移方案和问题，请在此页上留下评论。