Azure 上 SaaS 工作负载的标识和访问管理

应用程序标识是 SaaS 工作负载的关键区域，因为它充当保护数据的第一道防线。 在项目后期，它通常被忽视，但有关应用程序的其他元素的许多决策都依赖于坚实的标识策略。 不要低估标识在帮助保护客户数据方面的重要性。

在 SaaS 工作负载的上下文中，有两种不同的标识类型。

• 应用程序标识（也称为 客户标识和访问管理（CIAM）使最终用户能够进行身份验证并使用 SaaS 应用程序。 将用户登录到应用程序标识提供者有两种主要方法：

  • 联合标识。 用户使用由另一个标识提供者维护的现有凭据登录。 该提供商可以是社交标识提供者（如 Google、Facebook 或 LinkedIn），也可以是客户使用的企业标识提供者，例如Microsoft Entra 或 Okta。 维护用户的帐户由联合标识提供者负责。

  • 本地标识。 用户仅为应用程序创建帐户。 该帐户受用户名和密码、密码或其他身份验证方法保护。 维护用户帐户是你的责任。

• 企业标识 是用于向企业生产力工具、内部工具或服务和 Azure 服务验证内部用户和工作负载的标识解决方案。 为内部用户和工作负载使用企业标识解决方案向业务生产力工具、内部工具或服务和 Azure 服务进行身份验证。

  请参阅 SE：05 标识和访问管理。

应用程序和企业标识用于不同的目的，并可能使用不同的标识提供者。 本文重点介绍应用程序标识的设计注意事项，尽管这两种类型可能都存在于 SaaS 工作负荷环境中。

标识管理涉及两个相关问题：身份验证（验证用户的标识）和授权（基于标识授予权限）。 本文的前三部分重点介绍 SaaS 的身份验证。 最后一部分介绍 SaaS 提供程序的授权注意事项。

多租户应用程序中的标识

使租户数据在多租户应用程序中保持独立至关重要。 这种分段由你选择有效的用户身份验证和授权驱动。 此外，租赁模型的选择严重影响了有关标识提供者的决定。 将标识确定为主要外围的优先级。

请参阅 SE：04 分段建议。

设计注意事项

了解应用程序的租户和部署模型。 可能存在影响标识策略的细微差别。 例如，部署戳模式需要每个标记中的标识提供者，这是一种误解。 对于大多数标识提供者，通常可以使用备用隔离模型。

为多租户选择标识提供者时，评估故障的影响。 配置不当可能会降低所有租户的整个应用程序。 根据潜在影响半径的风险来权衡开销成本。

如果将解决方案部署到客户的 Azure 环境中并代表其管理解决方案，则可能需要与其企业标识提供者集成。 请清楚地了解以下方面：

• 用户与应用程序租户交互时所需的用户类型及其访问需求。 例如，用户 A 可能只需要登录租户 1 的访问权限，但用户 B 可能需要访问租户 1 和租户 2。
• 符合数据驻留法规（如果它们适用于你的标识提供者）。 在某些情况下，标识提供者存储的数据可能受到法规的约束。 许多标识提供者为此方案提供特定的指导和功能。 评估此方案是否与你相关，并采取必要的步骤来确保合规性。

设计建议

标识提供者选项

每个标识提供者都提供独特的功能、限制、定价模型和实现模式。 Microsoft Entra 和 Okta 是常用标识即服务（IDaaS）选项。 还有其他开放源代码提供程序，例如 Keycloak 和 Authentik。

设计注意事项

• 记录标识要求。 首先列出应用程序现在需要的功能，将来将需要这些功能。 要考虑的典型功能包括：

• • 联合标识提供者支持以与客户的标识解决方案集成。 使用此功能，可以避免创建新标识。
  • 可自定义的登录/注册流，用于修改外观以维护品牌。 此功能还提供将自定义业务逻辑注入登录/注册过程的功能。
  • 将租户数据分离为不同的孤岛，以保持租户隔离。
  • 审核支持以保留或导出用于安全管理的登录日志。

  重要

  评估标识解决方案的成本时，请考虑规划的用户增长。 解决方案可能长期不具有成本效益或可缩放性，但目前可能很有用。 需要时可以使用的迁移计划。

  例如，500 个用户可能负担得起解决方案，但 500 万用户不可持续。 如果它需要最少的设置且易于从中迁移，则它仍然是正确的选择，直到缩放成本证明切换到其他解决方案是正当的。

• 彻底研究标识提供者功能。 确保标识解决方案与所需功能列表匹配。 即使当前不需要复杂的方案（如联合标识），请考虑将来的需求。 对于企业到企业（B2B）SaaS 解决方案，最终可能需要联合标识。

• 考虑管理开销。 不同的标识提供者需要不同级别的管理开销。 众所周知的 IDaaS 解决方案通常开销较低，因为它们处理托管、维护和安全性。 但是，如果解决方案更适合你的专用需求，则开放源代码解决方案的额外开销可能值得。

设计建议

联合标识

联合标识（也称为 单一登录（SSO）允许用户使用已在其他位置使用的凭据登录。 可以通过在应用程序标识提供者与客户的现有标识提供者之间建立信任关系来启用联合标识。 联合标识是 SaaS 解决方案的常见要求，尤其是在 B2B 中，因为客户更喜欢员工使用公司凭据。 它为 B2B 解决方案提供了多项优势，例如集中式标识管理和自动生命周期管理。 在 B2C SaaS 产品中，与社交标识提供者集成很常见，允许用户使用现有凭据登录。

权衡：复杂性和运营效率。 通过使用联合标识提供者，可以卸载管理用户标识的复杂性。 但是，需要承担与另一个标识提供者集成的成本。 确定要专注于运营工作的位置。

虽然实现联合标识最初很简单，但随着支持的标识提供者的数量的增加，它变得更加复杂。 仔细规划至关重要，尤其是在每个客户使用唯一标识提供者时。 即使他们使用相同的标识提供者，由于特定的配置详细信息，每个客户通常需要唯一信任关系。

此图显示了应用程序、应用程序标识提供者和下游标识提供者之间的关系，你可能选择使用联合身份验证实现这些标识提供者。

设计注意事项

• 估计需要支持的标识提供者的类型和数量。 可能需要静态数量的社交标识提供者，或者可能需要每个客户的唯一联合标识提供者。 你应该知道客户是使用 OpenID Connect（OIDC）、安全断言标记语言（SAML）还是两者进行集成。

• 映射登录体验。 可视化注册和登录过程的用户流。 请注意可能会更改用户流设计的任何特殊要求。 例如：

  • 自定义品牌。 每个客户的白标签或自定义登录域。

  • 自定义信息。 在注册或登录期间收集其他用户信息，例如，有权访问多个租户的用户选择租户。

  • 标识提供者选择。 如果使用具有许多联合标识提供者信任它的单个应用程序标识提供者，请决定如何选择提供程序。 此选择可能通过按钮手动完成，也可以根据已知用户信息自动完成。 随着提供商数量的增加，自动选择变得更加实用。 此功能称为 主领域发现。

设计建议

授权

用户授权对于 SaaS 应用程序至关重要，后者通常存储多个租户的数据。 明确定义如何授权用户仅访问其数据，而不会无意中访问其他租户的数据。 此外，在租户中提供精细授权，允许用户读取或访问某些信息，同时限制更新或访问其他数据。

设计注意事项

• 为用例选择正确的授权模型。 有两种主要类型：

  • 基于角色的授权。 用户分配了角色或组，特定功能仅限于某些角色。 例如，管理员可以执行任何操作，但其他角色中的用户具有有限的权限。
  • 基于资源的授权。 每个资源都有自己的权限集。 用户可能是一个资源的管理员，但无权访问另一个资源。

• 确定在何处存储授权数据。 应用程序的授权数据可以存储在以下项中：

  • 标识提供者。 利用内置组或角色，将权限作为颁发给应用程序的令牌中的声明显示。 然后，应用程序可以使用这些令牌声明来强制实施授权规则。
  • 你的应用程序。 开发自己的授权逻辑，并将用户权限存储在数据库或类似系统中，从而实现基于角色的细化或资源级授权控制。

  权衡：复杂性、灵活性和安全性。 在标识提供者中存储授权数据并通过令牌声明显示通常比管理自己的授权系统更简单。 但是，基于声明的授权限制了灵活性，并且你需要接受声明仅在重新颁发令牌时刷新，这可能会导致应用更改的权限延迟。

• 评估委派管理的影响。 在大多数 SaaS 应用程序中，尤其是在 B2B 应用程序中，角色和权限管理将委托给客户。 如果没有此功能，如果客户经常更改其用户的权限，则可能会增加管理开销。

• 评估多租户访问。 在某些系统中，单个用户可能需要访问来自多个租户的数据。 例如，顾问可能需要访问来自多个租户的数据。 规划客户如何授予对这些用户的访问权限，以及登录流如何支持在租户之间进行选择和切换。

设计建议

其他资源

多租户是设计 SaaS 工作负载的核心业务方法。 以下文章提供有关标识和访问管理的详细信息：

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

下一步

了解如何选择计算托管模型、操作方面以及如何优化技术选项，以帮助满足服务级别协议和目标。