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

多租户解决方案中标识的体系结构注意事项

  • 项目

标识对于任何多租户解决方案来说都很重要。 应用程序的标识组件负责以下两项：

  • 验证用户是谁（身份验证）。
  • 在租户范围内强制实施用户的权限（授权）。

客户可能还希望授权外部应用程序访问其数据或集成到解决方案。 用户的标识确定用户或服务将访问哪些信息。 请务必考虑标识要求，以便在租户之间隔离应用程序和数据。

注意

身份验证和授权服务（在多租户和 SaaS 应用程序中）通常由第三方标识提供者 (IdP) 提供。 标识提供者通常是标识即服务 (IDaaS) 平台的重要组成部分。

构建自己的 IdP 非常复杂、昂贵且难以安全地构建。 构建自己的标识提供者是一种反模式。 但我们不建议这样做。

在定义多租户标识策略之前，首先应考虑服务的高级别标识要求，包括以下要求：

  • 用户或工作负载标识是否用于访问产品系列中的单个应用程序或多个应用程序？ 例如，零售产品系列可能同时具有销售点应用程序和库存管理应用程序，两者共享相同的标识解决方案。
  • 是否打算实施新式身份验证和授权，例如 OAuth2 和 OpenID 连接？
  • 解决方案是否仅向基于 UI 的应用程序提供身份验证？ 或者，是否还会向租户和第三方提供 API 访问权限？
  • 租户是否需要联合到自己的 IdP，并且每个租户是否需要支持多个不同的标识提供者？ 例如，你可能有 Microsoft Entra ID、Auth0 和 Active Directory 联合身份验证服务 (ADFS) 的租户，其中每个租户都希望与解决方案联合。 还需要了解要支持的租户 IdP 的联合协议，因为协议会影响你自己的 IdP 的要求。
  • 是否需要满足特定的合规性要求，例如 GDPR？
  • 租户是否需要其标识信息位于特定地理区域中？
  • 解决方案的用户是否需要访问应用程序内一个租户或多个租户的数据？ 他们是否需要能够快速在租户之间切换或查看来自多个租户的合并信息？ 例如，登录到 Azure 门户的用户可以轻松地在他们有权访问的不同 Azure Active Directory 和订阅之间切换。

建立高级别要求后，可以开始规划更具体的细节和要求，例如用户目录源和注册/登录流。

标识目录

若要使多租户解决方案对用户或服务进行身份验证和授权，需要一个存储标识信息的位置。 目录可以包含每个标识的权威记录，也可能包含对存储在另一标识提供者目录中的外部标识的引用。

为多租户解决方案设计标识系统时，需要考虑租户和客户可能需要的以下 IDP 类型之一：

  • 本地标识提供者。 本地标识提供者允许用户自行注册服务。 用户提供用户名、电子邮件地址或标识符，例如奖励卡号。 它们还提供凭据，例如密码。 IdP 存储用户标识符和凭据。
  • 社交标识提供者。 社交标识提供者允许用户使用他们在社交网络或其他公共标识提供者（如 Facebook、Google 或个人 Microsoft 帐户）上拥有的标识。
  • 使用租户的 Microsoft Entra ID 或 Microsoft 365 目录。 租户可能已有自己的 Microsoft Entra ID 或 Microsoft 365 目录，他们可能希望解决方案使用其目录作为 IdP 来访问解决方案。 当解决方案构建为多租户 Microsoft Entra 应用程序时，此方法是可行的。
  • 与租户的标识提供者联合。 租户可能有自己的 IdP，而不是 Microsoft Entra ID 或 Microsoft 365，他们可能希望你的解决方案与其联合。 联合身份验证支持单一登录 (SSO) 体验，它使租户能够独立于解决方案管理其用户的生命周期和安全策略。

你应考虑租户是否需要支持多个标识提供者。 例如，可能需要支持本地标识、社交标识和联合标识（全部位于单个租户中）。 当公司对自己的员工和承包商使用解决方案时，这一需求很常见。 他们可能会使用联合身份验证让自己的员工访问解决方案，同时允许对承包商或来宾用户（在联合 IdP 中没有帐户）的访问权限。

存储身份验证和租户授权信息

在多租户解决方案中，需要考虑存储多种标识信息的位置，包括以下类型：

  • 有关用户和服务帐户的详细信息，包括其名称和租户所需的其他信息。
  • 安全对用户进行身份验证所需的信息，包括提供多重身份验证 (MFA) 所需的信息。
  • 特定于租户的信息，例如租户角色和权限。 此信息用于授权。

注意

我们不建议自己生成身份验证过程。 新式 IdP 为应用程序提供这些身份验证服务，并且还包括其他重要功能，例如 MFA 和条件访问。 构建自己的标识提供者是一种反模式。 但我们不建议这样做。

请考虑以下用于存储标识信息的选项：

  • 把所有标识和授权信息存储在 IdP 目录中，并在多个租户之间共享。
  • 把用户凭据存储在 Store IdP 目录中，并将授权信息与租户信息一起存储在应用程序层中。

确定用户的标识数

多租户解决方案通常允许用户或工作负载标识访问多个租户的应用程序和数据。 请考虑解决方案是否需要此方法。 如果是，则应考虑以下问题：

  • 是否应为每个人员创建单个用户标识，还是为每个租户用户组合创建单独的标识？
    • 最好尽可能对每个人使用单个标识。 无论是作为解决方案供应商的你还是你的用户，管理多个用户帐户都变得困难。 此外，新式 IdP 提供的许多智能威胁防护依赖于拥有单个用户帐户的每个人。
    • 但是，在某些情况下，用户可能需要具有多个不同的标识。 例如，如果人们同时使用你的系统进行工作和个人目的，他们可能需要将用户帐户分开。 或者，如果你的租户具有严格的法规或地理数据存储要求，他们可能需要一个人具有多个标识，以便他们可以遵守法规或法律。
  • 如果使用每租户标识，请避免多次存储凭据。 用户应具有针对单个标识存储的凭据，并且应使用来宾标识等功能从多个租户的标识记录引用相同的用户凭据。

向用户授予对租户数据的访问权限

考虑如何将用户映射到租户。 例如，在注册过程中，可以使用首次访问租户时输入的唯一邀请代码。 在某些解决方案中，可以使用用户的注册电子邮件地址的域名来标识他们所属的租户。 或者，可以使用用户标识记录的另一个属性将用户映射到租户。 然后，应根据租户和用户的基础不可变唯一标识符存储映射。

如果解决方案旨在使单个用户只能访问单个租户的数据，请考虑以下决策：

  • IdP 如何检测用户正在访问的租户？
  • IdP 如何将租户标识符与应用程序通信？ 通常，租户标识符声明会添加到令牌中。

如果需要向单个用户授予对多个租户的访问权限，则需要考虑以下决策：

  • 解决方案如何标识并向有权访问多个租户的用户授予权限？ 例如，用户是否可以是培训租户中的管理员，并且对生产租户具有只读访问权限？ 或者，是否可以为组织中的不同部门单独创建租户，但你需要在所有租户中保持一致的用户标识？
  • 用户如何在租户之间切换？
  • 如果使用工作负载标识，工作负载标识如何指定它需要访问的租户？
  • 是否存在存储在用户标识记录中的租户特定信息，这些信息可能会在租户之间泄露？ 例如，假设用户注册了社交标识，然后被授予对两个租户的访问权限。 租户 A 扩充了用户标识的详细信息。 租户 B 是否有权访问扩充信息？

本地标识或社交标识的用户注册过程

某些租户可能需要允许用户自行注册解决方案中的标识。 如果你不需要与租户的标识提供者联合，则可能需要自助注册。 如果需要自注册过程，应考虑以下问题：

  • 哪些标识源允许用户从中注册？ 例如，用户是否可以创建本地标识并使用社交标识提供者？
  • 如果仅允许本地标识，是否会只允许特定电子邮件域？ 例如，租户是否可以指定只有拥有 @contoso.com 电子邮件地址的用户才能注册？
  • 应在登录过程中用于唯一标识每个本地标识的用户主体名称 (UPN) 是什么？ 例如，电子邮件地址、用户名、电话号码和奖励卡号都是 UPN 的常见选择。 但是，UPN 可能会随时间变化。 在应用程序的授权规则或审核日志中引用标识时，最好使用标识的基础不可变唯一标识符。 Microsoft Entra ID 提供对象 ID (OID)，这是不可变标识符。
  • 用户是否需要验证其 UPN？ 例如，如果用户的电子邮件地址或电话号码用作 UPN，则如何验证信息是否准确？
  • 租户管理员是否需要批准注册？
  • 租户是否需要特定于租户的注册体验或 URL？ 例如，用户注册时，租户是否需要品牌注册体验？ 租户是否需要在继续注册之前截获注册请求并执行额外验证？

自注册用户的租户访问权限

允许用户自行注册标识时，通常需要有一个进程，以便他们有权访问租户。 注册流可能包括访问授权过程，也可以根据有关用户的信息（例如其电子邮件地址）进行自动化。 必须规划此进程，并考虑以下问题：

  • 注册流将如何确定应向用户授予对特定租户的访问权限？
  • 如果用户不再有权访问租户，你的解决方案是否会自动撤销其访问权限？ 例如，当用户离开组织时，需要有一个手动或自动化的过程，用于从租户中删除其访问权限。
  • 是否需要为租户提供一种方法来审核有权访问其租户的用户及其权限？

自动化帐户生命周期管理

企业或企业客户对解决方案的的常见要求是具有一组让客户能够自动加入和注销帐户的功能。 开放协议（如跨域标识管理系统 (SCIM)）提供行业标准自动化方法。 此自动化过程通常不仅包括创建和删除标识记录，还包括管理租户权限。 在多租户解决方案中实现自动化帐户生命周期管理时，请考虑以下问题：

  • 客户是否需要配置和管理每个租户的自动化生命周期流程？ 例如，当用户加入时，可能需要在应用程序中的多个租户中创建标识，其中每个租户都有一组不同的权限。
  • 是否需要实现 SCIM，或者是否可以改为提供租户联合身份验证，以保留租户控制下的用户的真相来源，而不是管理本地用户？

用户身份验证过程

当用户登录到多租户应用程序时，标识系统对用户进行身份验证。 规划身份验证过程时，应考虑以下问题：

  • 租户是否需要配置自己的多重身份验证 (MFA) 策略？ 例如，如果你的租户位于金融服务行业，则需要实施严格的 MFA 策略，而一家小型在线零售商可能没有相同的要求。
  • 租户是否需要配置自己的条件访问规则？ 例如，不同的租户可能需要阻止来自特定地理区域的登录尝试。
  • 租户是否需要为每个租户自定义登录过程？ 例如，是否需要显示客户的徽标？ 或者，是否需要从另一个系统（例如奖励号码）中提取有关每个用户的信息，并返回到标识提供者以添加到用户配置文件？
  • 你的用户是否需要模拟其他用户？ 例如，支持团队成员可能希望通过模拟其用户帐户来调查其他用户存在的问题，而无需以用户身份进行身份验证。
  • 用户是否需要访问解决方案的 API？ 例如，用户或第三方应用程序可能需要直接调用 API 来扩展解决方案，而无需用户界面来提供身份验证流。

工作负载标识

在大多数解决方案中，标识通常表示用户。 某些多租户系统还允许服务和应用程序使用工作负载标识来访问应用程序资源。 例如，租户可能需要访问解决方案提供的 API，以便他们可以自动执行某些管理任务。

工作负载标识类似于用户标识，但通常需要不同的身份验证方法，例如密钥或证书。 工作负载标识不使用 MFA。 相反，工作负载标识通常需要其他安全控制，例如常规密钥滚动和证书过期。

如果租户希望能够启用对多租户解决方案的工作负载标识访问，则应考虑以下问题：

  • 如何在每个租户中创建和管理工作负载标识？
  • 工作负载标识请求的范围如何限定为租户？
  • 是否需要限制每个租户创建的工作负载标识数？
  • 是否需要针对每个租户的工作负载标识提供条件访问控制？ 例如，租户可能需要限制从特定区域外部进行身份验证的工作负载标识。
  • 向租户提供哪些安全控制，以确保工作负载标识的安全？ 例如，自动密钥滚动、密钥过期、证书过期和登录风险监视都是降低风险的方法，其中可能会滥用工作负载标识。

与标识提供者联合进行单一登录 (SSO)

已拥有自己的用户目录的租户可能希望解决方案联合到其目录。 联合身份验证允许解决方案在其目录中使用标识，而不是使用不同的标识管理另一个目录。

当某些租户想要指定自己的标识策略或启用单一登录 (SSO) 体验时，联合身份验证尤其重要。

如果希望租户与解决方案联合，应考虑以下问题：

  • 为租户配置联合身份验证的过程是什么？ 租户是否可以自行配置联合身份验证，或者该过程是否需要团队手动配置和维护？
  • 你将支持哪些联合身份验证协议？
  • 要确保正确配置联合身份验证，向另一个租户授予访问权限，需要执行哪些流程？
  • 单个租户的标识提供者是否需要与解决方案中的多个租户联合？ 例如，如果客户同时拥有培训和生产租户，则可能需要将同一标识提供者联合到这两个租户。

授权模型

确定最适合解决方案的授权模型。 两种常见的授权方法包括：

  • 基于角色的授权。 用户将分配到角色。 应用程序的一些功能仅限于特定角色。 例如，管理员角色中的用户可以执行任何操作，而角色较低的用户在整个系统中可能具有一部分权限。
  • 基于资源的授权。 你的解决方案提供了一组不同的资源，每个资源都有自己的一组权限。 特定用户可能是一个资源的管理员，并且无权访问另一个资源。

这些模型是不同的，你选择的方法会影响实现和可以实现的授权策略的复杂性。

有关详细信息，请参阅基于角色和基于资源的授权。

权利和许可

在某些解决方案中，可以将每用户授权用作商业定价模型的一部分。 你将提供具有不同功能的不同用户许可证层。 例如，允许具有一个许可证的用户使用应用程序的一部分功能。 特定用户根据许可证访问的功能有时称为权利。

尽管跟踪和强制执行权利类似于授权，但它通常由应用程序代码或专用权利系统处理，而不是由标识系统管理。

标识缩放和身份验证卷

随着多租户解决方案的增长，解决方案需要处理的用户和登录请求数将增加。 应考虑以下因素：

  • 用户目录会缩放到所需的用户数吗？
  • 身份验证过程会处理预期的登录和注册数吗？
  • 身份验证系统会遇到无法处理的峰值吗？ 例如，太平洋标准时间上午 9 点，美国西部地区的每个人都可能会开始工作并登录到解决方案，从而导致登录请求激增。 这些情况有时称为登录风暴。
  • 解决方案其他部分中的高负载是否会影响身份验证过程的性能？ 例如，如果你的身份验证过程需要调用应用程序层 API，那么大量的身份验证请求是否会导致解决方案的其余部分出现问题？
  • 如果 IdP 不可用，会发生什么情况？ IdP 不可用时，是否有备份身份验证服务可以接管以提供业务连续性？

作者

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

主要作者：

其他参与者：

后续步骤

请参阅多租户解决方案中的标识体系结构方法。