通过

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

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

几乎所有多租户解决方案都需要标识系统。 本文介绍标识的常见组件，包括身份验证和授权，以及如何在多租户解决方案中应用这些组件。

注意

在开始为多租户解决方案生成标识系统之前，请参阅 多租户解决方案中标识的体系结构注意事项。

身份验证

身份验证是建立用户标识的过程。 构建多租户解决方案时，请考虑身份验证过程的不同方面的各种方法。

联合

可能需要与外部标识提供者（IdP）联合。 可以使用联合身份验证来启用以下场景：

  • 社交登录，允许用户使用 Google、Facebook、GitHub 或个人Microsoft帐户登录

  • 特定于租户的目录，使租户能够将应用程序与其自己的 IdP 联合，以便无需在多个位置管理帐户

有关详细信息，请参阅 联合标识模式。

如果选择支持特定于租户的 IdP，请确保阐明应用程序支持的服务和协议。 例如，确定是支持 OpenID Connect 协议还是支持安全断言标记语言协议，还是将联合限制为Microsoft Entra ID 实例。

实现 IdP 时，请考虑适用的规模和限制。 例如，IdP 可能只能与数量有限的其他 IdP 联合。

此外，请考虑提供联合身份验证作为仅适用于更高 产品层的客户的功能。

单一登录

使用单一登录，用户可以无缝地在应用程序之间切换，而无需提示用户在每个点重新进行身份验证。

当用户访问应用程序时，应用程序会将其定向到 IdP。 如果 IdP 检测到现有会话，则会发出新令牌，而无需用户与登录过程交互。 联合标识模型支持单一登录，使用户能够跨多个应用程序使用单个标识。

在多租户解决方案中，可以启用另一种形式的单一登录。 如果用户被授权跨多个租户访问数据，那么当他们从一个租户切换到另一个租户时，您可能需要提供流畅的体验。 考虑解决方案是否需要支持租户之间的无缝转换。 如果是这样，请考虑您的 IdP 是否应该重新颁发包含特定租户声明的令牌。 例如，当用户登录到 Azure 门户时，他们可以在不同的Microsoft Entra ID 目录之间切换。 此转换触发重新身份验证，并从新选定的Microsoft Entra ID 实例生成新令牌。

登录风险评估

新式标识平台在登录过程中支持风险评估。 例如，如果用户从异常位置或设备登录，身份验证系统可能需要额外的标识检查，例如多重身份验证 (MFA)，然后才能继续登录请求。

请考虑租户是否可能具有需要在身份验证过程中应用的不同风险策略。 例如，如果你的一些租户处于高度监管的行业，则它们的风险配置文件和要求可能与在不太受监管的环境中工作的租户有不同的风险配置文件和要求。 或者，允许定价层较高的租户指定比购买服务较低层的租户更严格的登录策略。

如果需要为每个租户支持不同的风险策略，身份验证系统需要知道用户登录哪个租户，以便它可以应用正确的策略。

如果 IdP 包含这些功能，请考虑使用 IdP 的本机登录风险评估功能。 这些功能可能复杂且容易出错，可以自行实现。

或者，如果联合到租户的身份提供商(IdP)，则可以应用其有风险的登录缓解策略，从而控制这些强制性策略和管理措施。 例如，需要两个 MFA 挑战，一个来自用户的主 IdP 和另一个来自你自己的，可以使登录过程更加困难。 确保了解联邦身份验证如何与每个租户的 IdP 以及他们制定的策略进行交互。

模拟

通过模拟，用户无需使用该用户的凭据即可假定其他用户的身份。

模拟通常很危险，难以实施和控制。 但是，在某些情况下，需要冒充。 例如，如果在软件即服务（SaaS）环境中作，技术支持人员可能需要假设用户的标识，以便他们可以以用户身份登录并解决问题。

如果实现模拟，请考虑如何审核其使用情况。 确保日志包括执行动作的用户以及他们模拟的用户的标识符。

某些标识平台支持模拟，无论是作为内置功能，还是使用自定义代码。 例如，你可以在 Microsoft Entra 外部 ID 中为被模拟的用户 ID 添加自定义声明，或者替换所颁发令牌中的主体标识符声明。

授权

授权是确定用户允许执行的操作的过程。

授权数据可以存储在多个位置，包括以下位置：

  • 在 IdP 中： 例如，如果使用 Microsoft Entra ID 作为 IdP，则可以使用 应用角色 和 组 等功能来存储授权信息。 然后，应用程序可以使用关联的令牌声明来强制实施授权规则。

  • 在您的应用程序中： 您可以建立自己的授权逻辑，然后将关于每个用户可以执行操作的信息存储在数据库或类似的存储系统中。 然后，可以为基于角色或资源级别的授权设计精细控件。

在大多数多租户解决方案中，客户或租户管理角色和权限分配，而不是多租户系统的供应商。

将租户标识和角色信息添加到令牌

确定解决方案的哪些部分应处理授权请求。 评估是否允许用户访问特定租户中的数据。

一种常见方法是使标识系统将租户标识符声明嵌入令牌中。 此方法使应用程序能够检查声明，并验证用户是否正在使用他们有权访问的租户。 如果使用基于角色的安全模型，可以扩展令牌以包含有关租户中用户角色的信息。

但是，如果允许单个用户访问多个租户，则用户可能需要一种方法来指示他们在登录过程中计划处理的租户。 用户在选择了其活动租户后，IdP 可以颁发一个令牌，其中包含该租户的正确标识符和角色声明。 还需要考虑用户如何在租户之间切换，这需要颁发新令牌。

基于应用程序的授权

另一种方法是使标识系统与租户标识符和角色无关。 用户通过凭据或联合关系进行标识，令牌不包括租户标识符声明。 单独的列表或数据库维护用户有权访问每个租户的记录。 然后，应用程序层验证指定用户是否有权访问基于该列表的特定租户的数据。

使用 Microsoft Entra ID 或外部 ID

Microsoft Entra ID 和外部 ID 是可在自己的多租户解决方案中使用的托管标识平台。

许多多租户解决方案作为 SaaS 运行。 选择使用 Microsoft Entra ID 或外部 ID 部分取决于如何定义租户或客户群。

  • 如果你的租户或客户是组织，他们可能已经将 Microsoft Entra ID 用于 Microsoft 365、Microsoft Teams 或自己的 Azure 环境等服务。 可以在自己的Microsoft Entra ID 目录中创建 多租户应用程序 ，使解决方案可供其他Microsoft Entra ID 目录使用。 还可以在 Azure 市场中 列出解决方案，并使使用 Microsoft Entra ID 的组织可以轻松访问该解决方案。

  • 如果你的租户或客户不使用 Microsoft Entra ID，或者他们不是组织，请考虑使用外部 ID。 外部 ID 提供用于控制用户注册和登录方式的功能。 例如，可以将解决方案的访问权限限制为仅邀请的用户，也可以启用自助注册。 可以使用 自定义品牌。 若要让自己的员工能够登录，您可以通过来宾访问，邀请 Microsoft Entra ID 租户中的用户作为来宾进入外部 ID。 外部 ID 还允许 与其他 IdP 联合。

  • 某些多租户解决方案适用于以前列出的两种方案。 某些租户可能有自己的 Microsoft Entra ID 租户，而其他租户可能没有。 可以将外部 ID 用于此方案， 并使用联合身份验证允许用户从租户的 Microsoft Entra ID 目录登录。

重要

Azure AD B2C 还支持本文中的许多方案。 但是，自 2025 年 5 月 1 日起，不再可供新客户购买，因此不建议为新解决方案购买。 有关详细信息，请参阅 Azure AD B2C 常见问题解答。

要避免的反模式

生成或运行自己的标识系统

构建新式标识平台很复杂。 它需要对一系列协议和标准的支持，而不正确的实现可能会引入安全漏洞。 由于标准和协议发生更改，因此需要不断更新标识系统，以缓解攻击并整合最新的安全功能。 此外，请务必确保标识系统具有复原能力，因为任何停机时间都可能导致解决方案的其余部分产生严重后果。 在大多数情况下，实现 IdP 并不直接有利于业务，但实现多租户服务是必要的。 最好使用由专家构建、操作和保护的专用身份识别系统。

运行自己的标识系统时，需要存储密码哈希或其他形式的凭据，从而成为攻击者的诱人目标。 即使是哈希和加盐密码也往往没有足够的保护，因为攻击者有足够的计算能力来可能损害这些凭据。

运行标识系统时，负责生成和分发 MFA 或一次性密码代码。 你需要一种机制来通过短信或电子邮件发送这些代码。 你还负责检测有针对性的暴力攻击、限制登录尝试和维护审核日志。

最好使用预生成服务或组件，而不是生成或管理自己的标识系统。 例如，考虑管理的身份平台，例如 Microsoft Entra ID 以及外部 ID。 这些平台的供应商负责运行基础结构，通常确保对当前标识和身份验证标准的支持。

未能考虑租户的要求

租户通常对如何在使用的解决方案中管理标识具有很强的偏好。 例如，许多企业客户要求与自己的 IdP 联合才能启用单一登录，并避免管理多组凭据。 其他租户可能在登录过程中需要多因素认证 (MFA) 或额外的安全措施。 如果在设计过程中不考虑这些要求，以后添加这些要求可能会很困难。

在完成标识系统设计之前，请确保了解租户的标识要求。 有关特定要求的详细信息，请参阅 多租户解决方案中标识的体系结构注意事项。

将用户和租户串联在一起

请务必清楚地考虑解决方案如何定义用户和租户。 在许多情况下，关系可能比较复杂。 例如，租户可能包含多个用户，单个用户可能会加入多个租户。

确保有一个明确的过程来跟踪应用程序和请求中的租户上下文。 在某些情况下，此过程要求在每个访问令牌中包含一个租户标识符，并在每个请求上对其进行验证。 在其他情况下，租户授权信息与用户标识分开存储。 此方法需要更复杂的授权系统来管理哪些用户可以在每个租户中执行特定作。

跟踪用户或令牌的租户上下文适用于任何 租户模型，因为在多租户解决方案中，用户身份始终具有租户上下文。 在为单个租户部署独立节点时，最好跟踪租户上下文，这样可以为未来适应其他形式的多租户做好准备。

将角色和资源授权混为一体

选择适合解决方案的授权模型非常重要。 基于角色的安全性易于实现，但基于资源的授权提供了更精细的控制。 评估租户的要求，并确定他们是否需要授权某些用户仅访问解决方案的特定部分。

未能写入审核日志

审核日志是了解环境以及用户如何实现系统的重要工具。 通过审核每个与标识相关的事件，通常可以确定标识系统是否受到攻击，并且可以查看系统的使用方式。 请确保在标识系统中编写和存储审核日志。 考虑解决方案的标识审核日志是否应提供给租户查看。

作者

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

其他参与者：

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