评估用户账号整合对联合的影响

Last reviewed 2023-02-27 UTC

如果您计划将 Cloud Identity 或 Google Workspace 与外部身份提供商 (IdP) 联合，但仍需要整合现有消费者账号，则本文档可帮助您了解和评估联合与整合之间的相互作用。此外，本文档还介绍了如何通过不影响整合现有消费者账号能力的方式来配置联合。

联合与用户账号整合之间的相互作用

在联合设置中，您将 Cloud Identity 或 Google Workspace 连接到外部权威来源，以便权威来源可以在 Cloud Identity 或 Google Workspace 中自动预配用户账号。

联合设置通常具有以下不变的特性：

  1. 权威来源是唯一的身份来源。
  2. 除了权威来源预配的账号之外，Cloud Identity 或 Google Workspace 中没有其他用户账号。
  3. 除了权威来源已为其预配用户账号的身份以外，SAML 身份提供商不允许任何其他身份进行 Google 单点登录。

虽然这些不变的特性体现了联合 Google Cloud 与外部身份提供商的最佳做法，但当您想要迁移现有消费者账号时却会遇到一些问题：

  1. 现有消费者账号并非来自权威来源。这些账号已经存在，现在需要与权威来源已知的身份相关联。
  2. 现有消费者账号在迁移到 Cloud Identity 或 Google Workspace 后，即为尚未由权威来源预配的用户账号。权威来源必须识别并“采用”这些已迁移的账号。
  3. SAML 身份提供商可能不知道现有消费者账号的身份，但仍需允许它们使用单点登录。

若要允许现有消费者账号进行整合，您必须以对账号整合安全的方式临时设置联合。

确保联合的安全性以进行账号整合

下表列出了确保联合的安全性以进行账号整合的要求。如果您计划使用外部 IdP，但仍需要整合现有消费者账号，则必须确保您最初的设置满足这些要求。完成现有消费者账号的迁移后，您可以随时更改配置，因为这些要求不再适用。

要求 理由
允许拥有消费者账号的身份进行单点登录 迁移消费者账号需要账号转移。Cloud Identity 或 Google Workspace 管理员会发起账号转移，但要完成转移，消费者账号的所有者必须同意转移。作为管理员，您只能有限地控制用户表示同意及执行账号转移的时间。

在所有者表示同意并完成转移后，所有后续登录都将使用您的外部 IdP 进行单点登录。

为使单点登录成功，无论转移何时完成，请确保您的外部 IdP 允许计划迁移的所有消费者账号对应的身份进行单点登录。
防止为已拥有消费者账号的身份自动进行用户预配 如果您为已拥有消费者账号的身份预配用户账号，则会创建有冲突的账号。有冲突的账号会阻止您将消费者账号的所有权、其配置以及任何关联数据转移到 Cloud Identity 或 Google Workspace。

许多外部 IdP 的默认行为是在 Cloud Identity 或 Google Workspace 中主动创建用户账号。此行为可能会导致无意中创建有冲突的账号。

通过防止为已拥有消费者账号的身份自动进行用户预配，可以避免无意中创建有冲突的账号，并确保正确转移消费者账号。

如果您已确定消费者账号没有与您认为合法的外部 IdP 匹配的身份，并且希望将其迁移到 Cloud Identity 或 Google Workspace，则您必须确保您的联合配置不会影响您迁移这些消费者账号的能力。

要求 理由
防止删除没有与外部 IdP 匹配的身份的已迁移账号 如果您的 Cloud Identity 或 Google Workspace 用户账号没有与外部 IdP 匹配的身份，则您的 IdP 可能会认为此用户账号为孤立账号，并可能暂停或删除该账号。

通过阻止外部 IdP 暂停或删除没有与外部 IdP 匹配的身份的已迁移账号，您可以避免丢失与受影响账号关联的配置和数据，并确保可以手动调整账号。

确保 Microsoft Entra ID（以前称为 Azure AD）联合的安全性以进行账号整合

如果您计划将 Cloud Identity 或 Google Workspace 与 Microsoft Entra ID（以前称为 Azure AD）联合，则可以使用 Google Workspace 图库应用。

启用预配时，Microsoft Entra ID 会忽略 Cloud Identity 或 Google Workspace 中没有对应 Microsoft Entra ID 的现有账号，因此防止删除没有与外部 IdP 匹配的身份的已迁移账号的要求始终会得到满足。

根据您配置图库应用的方式，您仍必须确保执行以下操作：

您可以通过多种方式满足这些要求。每种方法都有其优点和缺点。

方法 1：不配置预配

使用此方法时，您将配置图库应用以处理单点登录，但不配置自动用户预配。通过不配置用户预配，您可以防止为已拥有消费者账号的身份自动进行用户预配。

为允许拥有消费者账号的身份进行单点登录，请将应用分配给最终可能需要访问 Google 服务的所有身份，即使其现有消费者账号仍要进行迁移也是如此。

对于已有消费者账号的用户，系统会在用户接受转移请求后自动创建相应的 Cloud Identity 或 Google Workspace 用户账号。然后，该用户可以立即使用单点登录。

对于没有 Cloud Identity 或 Google Workspace 用户账号的用户，您必须手动创建一个账号。

虽然此方法能够满足要求且设置最简单，但在 Microsoft Entra ID 中执行的任何特性更改或用户暂停均不会传播到 Cloud Identity 或 Google Workspace。

方法 2：手动分配两个应用

使用此方法时，您可以不必在 Cloud Identity 或 Google Workspace 中为没有现有账号的用户手动创建用户账号。该方法是使用两个图库应用，一个用于预配，另一个用于单点登录：

  • 第一个应用专门用于预配用户和群组，且已停用单点登录。通过将用户分配给此应用，您可以控制向 Cloud Identity 或 Google Workspace 预配哪些账号。
  • 第二个应用专门用于单点登录，且无权预配用户。通过将用户分配给此应用，您可以控制哪些用户可以登录。

按如下方式使用这两个应用来分配用户：

方法 3：停用两个应用的用户创建功能

配置预配时，您需要授权 Microsoft Entra ID 使用 Cloud Identity 或 Google Workspace 账号访问 Cloud Identity 或 Google Workspace。通常，最好为此使用专用超级用户账号，因为超级用户账号无需单点登录（也就是说，任何单点登录配置都不适用于超级用户账号；超级用户账号将继续使用密码登录）。

但是，对于这种情况，您可以让 Microsoft Entra ID 使用更受限的账号进行迁移，该账号不允许 Microsoft Entra ID 创建用户。这样一来，无论您将哪些用户分配给预配应用，您都可以有效地防止 Azure 自动为拥有消费者账号的身份预配用户账号。

Cloud Identity 或 Google Workspace 中受限的管理员用户账号应仅具有以下权限：

  • 单位部门 > 读取
  • 用户 > 读取
  • 用户 > 更新
  • 群组

这种方法的缺点是，对于没有非代管式账号的用户，您必须在 Cloud Identity 或 Google Workspace 中手动为其创建账号。

与 Microsoft Entra ID 联合：对比

下表总结了上述方法。

允许拥有消费者账号的身份进行单点登录。 防止为已拥有消费者账号的身份自动进行用户预配 防止删除没有与外部 IdP 匹配的身份的已迁移账号 自动预配新账号 自动更新已迁移的账号
方法 1：不进行预配 ✅ ✅ ✅ X X
方法 2：手动分配两个应用 ✅ 容易出现手动错误 ✅ ✅ ✅
方法 3：停用两个应用的用户创建功能 ✅ ✅ ✅ X ✅

确保 Active Directory 联合的安全性以进行账号整合

如果您计划将 Cloud Identity 或 Google Workspace 与 Active Directory 联合，则可以使用 Google Cloud Directory Sync 和 Active Directory Federation Services (AD FS)。配置 Google Cloud Directory Sync 和 AD FS 时，您必须确保执行以下操作：

您可以通过多种方式满足这些要求。每种方法都有其优点和缺点。

方法 1：停用 Google Cloud Directory Sync

在此方法中，可使用 AD FS 设置单点登录，但要在迁移非代管式用户账号之后才启用 Google Cloud Directory Sync。通过停用 Google Cloud Directory Sync，您可以防止为已拥有消费者账号的身份自动进行用户预配。

为允许拥有消费者账号的身份进行单点登录，请在 AD FS 中创建自定义访问权限控制政策，并分配最终可能需要访问 Google 服务的所有身份，即使其现有消费者账号仍要进行迁移也是如此。

对于已有消费者账号的用户，系统会在用户接受转移请求后自动创建相应的 Cloud Identity 或 Google Workspace 用户账号。通过使用自定义访问权限控制政策，您可以确保用户能够立即使用单点登录。

对于没有 Cloud Identity 或 Google Workspace 用户账号的用户，您必须手动创建一个账号。

虽然此方法能够满足要求且设置最简单，但在 Active Directory 中执行的任何特性更改或用户暂停均不会传播到 Cloud Identity 或 Google Workspace。

方法 2：手动分配 Google Cloud Directory Sync

使用此方法时，您可以不必在 Cloud Identity 或 Google Workspace 中为没有现有账号的用户手动创建用户账号。

这种方法的局限性在于，您无法防止删除没有与外部 IdP 匹配的身份的已迁移账号。 因此，仅当您没有任何与外部 IdP 匹配的身份的消费者账号时，此方法才适用。

方法 3：禁止 Google Cloud Directory Sync 创建用户

配置预配时，您必须授权 Google Cloud Directory Sync 访问 Cloud Identity 或 Google Workspace。通常，最好为此使用专用超级用户账号，因为超级用户账号无需单点登录（也就是说，任何单点登录配置都不适用于超级用户账号；超级用户账号将继续使用密码登录）。

但是，在这种情况下，您可以让 Google Cloud Directory Sync 使用受限更严的账号来执行迁移，该账号不允许创建用户。这样一来，您就可以有效地防止 Google Cloud Directory Sync 自动为拥有消费者账号的身份预配用户账号以及删除没有与外部 IdP 匹配的身份的已迁移账号。

Cloud Identity 或 Google Workspace 中受限管理员用户账号应仅具有以下权限：

  • 单位部门
  • 用户 > 读取
  • 用户 > 更新
  • 群组
  • 架构管理
  • 网域管理

这种方法的缺点是，对于没有非代管式账号的用户，您必须在 Cloud Identity 或 Google Workspace 中手动为其创建账号。

与 Active Directory 联合：对比

下表总结了上述方法。

允许拥有消费者账号的身份进行单点登录。 防止为已拥有消费者账号的身份自动进行用户预配 防止删除没有与外部 IdP 匹配的身份的已迁移账号 自动预配新账号 自动更新已迁移的账号
方法 1：不配置预配 ✅ ✅ ✅ X X
方法 2：手动分配 GCDS ✅ 容易出现手动错误 X ✅ ✅
方法 3：禁止 GCDS 创建用户 ✅ ✅ ✅ X ✅

确保 Okta 联合的安全性以进行账号整合

如需将 Cloud Identity 或 Google Workspace 与 Okta 联合，您可以使用 Okta 应用目录中的 Google Workspace 应用。此应用可以处理单点登录并将用户和群组预配到 Cloud Identity 或 Google Workspace。

当您使用 Google Workspace 应用进行预配时，Okta 会忽略 Cloud Identity 或 Google Workspace 中没有对应 Okta 用户的现有用户，因此总是能满足防止删除没有与外部 IdP 匹配的身份的已迁移账号的要求。

根据您配置 Okta 的方式，您仍必须执行以下操作：

您可以通过多种方式满足这些要求。每种方法都有其优点和缺点。

方法 1：不配置预配

使用此方法时，您将 Google Workspace 应用配置为处理单点登录，但完全不配置预配。通过不配置用户预配，您可以防止为已拥有消费者账号的身份自动进行用户预配。

为允许拥有消费者账号的身份进行单点登录，请将应用分配给最终可能需要访问 Google 服务的所有身份，即使其现有消费者账号仍要进行迁移也是如此。Google Workspace 或 Google Cloud 图标会显示在已分配给此应用的所有身份的 Okta 首页上。但是，除非 Google 端存在相应的用户账号，否则登录将失败。

对于已有消费者账号的用户，系统会在用户接受转移请求后自动创建相应的 Cloud Identity 或 Google Workspace 用户账号。然后，该用户可以立即使用单点登录。

虽然此方法能够满足要求且设置最简单，但在 Okta 中执行的任何特性更改或用户暂停均不会传播到 Cloud Identity 或 Google Workspace。这种方法的缺点是，对于没有非代管式账号的用户，您必须在 Cloud Identity 或 Google Workspace 中手动为其创建账号。

方法 2：通过手动分配进行预配

使用此方法时，您将配置 Google Workspace 应用以处理单点登录和预配，但仅启用以下预配功能：

  • 创建用户
  • 更新用户特性
  • 停用用户

向应用分配身份时，请包含最终需要访问 Google 服务的身份，但排除已知已拥有现有消费者账号的所有身份。这样，您就可以防止为已拥有消费者账号的身份自动进行用户预配。

在用户接受转移请求后，您需要将该用户分配给应用，以便他们能够使用单点登录并访问 Google Workspace 或 Google Cloud。

这种方法的缺点是，分配中出现任何错误都可能立即导致创建有冲突的账号，因此这种方法的风险比其他方法更大。

这种方法的另一个缺点是会暂时锁定已迁移的账号。在接受转移请求后，用户必须通过 Okta 执行所有后续登录操作。将用户分配给 Okta 中的应用之前，这些登录尝试将失败。

方法 3：通过停用用户创建功能进行预配

使用此方法时，您将配置 Google Workspace 以处理单点登录和预配，但仅启用以下预配功能：

  • 更新用户特性
  • 停用用户

停用创建用户选项，并将最终需要访问 Google 服务的所有身份分配给应用。包括具有现有消费者账号的身份，以便允许拥有消费者账号的身份进行单点登录。

通过禁止 Okta 创建账号，您可以阻止 Okta 自动为拥有消费者账号的身份预配用户账号。 同时，此配置仍允许 Okta 将特性更改和用户暂停操作传播到具有相应 Google 账号的用户的 Cloud Identity 或 Google Workspace。

对于在 Cloud Identity 或 Google Workspace 中没有相应用户账号的身份，Okta 可能会在 Okta 管理控制台中显示错误消息：

Okta 错误消息。

对于已有消费者账号的用户，系统会在用户接受转移请求后自动创建相应的 Cloud Identity 或 Google Workspace 用户账号。然后，该用户可以立即使用单点登录。虽然此时账号可正常使用，但 Okta 可能尚未在用户首页上显示图标，而是继续在管理界面中显示错误消息。如需解决此问题，请在 Okta 管理员信息中心内重试分配任务。

此方法可成功阻止 Okta 自动为拥有消费者账号的身份预配用户账号，但仍允许拥有消费者账号的身份进行单点登录。 与第二种方法相比，这种方法不易发生意外的配置错误。但这种方法的缺点在于，对于没有消费者账号的用户，您必须在 Cloud Identity 或 Google Workspace 中手动为其创建用户账号。

方法 4：手动分配两个应用

为克服上述方法的一些缺点，您可以使用两个应用，一个用于预配，另一个用于单点登录：

  • 配置 Google Workspace 应用的一个实例以仅处理配置。并且不使用应用的单点登录功能。通过将用户分配给此应用，您可以控制向 Cloud Identity 或 Google Workspace 预配哪些账号。通过启用不向用户显示应用图标 (Do not display application icon to users) 选项，您可以确保此应用对用户有效隐藏。
  • 配置 Google Workspace 应用的另一个实例，仅用于单点登录。通过将用户分配给此应用，您可以控制哪些用户可以登录。

按如下方式使用这两个应用来分配用户：

与 Okta 联合：对比

下表总结了上述方法。

允许拥有消费者账号的身份进行单点登录。 防止为已拥有消费者账号的身份自动进行用户预配 防止删除没有与外部 IdP 匹配的身份的已迁移账号 自动预配新账号 自动更新已迁移的账号
方法 1：不进行预配 ✅ ✅ ✅ X X
方法 2：通过手动分配进行预配 X 存在风险 ✅ ✅ ✅
方法 3：通过停用用户创建功能进行预配 ✅ ✅ ✅ X ✅
方法 4：手动分配两个应用 ✅ 存在风险 ✅ ✅ ✅

后续步骤