你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
标识对于任何多租户解决方案来说都很重要。 应用程序的标识组件负责以下任务：
验证用户的标识，称为 身份验证
在租户范围内强制实施用户的权限，称为 授权
客户可能还希望授权外部应用程序访问其数据或与解决方案集成。 用户的标识确定用户或服务可以访问哪些信息。 请务必考虑标识要求，以便在租户之间隔离应用程序和数据。
注意
多租户和软件即服务（SaaS）应用程序中的身份验证和授权服务通常由外部标识提供者（IdP）提供。 IdP 通常是托管标识平台不可或缺的一部分。
构建自己的 IdP 非常复杂、昂贵且难以确保安全。 它被认为是 反模式，我们不建议它。
在定义多租户标识策略之前，请先考虑以下服务的高级标识要求：
确定用户或 工作负荷标识 是访问产品系列中的单个应用程序还是多个应用程序。 某些产品系列可能包括共享相同标识基础结构的不同应用程序，例如销售点系统和库存管理平台。
请考虑解决方案是否实现新式身份验证和授权标准，例如 OAuth2 和 OpenID Connect。
评估身份验证是否仅限于基于 UI 的应用程序，或者 API 访问是否也适用于租户和第三方系统。
确定租户是否需要与自己的 IdP 对接，以及每个租户是否需要支持多个 IdP。 例如，你可能有包含 Microsoft Entra ID、Auth0 和 Active Directory 联合服务的租户，其中每个租户都与您的解决方案联合。 确定其 IdP 使用的联合协议，因为这些协议确定 IdP 必须支持哪些协议。
审查需要满足的任何适用的合规要求，例如 通用数据保护条例（GDPR） 之类的法规，这些法规会影响您的身份策略。
确定租户是否需要在特定地理区域中存储标识数据，以满足法律、合规性或运营需求。
评估用户是否访问应用程序中多个租户的数据。 如果这样做，可能需要支持无缝租户切换，或者为特定用户提供租户之间的合并视图。 例如，登录到 Azure 门户的用户可以轻松地在他们有权访问的不同Microsoft Entra ID 目录和订阅之间切换。
建立高级别要求时，可以开始规划更具体的详细信息和要求，例如用户目录源和注册和登录流。
标识目录
若要使多租户解决方案对用户或服务进行身份验证和授权，需要一个存储标识信息的位置。 目录可以包含每个标识的权威记录。 或者，它可能包含对存储在另一 IdP 目录中的外部标识的引用。
为多租户解决方案设计标识系统时，需要考虑租户和客户可能需要的以下 IDP 类型之一：
本地 IdP： 本地 IdP 允许用户自行注册服务。 用户提供用户名、电子邮件地址或标识符，例如奖励卡号。 它们还提供凭据，例如密码。 IdP 存储用户标识符和凭据。
社交 IdP： 社交 IdP 允许用户使用他们在社交网络或其他公共 IdP（如 Facebook、Google 或个人Microsoft帐户）上拥有的标识。 社交 IdP 通常用于企业到消费者 (B2C) SaaS 解决方案。
租户的Microsoft Entra ID 目录： 在许多企业到企业（B2B）SaaS 解决方案中，租户可能已经有自己的Microsoft Entra ID 目录，他们可能希望解决方案将其目录用作用于访问解决方案的 IdP。 当解决方案构建为 多租户Microsoft Entra 应用程序时，可能会采用此方法。
与租户的 IdP 联合： 在某些 B2B SaaS 解决方案中，租户可能有自己的 IdP，而不是Microsoft Entra ID，他们可能希望你的解决方案与其联合。 联合启用单一登录 (SSO)。 它还使租户能够独立于解决方案管理其用户的生命周期和安全策略。
您应考虑租户是否需要支持多个 IdP。 例如，单个租户可能需要支持本地标识、社交标识和联合标识。 当公司使用面向员工和承包商的解决方案时，这一要求很典型。 他们可以使用联合身份验证授予员工访问权限，同时允许未在联合 IdP 中拥有帐户的承包商或用户进行访问。
存储身份验证和租户授权信息
在多租户解决方案中，需要考虑存储多种标识信息的位置，包括以下类型：
有关用户和服务帐户的详细信息，包括其名称和租户所需的其他信息。
安全验证用户所需的信息，包括多重身份验证（MFA）相关的信息。
用于授权的租户特定信息，例如租户角色和权限。
注意
我们不建议自己生成身份验证过程。 新式 IdP 为应用程序提供这些身份验证服务，并且还包括其他重要功能，例如 MFA 和条件访问。 构建自己的标识提供者是一种反模式。 但我们不建议这样做。
请考虑以下用于存储标识信息的选项：
把所有标识和授权信息存储在 IdP 目录中，并在多个租户之间共享。
将用户凭据存储在 IdP 目录中。 在应用程序层中存储授权数据以及租户信息。
确定用户的标识数
多租户解决方案通常允许用户或工作负荷标识跨多个租户访问应用程序资源和数据。 如果需要此方法，请考虑以下因素：
决定是为每个人员创建单个用户标识，还是为每个租户用户组合创建单独的标识。
尽可能对每个人使用单个标识。 它简化了解决方案提供商和用户的帐户管理。 此外，新式 IdP 提供的许多智能威胁防护依赖于拥有单个用户帐户的每个人。
在某些情况下使用多个不同的标识。 例如，如果人们同时使用你的系统进行工作和个人目的，他们可能需要将用户帐户分开。 或者，如果你的租户有严格的法规或地理数据存储要求，他们可能需要一个人拥有多个标识，以便他们可以遵守法规或法律。
如果使用每租户标识，请避免多次存储凭据。 用户的凭据应该与单一标识关联存储，您应该使用例如来宾身份这样的功能来从多个租户的身份记录中引用同一用户凭据。
向用户授予对租户数据的访问权限
考虑如何将用户映射到租户。 例如，在注册过程中，可以为用户提供唯一的邀请代码，以便在用户首次访问租户时输入。 在某些解决方案中，用户的注册电子邮件地址的域名可以标识其关联的租户。 或者，可以使用用户标识记录中的另一个属性来确定租户映射。 然后，应根据租户和用户不可变的唯一标识符存储此关联。
如果解决方案限制每个用户访问单个租户的数据，请考虑以下决策：
确定 IdP 如何检测用户访问的租户。
说明 IdP 如何将租户标识符传达给应用程序。 通常，租户标识符声明将添加到令牌中。
如果需要向单个用户授予对多个租户的访问权限，请考虑以下决策：
解决方案必须支持用于标识用户并跨租户授予适当权限的逻辑。 例如，用户可能在一个租户中拥有管理权限，但在另一个租户中具有有限的访问权限。 例如，假设用户注册了社交标识，然后被授予对两个租户的访问权限。 租户 A 扩充了用户标识的详细信息。 租户 B 是否有权访问扩充信息？
明确的机制应允许用户在租户之间切换。 此方法可确保用户体验流畅，并防止意外的跨租户访问。
如果使用工作负载标识，则必须指定它们尝试访问的租户。 此要求可能包括在身份验证请求中嵌入特定于租户的上下文。
考虑用户标识记录中存储的特定于租户的信息是否可能在租户之间无意中泄露。 例如，如果用户使用社交标识注册并获取对两个租户的访问权限，而租户 A 会扩充用户配置文件，则确定租户 B 是否应有权访问该扩充信息。
本地标识或社交标识的用户注册过程
某些租户可能需要允许用户在您的系统中自主注册身份。 如果你不需要与租户的 IdP 联合，则可能需要自助注册。 如果需要自注册过程，应考虑以下因素：
定义允许用户注册的身份来源。 例如，确定用户是否可以创建本地标识并使用社交 IdP。
指定在使用本地标识时，解决方案是否仅允许特定的电子邮件域。 例如，确定租户是否可以将注册限制为具有
@contoso.com电子邮件地址的用户。必须明确建立用于标识本地标识的用户主体名称（UPN）。 常见的 UPN 包括电子邮件地址、用户名、电话号码或成员身份标识符。 由于 UPN 可以更改，因此建议引用用于授权和审核的基础不可变唯一标识符。 例如，Microsoft Entra ID 中的对象 ID （OID）。
可能需要验证 UPN 以确保其准确性。 此过程可能包括在授予访问权限之前验证电子邮件地址或电话号码的所有权。
某些解决方案可能需要租户管理员批准用户注册。 此审批过程允许对加入租户的人员进行管理控制。
确定租户是否需要特定于租户的注册体验或特定的 URL。 例如，确定租户在用户注册时是否需要品牌化的注册体验，或者是否能够截获注册请求并在继续之前进行额外的验证。
自注册用户的租户访问权限
如果用户可以自行注册标识，请定义一个流程，以授予他们对租户的访问权限。 注册流可能包括手动访问授权过程或基于有关用户的信息（例如其电子邮件地址）的自动化过程。 规划此过程并考虑以下因素非常重要：
定义注册流如何确定用户有权访问特定租户。
定义解决方案是否在适当时自动撤销对租户的用户访问权限。 例如，当用户离开组织时，应该有一个手动或自动化的过程来删除其访问权限。
提供用户审核功能，以便租户可以查看哪些用户有权访问其环境并了解其分配的权限。
自动化帐户生命周期管理
解决方案企业或企业客户的常见要求是一组功能，允许他们自动进行帐户载入和卸载。 开放协议（例如 跨域标识管理系统（SCIM）提供了一种行业标准的自动化方法。 此自动化过程通常包括创建和删除标识记录以及租户权限的管理。 在多租户解决方案中实现自动化帐户生命周期管理时，请考虑以下因素：
确定客户是否需要为每个租户配置和管理自动化生命周期过程。 例如，当用户加入时，可能需要在应用程序中的多个租户中创建标识，其中每个租户都有一组不同的权限。
确定是否需要实现 SCIM 或提供联合。 联合允许租户通过在自己的系统中保留事实来源，而不是在解决方案中管理本地用户来保留对用户管理的控制。
用户身份验证过程
当用户登录到多租户应用程序时，标识系统对用户进行身份验证。 规划身份验证过程时，请考虑以下因素：
某些租户可能需要配置其自己的 MFA 策略。 例如，如果你的租户位于金融服务行业，则需要实施严格的 MFA 策略，而一家小型在线零售商可能没有相同的要求。
定义自定义条件访问规则的选项对于租户来说可能很重要。 例如，不同的租户可能需要阻止来自特定地理区域的登录尝试。
确定租户是否需要单独自定义登录过程。 例如，解决方案可能需要显示客户的徽标。 或者，它可能需要从另一个系统检索用户信息（如奖励号码），并将其返回到 IdP 以扩充用户配置文件。
某些用户可能需要模拟其他用户。 例如，支持团队成员可能希望通过模拟另一个用户的帐户来调查问题，而无需以该用户身份进行身份验证。
某些用户或外部应用程序可能需要 API 访问。 这些方案可能包括直接调用解决方案的 API，从而绕过标准用户身份验证流。
工作负载标识
在大多数解决方案中，标识通常表示用户。 某些多租户系统还允许服务和应用程序使用工作负荷标识来访问应用程序资源。 例如，租户可能需要访问解决方案提供的 API，以便他们可以自动执行其管理任务。
Microsoft Entra 支持工作负荷标识，其他身份提供商通常也支持它们。
工作负载标识类似于用户标识，但通常需要不同的身份验证方法，例如密钥或证书。 工作负载标识不使用 MFA。 相反，工作负载身份通常需要其他安全控制，例如定期的密钥轮换和证书过期管理。
如果租户可以启用对您的多租户解决方案的工作负荷标识访问，则应考虑以下因素：
确定如何在每个租户中创建和管理工作负荷标识。
决定如何将工作负荷身份请求的范围如何限定为租户。
评估是否需要限制每个租户创建的工作负荷标识数。
确定每个租户中的工作负载身份是否需要条件访问控制。 例如，租户可能需要限制从特定区域外部进行身份验证的工作负载标识。
确定向租户提供哪些安全控制，以确保工作负荷标识保持安全。 例如，自动密钥滚动、密钥过期、证书过期和登录风险监视有助于降低工作负载标识滥用的风险。
与 IdP 联合实现 SSO
已拥有自己的用户目录的租户可能希望解决方案联合到其目录。 联合允许解决方案在其目录中使用标识，而不是使用不同的标识管理另一个目录。
当某些租户想要指定自己的标识策略或启用 SSO 体验时，联合尤其重要。
如果希望租户与解决方案联合，请考虑以下因素：
考虑为租户配置联合身份验证的过程。 确定租户是否自行配置联合身份验证，或者该过程是否需要由您的团队手动进行配置和维护。
定义解决方案支持的联合协议。
建立防止因联合配置错误而导致对非预期租户授予访问权限的流程。
请规划是否需要将单个租户的 IdP 与解决方案中的多个租户进行联合身份验证。 例如，如果客户同时拥有培训和生产租户，则可能需要将同一 IdP 联合到每个租户。
授权模型
确定最适合解决方案的授权模型。 请考虑以下常见授权方法：
基于角色的授权： 将用户分配到角色。 应用程序的一些功能仅限于特定角色。 例如，管理员角色中的用户可以执行任何操作，而角色较低的用户在整个系统中可能具有一部分权限。
基于资源的授权： 解决方案提供一组不同的资源，每个资源都有自己的权限集。 特定用户可能是一个资源的管理员，并且无权访问另一个资源。
这些模型是不同的，你选择的方法会影响实现和可以实现的授权策略的复杂性。
权利和许可
在某些解决方案中，可以将每用户授权用作商业定价模型的一部分。 在此方案中，提供具有不同功能的不同用户许可证层。 例如，允许具有一个许可证的用户使用应用程序的一部分功能。 特定用户根据许可证访问的功能有时称为权利。
应用程序代码或专用权利系统通常跟踪并强制实施权利，而不是标识系统。 此过程类似于授权，但在标识管理层外部发生。
标识缩放和身份验证卷
随着多租户解决方案的增长，解决方案需要处理的用户数和登录请求数也会增加。 请考虑下列因素：
评估用户目录是否缩放以支持所需的用户数。
评估身份验证过程是否能够处理预期的登录和注册次数。
确定身份验证系统无法处理的峰值。 例如，在太平洋时间上午 9 点，美国西部的每个人都可能会开始工作并登录到解决方案，这会产生登录请求激增。 这些场景有时称为 登录风暴。
确定解决方案中部分的高负载是否影响身份验证过程的性能。 例如，如果身份验证需要调用应用程序层 API，身份验证请求激增可能会影响系统的整体性能。
定义当 IdP 不可用时解决方案的行为方式。 考虑是否应包括备份身份验证服务，以保持业务连续性。
贡献者
Microsoft维护本文。 以下参与者撰写了本文。
主要作者：
- John Downs |Azure 模式和做法的主要软件工程师
- Daniel Scott-Raynsford | 高级合作伙伴技术解决方案顾问
- Arsen Vladimirskiy | 首席工程师，FastTrack for Azure
其他参与者：
- Jelle Druyts | 首席工程师，FastTrack for Azure
- Landon Pierce | 高级客户工程师
- Sander van den Hoven | 高级合作伙伴技术策略师
- Nick Ward | 高级云解决方案架构师
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。