通过

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

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

  • 项目

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

注意

在开始为多租户解决方案构建标识系统之前，请查看多租户解决方案中标识的体系结构注意事项，详细了解关键要求和需要做出的决策。

身份验证

身份验证是用户标识建立的过程。 构建多租户解决方案时，需要特别注意身份验证过程的几个方面并且了解具体方法。

联合

可能需要与其他标识提供程序 (IdP) 联合。 联合可用于启用以下方案：

  • 社交账号登录，例如允许用户使用其 Google、Facebook、GitHub 或个人 Microsoft 帐户。
  • 特定于租户的目录，例如，允许租户将应用程序与其自己的标识提供程序联合，因此无需在多个位置管理帐户。

有关联合的一般信息，请参阅联合标识模式。

如果选择支持特定于租户的标识提供程序，请确保阐明需要支持哪些服务和协议。 例如，是否支持 OpenID 连接协议和安全断言标记语言 (SAML) 协议？ 或者，是否仅支持与 Microsoft Entra 实例联合？

实现任何标识提供程序时，请考虑应用的任何缩放和限制。 例如，如果使用 Azure Active Directory (Azure AD) B2C 作为自己的标识提供程序，则可能需要部署自定义策略与某些类型的租户标识提供程序联合。 Azure AD B2C 限制可以部署的自定义策略数，这可能限制可以与之联合的特定于租户的标识提供程序的数量。

还可以考虑提供联合身份验证作为仅适用于更高产品层的客户的功能。

单一登录

单一登录体验使用户能够无缝地在应用程序之间切换，而不会每次都提示用户重新验证。

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

在多租户解决方案中，还可以启用另一种形式的单一登录。 如果用户有权处理多个租户的数据，则当用户将上下文从一个租户更改为另一个租户时，可能需要提供无缝体验。 请考虑是否需要支持租户之间的无缝转换，如果是，则标识提供程序是否需要使用特定租户声明重新颁发令牌。 例如，登录到 Azure 门户的用户可以在导致重新身份验证的不同 Microsoft Entra 目录之间切换，并重新颁发所选的新 Microsoft Entra 实例中的令牌。

登录风险评估

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

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

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

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

或者，如果联合到租户自己的标识提供程序，则可以应用其自己的风险登录缓解策略，并且可以控制应强制执行的策略和控制。 但是，请务必避免无意中将不必要的负担添加到用户，例如需要两个 MFA 质询-一个来自用户的主标识提供程序和一个来自你自己的。 确保了解联合身份验证如何与每个租户的标识提供程序及其应用的策略进行交互。

模拟

模拟使用户能够假定其他用户的身份，而无需使用该用户的凭据。

一般来说，模拟是危险的，很难实现和控制。 但是，在某些情况下，模拟是一项要求。 例如，如果运行软件即服务 (SaaS)，则支持人员可能需要假定用户的标识，以便他们可以以用户身份登录并解决问题。

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

某些标识平台支持模拟，无论是作为内置功能，还是使用自定义代码。 例如，在 Azure AD B2C 中，可以为模拟用户 ID 添加自定义声明，也可以替换颁发令牌中的使用者标识符声明。

Authorization

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

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

  • 在标识提供程序。 例如，如果使用 Microsoft Entra ID 作为标识提供程序，则可以使用应用角色和组等功能来存储授权信息。 然后，应用程序可以使用关联的令牌声明来强制实施授权规则。
  • 在应用程序中。 可以生成自己的授权逻辑，然后存储有关每个用户在数据库或类似存储系统中可以执行的操作的信息。 然后，可以为基于角色或资源级别的授权设计精细控件。

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

有关详细信息，请参阅应用程序角色。

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

考虑解决方案的哪个部分或哪些部分应执行授权请求，包括确定是否允许用户处理来自特定租户的数据。

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

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

基于应用程序的授权

另一种方法是使标识系统与租户标识符和角色无关。 用户使用凭据或联合关系标识用户，令牌不包括租户标识符声明。 单独的列表或数据库包含哪些用户已授予对每个租户的访问权限。 然后，应用程序层可以查找该列表来验证是否应允许指定用户访问特定租户的数据。

使用 Microsoft Entra ID 或 Azure AD B2C

Microsoft 提供 Microsoft Entra ID、Microsoft Entra 外部 ID 和 Azure AD B2C，这些是可以在自己的多租户解决方案中使用的托管标识平台。

许多多租户解决方案是软件即服务 (SaaS)。 选择是使用 Microsoft Entra ID、Microsoft Entra External ID 还是 Azure AD B2C，部分取决于如何定义租户或客户群。

  • 如果租户或客户是组织，他们可能已经将 Microsoft Entra ID 用于 Office 365、Microsoft Teams或自己的 Azure 环境等服务。 可以在自己的 Microsoft Entra 目录中创建多租户应用程序，使解决方案可用于其他 Microsoft Entra 目录。 甚至可以在 Azure 市场中列出解决方案，并让使用 Microsoft Entra ID 的组织可以轻松访问该解决方案。
  • 如果你的租户或客户不使用 Microsoft Entra ID，或者他们是个人而不是组织，请考虑使用 Microsoft Entra 外部 ID 或 Azure AD B2C。 Microsoft Entra 外部 ID 和 Azure AD B2C 都提供了一组功能来控制用户注册和登录的方式。 例如，可以仅对已邀请的用户限制对解决方案的访问，也可以允许自助注册。 使用 Azure AD B2C 中的自定义策略完全控制用户与标识平台的交互方式。 可以使用自定义品牌，并且可以将 Azure AD B2C 与你自己的 Microsoft Entra 租户联合，使你自己的员工能够登录。 Azure AD B2C 还支持与其他标识提供程序合。
  • 某些多租户解决方案适用于以上两种。 某些租户可能有自己的 Microsoft Entra 租户，而另一些租户可能没有。 还可以为此方案使用 Azure AD B2C，并使用 自定义策略允许用户从租户的 Microsoft Entra 目录登录。 但是，如果使用自定义策略在租户之间建立联合，请确保考虑单个 Azure AD B2C 目录可以使用的自定义策略数量限制。

有关详细信息，请参阅在多租户体系结构中使用 Azure Active Directory B2C 的注意事项。

要避免的反模式

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

构建新式标识平台很复杂。 需要支持一系列协议和标准，很容易错误地实现协议并公开安全漏洞。 标准和协议发生更改，还需要不断更新标识系统，以缓解攻击和支持最近的安全功能。 此外，请务必确保标识系统具有复原能力，因为任何停机时间都可能会对解决方案的其余部分产生严重后果。 此外，在大多数情况下，执行标识提供程序不会为业务添加权益，而这只是实现多租户服务的必要部分。 最好改用由专家构建、运营和保护的专用标识系统。

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

运行标识系统时，还负责生成和分发 MFA 或一次性密码 (OTP) 代码。 然后，这些要求意味着你需要一种机制来分发这些代码，方法是使用短信或电子邮件。 此外，你负责检测目标攻击和暴力攻击、限制登录尝试、审核等。

最好使用现成的服务或组件，而不是生成或运行自己的标识系统。 例如，请考虑使用 Microsoft Entra ID 或 Azure AD B2C（托管标识平台）。 托管标识平台供应商负责为其平台运营基础结构，通常支持当前的标识和身份验证标准。

未能考虑租户的要求

租户通常对标识如何管理其使用的解决方案有强烈意见。 例如，许多企业客户需要与自己的标识提供程序联合，才能启用单一登录体验，并避免管理多个凭据集。 其他租户可能需要多重身份验证，或者有关登录过程的其他保护形式。 如果尚未针对这些要求进行设计，以后对其进行改造可能很困难。

在完成标识系统的设计之前，请确保了解租户的标识要求。 查看多租户解决方案中标识的体系结构注意事项，以了解经常出现的一些特定要求。

将用户和租户串联在一起

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

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

跟踪用户或令牌的租户上下文适用于任何租户模型，因为用户标识始终在多租户解决方案中具有租户上下文。 在为单个租户部署独立标记时，跟踪租户上下文甚至是最好的做法，这将为其他类型的多租户证明代码库。

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

请务必为解决方案选择适当的授权模型。 基于角色的安全方法可以简单实现，但基于资源的授权提供了更精细的控制。 考虑租户的要求，以及租户是否需要授权某些用户访问解决方案的特定部分，而不是其他部分。

未能写入审核日志

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

作者

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

主要作者：

其他参与者：

后续步骤

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