通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

在多租户体系结构中使用 Azure Active Directory B2C 的注意事项

  • 项目

Azure Active Directory (Azure AD) B2C 以服务的形式提供企业对消费者的标识。 设计多租户应用程序时，用户标识通常是主要注意事项之一。 标识解决方案充当应用程序的守护者，确保租户留在你为租户定义的边界内。 本文介绍在多租户解决方案中使用 Azure AD B2C 的注意事项和方法。

使用 Azure AD B2C 的最常见原因之一是为应用程序启用联合身份验证。 联合身份验证是在两个标识提供者之间建立信任的过程，以便用户可以使用预先存在的帐户登录。 如果使用 Azure AD B2C，则可实现联合身份验证，使用户能够使用社交帐户或企业帐户登录。 如果使用联合身份验证，则用户无需单独创建特定于应用程序的本地帐户。

如果不熟悉本主题，建议查看以下资源：

注意

本文讨论了两个名称类似的概念：应用程序租户和 Azure AD B2C 租户。

术语应用程序租户指代你的租户，这可能是你的客户或用户组。

Azure AD B2C 也使用租户概念来指代各个目录，术语多租户用于指代多个 Azure AD B2C 租户之间的交互。 尽管术语相同，但概念不同。 本文中提到 Azure AD B2C 租户时，使用的是完整术语Azure AD B2C 租户。

多租户解决方案中的标识

在多租户解决方案中，通常组合使用多个标识服务来实现不同的要求集。 许多解决方案都有两组不同的标识：

  • 客户标识，用于最终用户帐户。 可控制租户的用户访问应用程序的方式。
  • 内部标识，用于处理你自己的团队管理解决方案的方式。

这些不同的标识类型通常也使用不同的标识服务。 Azure AD B2C 是一种客户标识和访问管理 (CIAM) 服务，租户用户可使用该服务来访问解决方案。 Microsoft Entra ID 是一项身份验证和访问控制管理 (IAM) 服务，而你和你的团队可使用它来管理 Azure 资源以及控制应用程序。

假设 Fabrikam 构建了一个示例多租户解决方案。 该解决方案结合使用这两种服务来满足 Fabrikam 的要求：

  • Fabrikam 实现 Azure AD B2C，以便公司的客户（租户）登录应用程序。
  • Fabrikam 的员工使用组织的 Microsoft Entra 目录访问解决方案以进行经营管理。 他们使用的标识与用于访问其他 Fabrikam 资源（如 Microsoft Office）的标识相同。

下图演示了此示例：

描述有两种登录方法的两个应用程序的示意图。

隔离模型

使用 Azure AD B2C 时，需要确定如何在不同应用程序租户之间隔离用户帐户。

你需要考虑以下问题：

  • 是否需要将客户标识提供者的登录相联合？ 例如，是否需要实现 SAML、Microsoft Entra ID、社交登录提供者或其他源的联合？
  • 你或你的租户是否有数据驻留要求？
  • 用户是否需要访问多个应用程序租户？
  • 是否需要复杂的权限和/或基于角色的访问控制 (RBAC)？
  • 谁登录到应用程序？ 不同类别的用户通常称为用户角色。

下表汇总了 Azure AD B2C 的主要租户模型之间的差异：

注意事项 共享 Azure AD B2C 租户 垂直分区的 Azure AD B2C 租户 每个应用程序租户一个 Azure AD B2C 租户
数据隔离 每个应用程序租户的数据存储在单个 Azure AD B2C 租户中，但只能由管理员访问 每个应用程序租户的数据分布在多个 Azure AD B2C 租户中，但只能由管理员访问 每个应用程序租户的数据存储在专用 Azure AD B2C 租户中，但只能由管理员访问
部署复杂性 低 中高，具体取决于分区策略 很高
要考虑的限制 每个 Azure AD B2C 租户的请求数、每个客户端 IP 地址的请求数 请求数、每个订阅的 Azure AD B2C 租户数以及单个用户的目录数的组合，具体取决于分区策略 每个订阅的 Azure AD B2C 租户数、单个用户的目录数上限
操作复杂性 低 中高，具体取决于分区策略 很高
所需的 Azure AD B2C 租户数 一种 1 - n,，具体取决于分区策略 n，其中 n 是应用程序租户数
示例方案 你正在为数据驻留要求较低或没有该要求的使用者构建 SaaS 产品/服务，如音乐或视频流服务。 你正在构建 SaaS 产品/服务，例如面向企业的会计记帐应用程序。 需要支持数据驻留要求或大量的自定义联合标识提供者。 你正在构建 SaaS 产品/服务，例如面向企业的政府记帐应用程序。 客户要求实现与其他应用程序租户的高度数据隔离。

共享 Azure AD B2C 租户

如果要求允许，管理单个共享 Azure AD B2C 租户通常最简单。 只需长期维护一个租户，并且此选项产生的开销最低。

注意

建议在大多数情况下使用共享 Azure AD B2C 租户。

在以下情况下，应考虑使用共享 Azure AD B2C 租户：

  • 没有数据驻留要求或严格的数据隔离要求。
  • 应用程序要求在 Azure AD B2C 服务限制范围内。
  • 如果你有联合标识提供者，可使用主领域发现自动为用户选择一个提供者进行登录，或者用户可从列表中手动选择一个提供者。
  • 为所有应用程序租户提供统一的登录体验。
  • 最终用户需要使用单个帐户访问多个应用程序租户。

下图说明了共享 Azure AD B2C 租户模型：

示意图显示三个应用程序连接到单个共享 Azure AD B2C 租户。

垂直分区的 Azure AD B2C 租户

预配垂直分区的 Azure AD B2C 租户是一种策略，旨在尽可能减少所需的 Azure AD B2C 租户数。 它是其他两个租户模型之间的折中方案。 如果需要，垂直分区可为特定租户提供更大的自定义灵活性。 然而，它不会产生与为每个应用程序租户预配 Azure AD B2C 租户相关的操作开销。

此租户模型的部署和维护要求高于单个 Azure AD B2C 租户的相应要求，但低于使用“每个应用程序租户一个 Azure AD B2C 租户”时的相应要求。 仍需为整个环境中的多个租户设计和实施部署和维护策略。

垂直分区类似于数据分片模式。 要对 Azure AD B2C 租户进行垂直分区，需要将应用程序租户组织到逻辑组中。 这种租户分类方式通常称为分区策略。 分区策略应基于应用程序租户的稳定公共因素，例如区域、大小或应用程序租户的自定义要求。 例如，如果目标是解决数据驻留要求，可决定为托管应用程序租户的每个区域部署一个 Azure AD B2C 租户。 或者，如果按大小分组，可决定将大多数应用程序租户的标识置于单个 Azure AD B2C 租户中，但将最大的应用程序租户置于它们自己的专用 Azure AD B2C 租户中。

重要

避免使分区策略基于可能会随时间变化的因素，因为很难在 Azure AD B2C 租户之间移动用户。 例如，如果创建的 SaaS 产品/服务具有多个 SKU 或产品层，则不应根据用户选择的 SKU 对用户进行分区，因为如果客户升级其产品，SKU 可能会更改。

在以下情况下，应考虑使用垂直分区策略预配 Azure AD B2C 租户：

  • 有数据驻留要求，或需按地理位置分隔用户。
  • 拥有大量联合标识提供者，并且无法使用主领域发现自动为用户选择一个提供者进行登录。
  • 应用程序了解（或可能了解）多租户，并且知道用户需要登录到哪个 Azure AD B2C 租户。
  • 认为较大的应用程序租户可能会达到 Azure AD B2C 限制。
  • 有一个部署和维护中等数量到大量的 Azure AD B2C 租户的长期策略。
  • 拥有以下策略：将应用程序租户划分到一个或多个 Azure 订阅，以在 Azure 订阅中可部署的 Azure AD B2C 租户数限制范围内工作。

下图说明了垂直分区的 Azure AD B2C 租户模型：

示意图显示三个应用程序。其中两个连接到共享 Azure AD B2C 租户。第三个应用程序连接到其自己的 Azure AD B2C 租户。

每个应用程序租户一个 Azure AD B2C 租户

如果为每个应用程序租户预配一个 Azure AD B2C 租户，则可为每个租户自定义多个因素。 但是，此方法会显著增加开销。 需要为潜在的大量 Azure AD B2C 租户制定部署和维护策略。

还需了解上传限制。 Azure 订阅支持只部署有限数量的 Azure AD B2C 租户。 如果需要部署超过该限制所允许的数量，则需考虑适当的订阅设计，以便在多个订阅之间均衡分布 Azure AD B2C 租户。 还有其他 Microsoft Entra 限制也适用，例如单个用户可创建的目录数以及用户可以属于的目录数。

警告

由于此方法较为复杂，强烈建议首先考虑其他隔离模型。 出于完整性考虑，此处包含了此选项，但对于大多数用例来说，它并不是适当的方法。

一个常见的误解是认为，如果使用部署缩放单元模式，则需在每个缩放单元中包含标识服务。 这不一定正确，通常可改用另一种隔离模型。 如果使用此隔离模型，请谨慎处理并有明确的业务理由。 部署和维护开销很大。

只有在以下情况下，才应考虑为每个应用程序租户预配一个 Azure AD B2C 租户：

  • 对应用程序租户有严格的数据隔离要求。
  • 有一个部署和维护大量 Azure AD B2C 租户的长期策略。
  • 拥有以下策略：将客户划分到一个或多个 Azure 订阅以符合 Azure AD B2C 每订阅租户限制。
  • 应用程序了解（或可能了解）多租户，并且知道用户需要登录到哪个 Azure AD B2C 租户。
  • 需要为每个应用程序租户执行自定义配置。
  • 最终用户无需通过同一登录帐户访问多个应用程序租户。

下图说明了“每个应用程序租户一个 Azure AD B2C 租户”的使用：

示意图显示三个应用程序，每个都连接到自己的 Azure AD B2C 租户。

联合身份验证

需要通过用户流或自定义策略配置每个联合标识提供者。 通常在登录期间，用户选择要用于进行身份验证的标识提供者。 如果使用共享租户隔离模型或拥有大量联合标识提供者，请考虑使用主领域发现在登录期间自动选择标识提供者。

还可通过将各个 Azure AD B2C 租户相互联合，将联合身份验证用作管理多个 Azure AD B2C 租户的工具。 这样可使应用程序信任单个 Azure AD B2C 租户。 应用程序无需知道客户分布在多个 Azure AD B2C 租户中。 当按区域对用户分区时，此方法最常用于垂直分区隔离模型。 如果采用此方法，则需考虑一些注意事项。 有关此方法的概述，请参阅全局标识解决方案。

主领域发现

主领域发现是自动为用户的登录事件选择联合标识提供者的过程。 如果自动选择用户的标识提供者，则无需提示用户选择提供者。

如果使用共享 Azure AD B2C 租户并允许客户自带联合标识提供者，则主领域发现非常重要。 你可能希望避免使用用户需要从标识提供者列表中进行选择的设计。 这种设计会增加登录过程的复杂性。 此外，用户可能会意外选择不正确的提供者，从而导致登录尝试失败。

可通过各种方式配置主领域发现。 最常见的方式是使用用户电子邮件地址的域后缀来确定标识提供者。 例如，假设 Northwind Traders 是 Fabrikam 多租户解决方案的客户。 电子邮件地址 user@northwindtraders.com 包含域后缀 northwindtraders.com，该后缀可映射到 Northwind Traders 联合标识提供者。

有关详细信息，请参阅主领域发现。 有关如何在 Azure AD B2C 中实现此方法的示例，请参阅 Azure AD B2C 示例 GitHub 存储库。

数据驻留

预配 Azure AD B2C 租户时，出于数据驻留目的，可选择部署租户的区域。 此选择非常重要，因为这将指定客户数据处于静态状态时所在的区域。 如果对部分客户有数据驻留要求，请考虑使用垂直分区策略。

授权

对于强标识解决方案，除了身份验证之外，还需考虑授权。 可通过多种方法使用 Microsoft 标识平台为应用程序创建授权策略。 AppRoles 示例演示如何使用 Azure AD B2C 应用角色在应用程序中实现授权， 还介绍了替代的授权方法。

授权方法并非只有一种，在确定授权方法时，应考虑应用程序和客户的需求。

维护

规划 Azure AD B2C 多租户部署时，需要考虑 Azure AD B2C 资源的长期维护。 Azure AD B2C 租户（如组织 Microsoft Entra 租户）是需要创建、维护、操作和保护的资源。 尽管以下列表并不全面，但应考虑以下方面产生的维护：

  • 租户治理。 谁维护 Azure AD B2C 租户？ 这些管理员需要哪些提升的角色？ 如何为管理员配置条件访问和 MFA 策略？ 如何长期监视 Azure AD B2C 租户？
  • 用户旅程配置。 如何将更改部署到一个或多个 Azure AD B2C 租户？ 在部署对用户流或自定义策略的更改之前，如何测试这些更改？
  • 联合标识提供者。 是否需要随时间推移添加或删除标识提供者？ 如果允许每个客户自带标识提供者，如何大规模地管理？
  • 应用注册。 许多 Microsoft Entra 应用注册使用客户端密码或证书进行身份验证。 如何在需要时轮换这些密码或证书？
  • 策略密钥。 如果使用自定义策略，如何在需要时轮换策略密钥？
  • 用户凭据。 如何管理用户信息和凭据？ 如果其中一个用户被锁定或忘记密码并需要管理员或客户服务干预，会发生什么情况？

请记住，需要为部署的每个 Azure AD B2C 租户考虑这些问题。 如果有多个 Azure AD B2C 租户要维护，则还应考虑如何更改流程。 例如，手动将自定义策略更改部署到一个 Azure AD B2C 租户很容易，但手动将其部署到五个租户既耗时又有风险。

部署和 DevOps

定义完善的 DevOps 流程有助于最大限度地减少维护 Azure AD B2C 租户所需的开销。 应在开发过程的早期实施 DevOps 做法。 理想情况下，应尝试自动执行所有或大部分维护任务，包括部署对自定义策略或用户流的更改。 还应计划创建多个 Azure AD B2C 租户，以在较低级别的环境中逐步测试更改，然后再将其部署到生产租户。 DevOps 管道可执行这些维护活动。 可使用 Microsoft Graph API 以编程方式管理 Azure AD B2C 租户。

有关 Azure AD B2C 的自动部署和管理的详细信息，请参阅以下资源。

重要

用于以编程方式管理 Azure AD B2C 的某些终结点尚未正式发布。 Beta 版 Microsoft Graph 中的 API 随时可能变动，并受预发布服务条款的约束。

比较 Microsoft Entra B2B 与 Azure AD B2C

Microsoft Entra B2B 协作是 Microsoft Entra 外部 ID 的一项功能，可用于邀请来宾用户加入组织 Microsoft Entra 租户，以便与他们协作。 通常在需要向外部用户（如供应商）授予对 Microsoft Entra 租户中资源的访问权限时，可使用 B2B 协作。

Azure AD B2C 是一款独特的产品，它除了提供 Microsoft Entra 外部 ID 之外，还提供一组其他功能。 Azure AD B2C 旨在供产品客户使用。 Azure AD B2C 租户与组织 Microsoft Entra 租户并不相同。

根据你的用户角色和方案，可能需要使用 Microsoft Entra B2B、Azure AD B2C，甚至同时使用两者。 例如，如果应用程序需要在同一应用中对多种类型的用户（例如组织中的员工、为供应商工作的用户以及客户）进行身份验证，则可同时使用 Microsoft Entra B2B 和 Azure AD B2C 来满足此需求。

有关详细信息，请参阅：

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

其他参与者：

若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤