本文档介绍帮助您以始终安全的方式设置联合的最佳做法和指南。本指南以将 Cloud Identity 或 G Suite 与 Google Cloud 结合使用的最佳做法为基础。
所有 Google 服务（包括 Google Cloud、Google Marketing Platform 和 Google Ads）都依赖于 Google 登录对用户进行身份验证。您可以联合 Cloud Identity 或 G Suite 与您的外部身份提供商 (IdP)，例如 Active Directory 或 Azure Active Directory，而无需在 Cloud Identity 或 G Suite 中为每位员工手动创建和维护用户帐号。设置联合通常需要执行以下操作：
映射身份
由 Cloud Identity 或 G Suite 管理的用户帐号的身份由其主电子邮件地址定义。 主电子邮件地址在 Google 帐号页面上列为 Google 帐号电子邮件。 主电子邮件地址必须使用您添加到 Cloud Identity 或 G Suite 帐号的域名之一，才能被视为有效。
主电子邮件地址还具有以下用途：
- 主电子邮件地址是用户在登录时必须提供的用户名。虽然用户可以向自己的 Google 用户帐号添加辅助电子邮件地址或别名，但这些地址不会被视为身份，因此无法用于登录。
- 当管理员需要向用户发送通知（例如，公布潜在的安全风险）时，系统只会将通知发送到主电子邮件地址。
若要在 Google 和外部 IdP 之间设置单点登录和自动用户预配，您必须将外部 IdP 中的身份映射到 Cloud Identity 或 G Suite 中的相应身份。以下部分介绍了建立此映射的最佳做法。
在所有联合系统中使用相同的身份
为建立映射，您只需验证 IdP 提供给 Google 的 SAML 断言包含 NameID 声明，其值与现有 Cloud Identity 或 G Suite 用户的主电子邮件地址匹配。IdP 可以随意使用任何适用的映射或逻辑来为其现有用户生成合适的 NameID 声明。
许多 IdP 依赖电子邮件地址（或更常见的是，符合 RFC 822 的名称）来识别用户。示例如下：
- Active Directory 中的
userPrincipalName特性是一个符合 RFC 822 的名称，可唯一识别用户，并可用于登录 Windows 或 Active Directory Federation Services (AD FS)。 - Azure Active Directory 使用
UserPrincipalName特性识别用户并允许其登录。
如果您的外部 IdP 管理的用户依赖于电子邮件地址作为其身份，则您可以使用同一身份作为 Cloud Identity 或 G Suite 中的主电子邮件地址。在联合系统中使用同一用户身份具有多个优点：
当用户登录 Google 工具（如 Cloud Console）时，系统会先提示他们提供 Cloud Identity 或 G Suite 用户的主电子邮件地址，然后再将其重定向到您的外部 IdP。系统可能会向用户显示另一个登录屏幕，提示其输入用户名和密码，具体取决于您的身份提供商。
如果这些步骤中的电子邮件地址不同，则登录屏幕的顺序很容易造成最终用户的混淆。相反，如果用户可以在所有步骤中使用通用身份，则不会受到 IdP 之间的技术差异的影响，从而最大程度地减少潜在的混淆。
如果您不必映射用户身份，则将 Google Cloud 审核日志与本地系统日志关联起来会更容易。
同样地，如果在本地和 Google Cloud 上部署的应用需要交换包含用户身份的数据，则无需额外映射用户标识符。
如需详细了解如何将 Active Directory 用户或 Azure AD 用户映射到 Cloud Identity 或 G Suite，请参阅 Active Directory 或 Azure AD 指南。
确保身份使用可路由的电子邮件地址
Google Cloud 使用用户的主电子邮件地址来递送通知电子邮件。此类通知的示例包括以下内容：
预算提醒：如果您配置了预算提醒，则 Google Cloud 会在预算超出阈值时向结算管理员和结算用户发送通知。
付款通知：系统会将所有与付款相关的通知或提醒发送到为受影响的结算帐号配置的付款用户的电子邮件地址。
项目邀请：如果您将 Project Admin 角色分配给与项目组织关联的 Cloud Identity 或 G Suite 帐号不同的帐号的用户，则系统会向该用户发送邀请。用户必须点击电子邮件中的链接接受邀请，新授予的角色才会生效。
对邮件支持记录的回复和来自支持团队的其他通知。
如果您使用 G Suite 并正确配置了必要的 DNS MX 记录，则发送到主电子邮件地址的所有通知电子邮件都会递送到相应用户的 Gmail 收件箱。
对于 Cloud Identity 用户，Google Cloud 还会尝试递送通知电子邮件，但此电子邮件必须由您现有的电子邮件基础架构进行处理。如需确保您的 Cloud Identity 用户不错过通知，请确保您现有的电子邮件系统能够接受发送到 Cloud Identity 用户的主电子邮件地址的邮件，并且能够将该电子邮件路由到正确的邮箱。执行以下操作：
确保添加到 Cloud Identity 的所有网域都具有指向您现有电子邮件系统的 DNS MX 记录。
确保 Cloud Identity 用户的主电子邮件地址与您的电子邮件系统中的现有邮箱匹配。如果 Cloud Identity 使用的主电子邮件地址与用户的电子邮件地址不匹配，请在您的现有电子邮件系统中配置别名，以便将发送到每个主电子邮件地址的电子邮件路由到正确的邮箱。
如果这些解决方案不实用，可以考虑将 G Suite 添加到现有 Cloud Identity 帐号，并为负责结算或与支持团队互动的关键用户分配 G Suite 许可，这些用户因而最有可能收到通知。
评估现有消费者帐号的迁移选项
如果您的员工在贵组织注册 Cloud Identity 或 G Suite 之前就在使用 Google Ad Manager、Google AdSense 或 Google Analytics（分析）等 Google 服务，则可能您的员工一直在使用消费者帐号访问这些服务。
允许员工使用消费者帐号来处理业务可能会导致风险。如需详细了解这些风险以及如何发现现有消费者帐号，请参阅评估现有 Google 帐号。
您可以通过以下方式处理现有消费者帐号：
- 原样保留消费者帐号，接受潜在风险。
- 通过转移将帐号迁移到 Cloud Identity 或 G Suite。
- 强制非受管用户帐号的所有者将其电子邮件地址更改为使用其他网域。
如需详细了解如何整合现有消费者帐号，请参阅评估身份整合选项。
您决定的处理消费者帐号的方式会影响您设置联合的方式和顺序。开始在 Cloud Identity 或 G Suite 中创建用户帐号或设置单点登录之前，请评估您的用户使用的所有现有消费者帐号。
映射身份组
定义单个身份在您的外部 IdP 与 Cloud Identity 或 G Suite 之间的映射方式后，您必须确定要为其启用 Google 服务访问权限的一组身份。
可以向 Google 服务进行身份验证的一组有效身份是以下两个身份组的交集：
- 映射到 Cloud Identity 或 G Suite 中的身份的外部身份。
您的外部 IdP 允许单点登录 Cloud Identity 或 G Suite 的外部身份。
控制哪些用户可以使用单点登录的流程取决于您使用的 IdP。例如，Azure AD 依赖于分配，而 AD FS 使用访问权限控制政策。
限制可以向 Google 服务进行身份验证的一组身份
根据您计划使用 Google Cloud、G Suite 和其他 Google 工具的方式，您的组织中的所有员工或者其中一部分员工将能够向 Google 服务进行身份验证。
如果您只打算向组织中的一部分员工授予对 Google 服务的访问权限，那么最好只对这组用户进行身份验证。 通过限制可进行身份验证的用户数量，您可以设置一层额外的防御，以防您不小心将访问权限控制规则配置得过于宽松。
您可以通过以下方式限制可向 Google 进行身份验证的一组用户：
- 最大限度地减少 Cloud Identity 或 G Suite 中的用户帐号数量。如果没有映射的用户帐号，那么即使 IdP 允许用户通过单点登录的方式登录 Cloud Identity 或 G Suite，此用户尝试进行的任何身份验证都将失败。
- 在 IdP 中配置单点登录，以最大限度地减少允许登录 Cloud Identity 或 G Suite 的用户数量。
最适合您的方式取决于您是否有需要迁移的现有消费者帐号。
如果您仍需要迁移消费者帐号，请限制预配的一组身份
仅当您尚未在 Cloud Identity 或 G Suite 中创建与消费者帐号具有相同身份的用户帐号时，才可以将此消费者帐号迁移到 Cloud Identity 或 G Suite。
如果您仍计划迁移现有消费者帐号，请务必小心谨慎，避免不小心创建有冲突的用户帐号。 请遵循以下原则：
- 仅为需要使用 Cloud Identity 或 G Suite 用户帐号且已知没有消费者帐号的用户创建新的 Cloud Identity 或 G Suite 用户帐号，以限制身份验证。
- 允许在 Cloud Identity 或 G Suite 中为其创建用户帐号的用户以及所有尚未迁移的消费者帐号使用单点登录，避免无意中锁定已迁移的帐号。
下图展示了不同类型的身份的重叠和相互关系。
如图所示，在 Cloud Identity 或 G Suite 中具有用户帐号的身份处于最小（黄色）的椭圆中。此椭圆包含在第二个（蓝色）椭圆中，这个椭圆中包含能够进行身份验证的身份。第三个也是最大的椭圆（粉色）所包含的身份在您的 IdP 中拥有用户帐号。如需详细了解如何配置 Active Directory、Azure AD 或 Okta，请参阅单独的最佳做法指南。
禁止注册新消费者帐号
当没有更多消费者帐号需要迁移到 Cloud Identity 或 G Suite 时，最好禁止注册新的消费者帐号。
将网域（如 example.com）添加到您的 Cloud Identity 或 G Suite 帐号不会防止员工使用同一网域注册新的消费者帐号。这些新的消费者帐号会在您的 Cloud Identity 或 G Suite 帐号中显示为非受管用户，但其无法使用单点登录或您在 Cloud Identity 或 G Suite 帐号中应用的任何其他配置。
为阻止创建新的消费者帐号，您必须在 Cloud Identity 或 G Suite 中使用同一电子邮件地址创建用户帐号。例如，如果您在 Cloud Identity 或 G Suite 帐号中创建了用户 alice@example.com，则员工尝试使用同一身份注册新消费者帐号的操作将失败。但是，如果 Cloud Identity 或 G Suite 中没有对应的用户，则注册新消费者帐号的操作将会成功。
当没有更多消费者帐号需要迁移到 Cloud Identity 或 G Suite 时，您可以应用以下配置：
仅允许相关用户对 Cloud Identity 或 G Suite 进行单点登录以限制身份验证。
理想情况下，您应为所有员工预配 Cloud Identity 或 G Suite 用户。请确保用户帐号使用员工的公司电子邮件地址作为主电子邮件地址或别名，这样可以避免使用同一电子邮件地址创建新的消费者帐号。如果可能，请将未启用单点登录的用户帐号保留为暂停状态。
下图展示了此配置。
将 Cloud Identity 或 G Suite 身份设为您的外部 IdP 中身份的子集
您的 Cloud Identity 或 G Suite 帐号可能包含其身份未映射到外部 IdP 中任何用户的用户帐号。 有两种典型的情况可能会导致出现此类用户帐号：
- 您在 Cloud Identity 或 G Suite 中创建了新用户帐号，并使用未映射到外部 IdP 中的任何用户的主电子邮件地址。
- 您在 Cloud Identity 或 G Suite 中拥有一个映射到外部 IdP 中某个身份的用户帐号，但您删除了外部 IdP 中的此身份。例如，如果员工离职，您可能会删除其身份。
当您在 Cloud Identity 或 G Suite 中启用单点登录时，所有用户（超级用户除外）都必须使用单点登录。对于未映射到外部 IdP 中的身份的 Cloud Identity 或 G Suite 用户帐号，尝试使用单点登录的操作将失败。没有对应帐号的用户帐号实际上已失效，但在以下情况下可能仍存在风险：
如果在某个时间点暂时或永久停用单点登录，则可以再次使用此用户帐号。这会导致离职员工能够登录并访问公司资源。
已删除的用户帐号的名称可能会被重复使用。例如，加入公司的新员工可能会与几个月或几年前离职的某个员工同名。如果离职员工的用户帐号已被删除，则您可能会为新员工分配离职员工使用过的用户名。
新员工用户帐号的内部 ID 可能与离职员工不同。但从联合的角度来看，如果两个用户帐号映射到 Cloud Identity 或 G Suite 中的同一主电子邮件地址，则这两个用户帐号会被视为同一帐号。 因此，当新员工登录 Google 时，他们可能会“继承”离职员工的现有数据、设置和权限。
Cloud Identity 和 G Suite 超级用户不需要使用单点登录，但当 IdP 发起登录时，他们仍然可以使用单点登录。由于超级用户具有使用 IdP 发起的单点登录的能力，当其在您的外部 IdP 中缺少对应的帐号时，就很容易遇到姓名抢注问题。
请考虑以下示例：Alice 在 Cloud Identity 或 G Suite 中拥有超级用户 alice-admin@example.com，并且未使用两步验证。Mallory 不知道 Alice 的密码，但他找到了一种方法，能够在外部 IdP 中创建一个映射到 alice-admin@example.com 的新用户。虽然这个新创建的用户帐号可能没有任何特殊权限，并且与 Alice 的用户帐号没有任何关系，但其与 Alice 的超级用户帐号共用一个通用身份，因此 Malory 可以使用 IdP 发起的单点登录并将身份验证为 alice-admin@example.com。
为了消除这种姓名抢注风险，请确保您的 Cloud Identity 或 G Suite 身份是您的外部 IdP 中身份的子集。为实现此目的，最好的方法是将外部 IdP 实现的整个用户帐号生命周期映射到 Cloud Identity 或 G Suite 中的用户帐号生命周期。
使用专用的超级用户
G Suite 和 Cloud Identity 超级用户帐号拥有一组强大的权限，这些权限不仅适用于 Cloud Identity 或 G Suite 帐号，还适用于关联的 Google Cloud 组织。 由于只有一小部分活动需要超级用户权限，因此在可能的情况下，最好限制具有超级用户访问权限的管理员数量，并将权限较低的用户帐号用于帐号或 Google Cloud 组织的日常管理。
如果您确定某些管理员需要超级用户访问权限，请为其创建专用的超级用户帐号，例如：
- 创建一个身份为
alice@example.com的用户帐号并分配常规权限。此帐号应用于日常活动的常规操作。 使用身份
alice-admin@example.com创建第二个用户帐号，并为其分配超级用户权限。Alice 最好仅在需要超级用户访问权限的情况下使用此帐号。为确保用户的邮箱能够接收发送到此电子邮件地址的通知电子邮件，请配置 G Suite 或您的现有电子邮件系统，使电子邮件地址
alice-admin@example.com作为别名或转发给alice@example.com。
确保您的外部 IdP 可以识别这两个身份，以使 Cloud Identity 或 G Suite 中的身份组仍是外部 IdP 中的身份的子集。
我们建议您为这些专用超级用户帐号指定一个命名方案，以便在审核日志中跟踪它们用于何处以及进行了哪些操作。例如，将 -admin 添加到用户名，如上例所示。
限制 G Suite 和 Cloud Identity 中的服务用户数量
您的外部 IdP 可能不仅包含员工的用户帐号，还包含供机器用户（如应用、工具或后台作业）使用的用户帐号。
相比之下，在 Google Cloud 上允许应用进行身份验证以及访问 Google API 的首选方法如下：
需要代表最终用户访问 Google API 或服务的 Web 应用或工具应使用 OAuth 2.0 或 OpenID Connect。 通过使用其中一种协议，应用首先会征求最终用户的同意以访问其数据，并在获得同意后代表最终用户执行访问。
如果对 API 或服务的访问并非代表最终用户，而是代表应用本身，则最好使用 Google Cloud 服务帐号进行身份验证，然后使用 Cloud IAM 为服务帐号授予资源的访问资源。
如果 Google Cloud 服务帐号被授予了 Cloud IAM 中适当的角色，则这些帐号可用于身份验证以及使用任何 Cloud API。如果您需要为服务帐号授予对 Google Cloud 之外的 API（例如 Directory API 或Drive API）的访问权限，则可以使用 G Suite 全网域委托。
借助 G Suite 全网域委托功能，您可以让服务帐号代表 Cloud Identity 或 G Suite 用户执行操作。由于委托是一项强大的权限，因此我们建议您仅在 OAuth 方法不实用时才使用 G Suite 全网域委托。
对启用了 G Suite 全网域委托的每个 Google Cloud 服务帐号使用专用 Cloud Identity 或 G Suite 用户。在外部 IdP 中创建此用户，然后将其预配到 Cloud Identity 或 G Suite，以使 Cloud Identity 或 G Suite 中的用户组仍是外部 IdP 中的用户的子集。
请避免在 Cloud Identity 和 G Suite 中创建您不打算用于 G Suite 全网域委托的服务用户。
映射用户帐号生命周期
您的外部 IdP 中的用户帐号遵循特定的生命周期。通常情况下，此生命周期反映的是员工与公司之间的关系：
- 系统会为加入组织的员工创建新的用户帐号。
- 用户帐号可能会被暂停，之后重新激活，例如在员工休假时。
- 当用户离开公司后，用户帐号会被删除，或在特定的保留期限内处于暂停状态，最终被删除。
下图展示了此生命周期。
本部分列出了确保 Cloud Identity 或 G Suite 中用户帐号的生命周期遵循外部 IdP 中相应用户帐号的生命周期的最佳做法。
将外部 IdP 指定为可靠来源
许多人力资源信息系统 (HRIS)、IdP 和适配器仅支持单向用户预配。这意味着在 HRIS 或 IdP 中执行的更改会传播到 Cloud Identity 或 G Suite，但在 Cloud Identity 或 G Suite 中执行的更改不会传播回去。
为防止单向预配导致的不一致，请将您的外部 IdP 指定为可靠来源。仅使用您的外部 IdP（或 HRIS）创建、修改或删除用户，并依赖自动预配将更改传播到 G Suite 和 Cloud Identity。通过将外部 IdP 指定为可靠来源，您可以降低不一致以及手动修改被 IdP 覆盖的风险。
将用户自动预配到 Cloud Identity 或 G Suite
为使员工能够使用单点登录向 Google 进行身份验证，您必须先在 Cloud Identity 或 G Suite 中为该员工创建用户帐号。为确保与外部 IdP 保持一致，最佳做法是在 Cloud Identity 或 G Suite 中自动预配这些用户帐号：
- 通过自动预配，您可以确保 Cloud Identity 或 G Suite 身份始终是外部 IdP 中的身份的子集。
- 您可以最大限度地降低无意中引入 Cloud Identity 或 G Suite 中的身份与外部 IdP 中的相应身份之间不匹配的风险。不匹配（例如电子邮件地址拼写错误）可能会导致员工无法登录。
- 您可以最大限度地减少手动管理的工作量。
如果您使用 HRIS 来管理初始配置过程，则自动进行用户预配的一种方法是配置 HRIS，使其将用户帐号同时预配到外部 IdP 和 Cloud Identity 或 G Suite，如下图所示。
为确保此设置能够正常运行，您必须确保您的 HRIS 预配用户帐号，使其能够正确地彼此映射。 此外，HRIS 还必须决定要将哪些用户帐号预配到 Cloud Identity 或 G Suite。
在不使用 HRIS 的情况下，自动进行用户预配的另一种方法是将外部 IdP 用作在 Cloud Identity 或 G Suite 中预配用户的权威来源。在此设置中，映射用户帐号和用户帐号组的配置在 IdP 中或由适配器进行管理，如下图所示。
如果您使用 Active Directory 作为 IdP，则可以使用 Google Cloud Directory Sync 复制此设置。 其他 IdP（如 Azure AD 或 Okta）具有内置适配器，用于为 G Suite 预配用户。 由于 G Suite 和 Cloud Identity 基于同一平台且使用相同的 API，因此这些适配器也可用于 Cloud Identity。
将暂停事件传播到 Cloud Identity 或 G Suite
当员工从单位离职时（无论是临时还是永久），我们建议您撤消该员工对 Google 服务的访问权限。通过暂停员工在外部 IdP 中的用户帐号，您可以撤消员工使用单点登录向 Google 进行身份验证的权限，但可能无法完全撤消其对所有 Google 服务的访问权限。以下情况可能仍会出现：
- 如果 Cloud Identity 或 G Suite 用户的浏览器会话处于活动状态，该会话将继续有效。已获得的所有 OAuth 令牌也会继续有效。
- 如果用户拥有超级用户权限，或者您已配置了网络掩码，则该员工可能仍然可以使用密码登录。
- 用户帐号可能仍会收到来自 Google Cloud 的通知，包括预算提醒。
- 如果用户已分配有 G Suite 许可，则系统会继续将电子邮件递送到该用户的邮箱，该用户仍会显示在通讯录中，并且该用户可能仍会在 Google 日历中被列为可用。
- 如果您允许用户使用安全性较低的应用，则用户可能仍可通过使用应用专用密码访问 Gmail、Google 日历和其他数据。
如需完全撤消对 Google 服务的访问权限，请通过以下方式将暂停事件传播到 Cloud Identity 或 G Suite：
确保每当外部 IdP 中有用户帐号被暂停时，Cloud Identity 或 G Suite 中相应的用户帐号也会被暂停。暂停 Cloud Identity 或 G Suite 中的用户会终止活跃的浏览器会话、使令牌失效并撤消所有其他访问权限。
同样，在外部 IdP 中重新激活用户帐号时，请务必在 Cloud Identity 或 G Suite 中重新激活相应的用户帐号。
在 Cloud Identity 或 G Suite 中暂停用户帐号属于非破坏性操作。在用户帐号被暂停期间，系统会保留用户的数据，同时 G Suite 许可会保持关联状态，且 Google Cloud 中分配的角色保持不变。
将删除事件传播到 Cloud Identity 或 G Suite
当员工永久离开单位时，您可能不仅要暂停该员工在外部 IdP 中的用户帐号，还要将其删除。
如果您删除外部 IdP 中的用户帐号，但未删除相应的 Cloud Identity 或 G Suite 用户，则 Cloud Identity 和 G Suite 中的用户组不再是外部 IdP 中用户的子集。 如果入职的新员工正好与从公司离职的员工同名，这可能会带来问题。如果您在 IdP 中为新员工创建用户帐号，则可能会重复使用离职员工的用户名，导致新用户帐号映射到 Cloud Identity 或 G Suite 中的旧用户帐号。因此，新员工可能会获得离职员工的数据和设置的访问权限。
您可以在 IdP 中的用户帐号被删除后立即删除 Cloud Identity 或 G Suite 中相应的用户，从而避免与孤立的 Cloud Identity 或 G Suite 用户帐号关联的风险。
删除 Cloud Identity 或 G Suite 用户是一项破坏性操作，只能在特定时间段内撤消。 根据用户使用的 Google 服务，删除用户可能会导致关联数据被永久删除，这可能不符合您的合规性要求。
若要在永久删除用户的设置和数据之前将其保留一段特定的时间，请采用以下方法之一：
通过将用户暂停状态保留一段特定的时间，延迟在外部 IdP 中删除用户帐号。保留期限过后，再删除 IdP 和 Cloud Identity/G Suite 中的用户。
删除外部 IdP 中的用户帐号时，请暂停相应的 Cloud Identity 或 G Suite 用户，并将其主电子邮件地址更改为不太可能引起冲突的名称。例如，将
alice@example.com重命名为obsolete-yyyymmdd-alice@example.com，其中yyyymmdd反映了外部 IdP 中的删除日期。将重命名的用户帐号保留在暂停状态一段时间，并在保留期限结束后将其删除。
如需为已暂停的用户保留 G Suite 数据，请保留已分配给该用户的 G Suite 许可或将其切换为封存用户专用许可，以确保继续应用 G Suite 保险柜保留规则并保留用户数据。
单点登录
所有 Google 产品（包括 Google Cloud、Google Ads 和 YouTube 等服务）均使用 Google 登录对用户进行身份验证。服务通过将用户重定向到 accounts.google.com（用户看到 Google 登录屏幕并被提示输入电子邮件地址的页面）来启动身份验证过程。根据提供的电子邮件地址的网域，系统会在 Gmail、消费者帐号目录中查找用户帐号，如果该网域与其主域名、辅助域名或别名域名匹配，则在 Cloud Identity 或 G Suite 帐号中查找。
下图展示了此身份验证过程。
如果您将 Cloud Identity 或 G Suite 帐号配置为使用单点登录，则系统会将用户重定向到外部 IdP 以进行身份验证。当外部 IdP 完成身份验证后，系统会通过 SAML 断言的方式将结果中继回 Google 登录。此 SAML 断言可作为身份验证成功的证明。该断言包含用户的电子邮件地址，并由外部 IdP 的证书签名，便于 Google 登录验证其真实性。
此过程称为“服务提供商发起的单点登录”，适用于除超级用户以外的所有用户。超级用户绝不会重定向到外部 IdP，系统会提示他们输入密码。
某些 IdP 还支持“IdP 发起的单点登录”。在此模型中，用户在外部 IdP 上进行身份验证，然后点击指向 Google Cloud 或 Google Ads 等 Google 服务的链接。如果已为 Cloud Identity 或 G Suite 帐号启用单点登录，则该帐号的所有用户都可以使用 IdP 发起的单点登录，包括超级用户。
最大限度地减少在 SAML 断言中传递的特性集
用户在外部 IdP 进行身份验证后，Cloud Identity 或 G Suite 会使用外部 IdP 传递的 SAML 断言来建立会话。除了验证其真实性之外，此过程还包括识别与 SAML 断言中的 NameID 值对应的 Cloud Identity 或 G Suite 用户帐号。
NameID 值应包含要验证身份的用户帐号的主电子邮件地址。电子邮件地址区分大小写。不考虑别名和辅助电子邮件地址。
为避免拼写错误或大小写不匹配，最好自动预配用户帐号。
SAML 断言可以包含其他特性，但在身份验证期间不考虑这些特性。包含信息的特性（例如用户的名字、姓氏或群组成员资格）会被忽略，因为 Cloud Identity 或 G Suite 中的用户帐号被视为此用户信息的唯一来源。
要最大限度地缩减 SAML 断言的大小，请配置您的 IdP，使其不包含 Google 登录要求的特性以外的其他特性。
使用 google.com 作为颁发者
Google 登录会话不限于单个工具或网域。相反，会话建立后，该会话在用户已获得访问权限的所有 Google 服务中都有效。 此服务列表可能包括 Google Cloud 和 Google Ads 等服务以及 Google 搜索和 YouTube 等服务。
会话的全局性质反映在 SAML 协议交换中：默认情况下，Google 会在 SAML 请求中使用 google.com 作为颁发者（SAML 请求中的 Issuer 元素），并期望 SAML 断言指定 google.com 作为目标对象（SAML 响应中的 Audience 元素）。
若要更改此默认设置，您可以在 Cloud Identity 或 G Suite 中配置单点登录时启用使用网域特有的颁发者选项。只有当您拥有多个 Cloud Identity 或 G Suite 帐号（因此有多个网域）且您的 IdP 需要区分其中一个 Cloud Identity 或 G Suite 帐号与另一个帐号发起的登录时，才启用网域特有的颁发者选项。启用该选项后，SAML 请求将使用 google.com/a/DOMAIN 作为颁发者，并期望 google.com/a/DOMAIN 作为目标对象，其中 DOMAIN 是 Cloud Identity 或 G Suite 帐号的主域名。
在所有其他情况下，请保留默认设置，以使用 google.com 作为颁发者，并配置外部 IdP 以将 google.com 指定为 SAML 断言中的目标对象。根据您的 IdP，此设置也可能称为“颁发者”、“信赖方信任标识符”或“实体 ID”。
使 Google 会话与 IdP 会话的长度保持一致
当用户完成单点登录过程并建立会话后，Google 登录会话会在特定时间段内保持活动状态。当此时间段过后或用户退出登录时，系统会要求用户重复单点登录过程来重新进行身份验证。
默认情况下，Google 服务的会话时长为 14 天。对于拥有 Cloud Identity 专业版或 G Suite 商务版许可的用户，您可以将默认会话长度更改为其他时间段，例如 8 小时。
您可以控制 Google Cloud 使用的会话长度。
Google Cloud 会话适用于 Cloud Console 以及 gcloud 命令行工具和其他 API 客户端。您可以在所有 Cloud Identity 和 G Suite 帐号类型中设置 Google Cloud 会话长度。
大多数外部 IdP 还会为经过身份验证的用户维护会话。如果 IdP 会话的长度比 Google 会话的长度长，则系统可能会在不发出提示的情况下重新进行身份验证。也就是说，用户会被重定向到 IdP，但可能无需再次输入凭据。在不发出提示的情况下重新进行身份验证可能会破坏缩短 Google 会话长度的意图。
为确保用户在 Google 会话过期后必须再次输入其凭据，请配置 Google 会话长度和 IdP 会话长度，以确保 IdP 会话长度短于 Google 会话长度。
多重身份验证
在 Cloud Identity 或 G Suite 和外部 IdP 之间启用单点登录可以改善员工的用户体验。用户无需频繁进行身份验证，也无需记住单独的凭据即可访问 Google 服务。
但是，允许用户跨服务和环境无缝进行身份验证也意味着用户凭据被盗用的潜在影响会提升。 如果用户的用户名和密码丢失或被盗，攻击者可能不仅会使用这些凭据访问现有环境中的资源，还会访问一项或多项 Google 服务中的资源。
为降低凭据被盗的风险，最好为所有用户帐号使用多重身份验证。
对用户强制执行多重身份验证
为您的 Cloud Identity 或 G Suite 帐号配置单点登录后，没有超级用户权限的用户必须使用您的外部 IdP 进行身份验证。
配置您的 IdP，要求使用双重身份验证（例如一次性代码或 USB 密钥），以确保每次通过单点登录的方式登录 Google 时强制应用多重身份验证。
如果您的外部 IdP 不支持多重身份验证，请考虑启用单点登录后验证，以便 Google 在用户从外部 IdP 身份验证返回后执行其他验证。
避免使用网络掩码，因为它们可能会被滥用以规避对用户进行多重身份验证。
对超级用户强制执行 Google 两步身份验证
G Suite 和 Cloud Identity 超级用户帐号无需进行单点登录，并且拥有一组强大的权限，因此很容易成为攻击者的攻击目标。默认情况下，两步身份验证对于 Google 帐号（包括超级用户帐号）是可选的，除非您强制执行两步身份验证，否则用户可以自行选择是否启用该功能。
超级用户通常分为两类：
个性化超级用户：这些用户是个性化用户，应由单个管理员使用。我们建议您对所有个性化超级用户强制执行两步验证。
机器超级用户：虽然最好避免使用此类用户帐号，但有时需要使用它们来启用 Cloud Directory Sync 或 Azure AD 图库应用等工具来管理 Cloud Identity 或 G Suite 中的用户和群组。
请限制机器超级用户的数量，并尽可能尝试启用两步验证。
对于不使用单点登录的用户，您可以按单位部门或群组对全局帐号强制执行两步身份验证：
如果您没有无法使用两步验证的机器超级用户，则最好为所有用户开启强制执行。 对所有用户强制执行两步验证可以避免意外丢失用户的风险。
如果您有一些无法使用两步验证的机器超级用户，请使用专用的群组来控制两步验证。创建一个新群组，为该群组开启强制执行，并将所有相关的超级用户添加到其中。
如需详细了解如何使用两步身份验证来保护超级用户，请参阅我们的管理员帐号的安全最佳做法。
不通过网络掩码限制单点登录
在 Cloud Identity 或 G Suite 中配置单点登录时，您可以选择指定网络掩码。 如果您指定了掩码，则只有 IP 地址与掩码匹配的用户才能进行单点登录；其他用户在登录时需要输入密码。
如果您使用网络掩码，则可能会破坏由外部 IdP 强制执行的多重身份验证。例如，通过更改位置或使用 VPN，用户可以控制是否应用网络掩码。如果您在外部 IdP 强制执行多重身份验证，则此策略可能允许用户或攻击者规避在外部 IdP 中配置的多重身份验证政策。
为确保无论用户的位置或 IP 地址如何，都始终应用多重身份验证，请避免通过网络掩码限制单点登录。
如需按 IP 地址限制对资源的访问权限，请在外部 IdP 配置适当的 IP 允许列表，或使用 Google Cloud 的情境感知访问权限和 G Suite。