身份联合的架构模式

本文档比较了四种将 Google Cloud与外部身份提供方 (IdP) 联合的架构模式。本文档还提供了相关指南，帮助您为自己的使用场景选择合适的架构。

四种架构模式如下：

决策因素

如需选择适合您组织的架构模式，请考虑多种因素，包括：

  • 服务组合：您的 Google 服务组合，以及是否包含 Google Workspace 和Google Cloud以外的服务，例如 Google Ads、Google 地图或 Chrome 企业版。
  • 数据驻留：您的数据驻留和主权要求。
  • Gemini Enterprise 与 Microsoft 365 集成：您对 Gemini Enterprise 或 NotebookLM Enterprise 的使用情况，以及您是否计划将 Gemini Enterprise 与 Microsoft 365 服务集成。

服务组合

Google 服务以不同的方式管理身份验证和授权。这会影响您配置身份联合的方式。这些差异取决于两个因素：服务模型（SaaS 与 PaaS 和 IaaS）和授权模型（IAM 与特定于服务的模型）。

服务模式

  • 软件即服务 (SaaS)：Google 全面管理 Gmail、Google Ads 或 Gemini Enterprise 应用等服务。这些服务无需开发工作，可直接使用。由于 SaaS 服务面向的是广泛的受众群体，因此您的大多数用户可能都需要访问这些服务。
  • 平台即服务 (PaaS) 或基础架构即服务 (IaaS)：大多数Google Cloud 服务都是 PaaS 或 IaaS。借助这些服务，技术用户可以开发、部署和运行自定义工作负载。由于这些服务面向的是技术受众群体，因此只有部分用户需要访问权限。

授权模型

Google 服务通过以下两种方式之一实现授权：

  • IAM：大多数 Google Cloud 服务都使用 IAM 来让管理员管理对资源的精细访问权限。
  • 特定于服务的授权：Google Ads、Looker 或 Google Workspace 等服务不使用 IAM。而是要使用特定于每项服务的工具来管理访问权限。

这些因素导致了以下服务组：

SaaS PaaS 或 IaaS
基于 IAM 的授权 Google Cloud Gemini Enterprise 应用和 NotebookLM Enterprise 等 SaaS 服务 Google Cloud PaaS 和 IaaS 服务，例如 BigQuery 或 Compute Engine
特定于服务的授权 非云 Google 服务，例如 Google Ads、Google Workspace 和 Google 地图 无

如需选择适合您组织的架构模式，请考虑哪些服务组适用于您的组织。

数据驻留

为了对用户进行身份验证和管理会话，Cloud Identity、Google Workspace 和员工身份联合会处理用户的个人信息。这些用户信息可能包括：

  • 用户名或电子邮件地址
  • 用户属性，例如名字和姓氏
  • 群组名称和成员

Cloud Identity、Google Workspace 和员工身份联合会根据服务数据的条款处理这些数据，并且可能会将其存储在您组织或用户所在位置之外的其他位置：

  • Cloud Identity 和 Google Workspace 会将服务数据存储在 Google 数据中心，并且可能会在所有数据中心复制这些数据。存储的数据可能包含对身份验证而言并非必要的信息，例如部门名称、地址或手机号码。
  • 工作负载身份联合会在 Google Cloud区域中存储服务数据，并可能会跨所有区域复制这些数据。

如果您向用户授予对资源的访问权限，IAM 会将该用户的主账号标识符存储在角色绑定中。 Google Cloud 会根据服务数据的条款处理角色绑定，并可能会将其存储在所有 Google Cloud 区域中。

本页中描述的架构模式需要存储用户信息，但它们在存储用户信息的时间长短方面有所不同：

许多 IdP 都允许您在 IdP 中相应用户账号的状态发生变化时，自动暂停或删除用户账号。根据您的 IdP 及其配置，IdP 可能会延迟删除用户账号，直到宽限期结束，这可能会延长 Google Cloud存储相应用户信息的时长。

Gemini Enterprise 与 Microsoft 365 集成

Gemini Enterprise 可让您使用以下两种类型的连接器连接到 Microsoft 365 服务：

  • 基于数据提取的连接器：这些连接器会抓取 Microsoft 365 来在 Google Cloud中构建搜索索引。当用户提交提示时，Gemini Enterprise 会使用此索引来搜索内容，并通过评估从 Microsoft 365 获取的访问控制列表 (ACL) 在本地执行访问权限检查。
  • 联合连接器：这些连接器会针对每个提示查询 Microsoft 365。它们使用委托授权，让 Microsoft 365 直接执行访问权限检查。

基于数据注入的连接器对用户联盟提出了特定要求：

  • 群组成员资格感知：Microsoft 365 ACL 可以包含群组和用户的条目。为了评估用户是否可以访问内容，连接器必须考虑用户所属的所有群组。如果连接器仅知道用户的部分群组，则可能会错误地允许或拒绝访问。
  • 标识符转换：为了评估 ACL，连接器必须在 Microsoft 365 使用的用户和群组标识符与 Google Cloud使用的标识符之间进行转换。

使用员工身份联合时，如果您配置的属性映射与 Gemini Enterprise 兼容，Gemini Enterprise 就可以可靠地转换标识符并评估 ACL。

使用 Cloud Identity 或 Google Workspace 联合身份验证时，Microsoft Entra ID 会控制用户和群组预配的属性映射，而不是 Google Cloud。Entra 会确定用户和群组标识符的转换规则，这可能涉及复杂的转换。为了评估 ACL，Gemini Enterprise 连接器必须应用相同的转换规则，但该连接器无法了解 Entra 配置。因此，当您使用 Cloud Identity 联合或 Google Workspace 联合时，Gemini Enterprise 无法可靠地转换用户和群组标识符，也无法可靠地评估 ACL。

如需确定哪种架构模式适合您的组织，请考虑您对 Gemini Enterprise 的使用情况，以及您是否计划使用基于数据提取的连接器。

架构模式

以下流程图展示了这些因素如何决定哪种模式符合组织的要求：

显示如何选择身份联合模式的流程图。

  1. 贵组织中有很大一部分用户使用 Google Workspace 吗？

  2. 您是否使用 Google Cloud 以外的服务，例如 Google Ads 或 Google 地图？

    • 如果答案为是，请继续做出决策 3。
    • 如果为否，请继续执行决策 4。

  3. 您是否计划使用 Gemini Enterprise 并将其与 Microsoft 365 集成？

  4. 您是否打算使用 Gemini Enterprise？

  5. 您是否需要遵守数据驻留要求，从而需要尽量减少 用户信息的存储？

Cloud Identity 或 Google Workspace 联合

如果您的组织符合以下条件之一，请选择此模式：

  • 贵组织中有很大一部分人已在使用 Google Workspace。
  • 您使用的 Google 服务除了 Google Cloud 之外，还包括 Google Ads 或 Google 地图等，但您不打算使用基于数据注入的连接器将 Gemini Enterprise 与 Microsoft 365 集成。
  • 您只使用 Google Cloud 服务，不打算使用 Gemini Enterprise，并且没有严格的数据留存要求，因此可以尽量减少用户数据存储。

在此模式下，您不使用员工身份联合。您可以将 Cloud Identity 账号或 Google Workspace 账号与 IdP 联合，并使用预先用户配置和群组配置。

Cloud Identity 和 Google Workspace 联合身份验证的架构。

在这种模式下，您必须先预配用户和群组，然后用户才能登录；否则，用户的登录尝试会失败：

  • 用户配置：有助于确保及时为用户完成新手入门和离职流程。
  • 群组配置：可让您使用群组来管理对 Google 服务和 Google Cloud 资源的访问权限。

如果贵组织只有一部分用户需要 Google Workspace，请为您的账号同时添加 Google Workspace 订阅和 Cloud Identity 订阅，然后仅向需要 Google Workspace 的用户分配 Google Workspace 许可。

福利

  • 无论 Google 服务是否使用 IAM，用户都可以向这些服务进行身份验证。在 Cloud Identity 账号或 Google Workspace 账号中，控制允许用户使用哪些 Google 服务。
  • 您可以将单点登录 (SSO) 和预先配置限制为仅适用于部分用户，并继续在 Cloud Identity 或 Google Workspace 中直接管理特定用户，例如紧急访问用户。
  • 您可以从外部 IdP 预配群组，在 Cloud Identity 账号或 Google Workspace 账号中本地管理群组，也可以将这两种方法结合使用。

限制

  • 提前配置用户账号会增加开销，并且这种配置可能会减慢初始配置流程。

  • 您无法控制或限制 Cloud Identity 或 Google Workspace 用于存储用户数据和群组数据的位置。由于 Google 会根据服务数据条款处理和存储用户数据和群组数据，因此数据区域控制功能不适用于这些数据，并且 Google 可能会在Google 数据中心位置之间复制这些数据。

  • 当您使用 Cloud Identity 联合或 Google Workspace 联合时，Gemini Enterprise 对连接到 Microsoft 数据源的支持有限。

员工身份联合（无需同步）

如果您的组织符合以下条件，请选择此模式：

  • 您仅使用 Google Cloud 服务。
  • 您使用的是 Gemini Enterprise，但希望遵守 IdP 施加的群组限制。
  • 您有数据驻留要求，需要尽量减少个人用户信息的存储。

员工身份联合的架构，无需同步。

在此模式下，您可以使用员工身份联合将Google Cloud 组织与外部 IdP 进行联合。

此模式不需要用户配置或群组配置。每次用户登录时，IdP 都会将有关用户的必要信息（包括群组成员资格和自定义属性）传递给 Google Cloud，并且 Google Cloud 仅在用户会话期间保留该信息。

福利

  • 您无需在Google Cloud中存储或管理用户账号或群组。
  • 借助此模式，您可以使用基于数据注入的连接器将 Gemini Enterprise 与 Microsoft 365 集成。

限制

  • 员工身份联合是一项 IAM 功能，仅允许用户访问使用 IAM 的服务。使用 Workforce Identity Federation 进行身份验证的用户无法访问 Google 服务，例如 Google Ads、Looker 或 Google Marketing Platform。
  • 使用员工身份联合进行身份验证的用户无法访问某些 Google Cloud 功能。如需了解详情，请参阅身份联合：产品和限制。
  • 许多 IdP 会限制其在 SAML 断言或 ID 令牌中可以传递给员工身份联合的群组成员资格数量。为了不超过这些限制，您可能需要加强群组治理，并限制断言或令牌中可包含的群组类型。
  • 分享 NotebookLM Enterprise 笔记本等资源时，您无法按名称查找群组。用户必须手动输入其标识符。

如果您使用 Microsoft Entra ID，可以通过配置额外属性来使用此模式的变体。配置额外属性时，员工身份联合会在用户身份验证期间执行对 Microsoft Graph API 的回调，以检索群组成员资格。通过此配置，您可以克服 Entra 对 SAML 断言和 ID 令牌的群组成员资格限制，并为每位用户使用最多 999 个群组成员资格。

使用 SCIM 的员工身份联合

如果您的组织符合以下条件，请选择此模式：

  • 您仅使用 Google Cloud 服务。也就是说，您不使用外部 Google 服务，例如 Google Ads 或 Google 地图。
  • 您计划使用 Gemini Enterprise 或 NotebookLM Enterprise，并且需要支持每位用户最多拥有 2,000 个群组成员身份，或者在共享资源时能够按名称查找群组。

采用 SCIM 的员工身份联合架构。

在此模式中，您可以使用员工身份联合来联合Google Cloud 组织。为了增加可用于 Gemini Enterprise 的群组数量，您还可以配置 SCIM 以提前预配群组成员资格信息。

福利

  • 借助此模式，您可以使用基于数据注入的连接器将 Gemini Enterprise 与 Microsoft 365 集成。
  • 您最多可以为每位用户分配 2,000 个群组成员身份，以控制对 Gemini Enterprise 和 NotebookLM Enterprise 的访问权限，并让基于 Gemini Enterprise 数据注入的连接器执行访问权限检查。
  • 在共享 NotebookLM Enterprise 笔记本等资源时，您可以按名称查找群组，以帮助提升整体用户体验。

限制

  • 对通过 SCIM 预配的群组的支持仅限于 Gemini Enterprise 和 NotebookLM Enterprise。 其他服务只能使用您的 IdP 在 SAML 断言或 ID 令牌中传递的群组成员身份。
  • 员工身份联合是一项 IAM 功能，仅允许用户访问使用 IAM 的服务。使用 Workforce Identity Federation 进行身份验证的用户无法访问 Google 服务，例如 Google Ads、Looker 或 Google Marketing Platform。
  • 使用员工身份联合进行身份验证的用户无法访问部分 Google Cloud 功能。如需了解详情，请参阅身份联合：产品和限制。

混合云身份和员工身份联合

如果您的组织符合以下条件，请选择此模式：

  • 您使用的 Google 服务超出 Google Cloud （例如 Google Ads 或 Google 地图）。
  • 您计划使用 Gemini Enterprise 并将其与 Microsoft 365 集成。

混合 Cloud Identity 和员工身份联合联合的架构。

此模式结合了前两种模式：

  • 您可以使用员工身份联合（无同步或使用 SCIM）来管理对 Gemini Enterprise 和 NotebookLM Enterprise 的访问权限。
  • 您可以使用 Cloud Identity 或 Google Workspace 联合来管理对其他服务（包括 Google Cloud 和非云 Google 服务）的访问权限。

福利

此模式可让您兼具前两种模式的优势：

  • 您可以将 Gemini Enterprise 连接到 Microsoft 数据源，而不会受到功能限制。
  • 无论 Google 服务是否使用 IAM，用户都可以向这些服务进行身份验证。
  • 使用全套 Google Cloud 功能。

限制

  • 您必须在外部 IdP 中维护两个单独的信赖方配置：一个用于 Cloud Identity，另一个用于员工身份联合。
  • 根据您配置用户使用 Cloud Identity 还是 Workforce Identity Federation，他们的登录体验可能会有所不同。
  • 管理 IAM 允许政策时，您必须使用不同的主账号标识符，具体取决于用户的身份验证方式。例如，在外部 IdP 中名为 bob@example.com 的用户在 IAM 中可能具有 bob@example.com 或 principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID//subject/SUBJECT_ID 的主账号标识符，具体取决于该用户是使用 Cloud Identity 联合还是使用员工身份联合进行身份验证。
  • 您无法创建同时包含 Cloud Identity 用户和员工身份联合主账号的群组。Cloud Identity 群组只能包含 Cloud Identity 用户，而员工身份群组只能包含员工身份联合主账号。
  • 如果将员工身份联合的使用范围扩展到 Gemini Enterprise 之外，用户可能需要切换身份，或者不确定如何进行身份验证。

后续步骤