所有 Google 服务（包括 Google Cloud、Google Marketing Platform 和 Google Ads）都依赖于 Google 登录对用户进行身份验证。本文档介绍了 Google 登录进行身份验证和身份管理所依赖的网域模型。网域模型可帮助您了解 Google 登录在企业环境中的工作原理、身份的管理方式，以及如何促进与外部身份提供商 (IdP) 集成。下图展示了这些实体的交互方式。
如图所示，模型的中心是 Google 登录所用的 Google 身份。Google 身份与许多其他实体相关，这些实体在管理身份方面具有相关性：
- 面向消费者的 Google 包含与面向消费者的 Google 服务（如 Gmail）相关的实体。
- 面向组织的 Google 包含由 Cloud Identity 或 Google Workspace 管理的实体。这些实体与管理公司身份的相关度最高。
- Google Cloud 包含特定于 Google Cloud 的实体。
- 外部包含将 Google 与外部 IdP 集成的相关实体。
图中的实线箭头表示实体互相引用或互相包含，而虚线箭头表示联合关系。
Google 身份
身份、用户和用户账号在身份管理中发挥着至关重要的作用。这 3 个术语密切相关，有时甚至可互换使用。但在涉及身份管理时，需要区分这些概念：
“身份”是一个名称，用于唯一标识与 Google 服务进行交互的人员。Google 将电子邮件地址用于此用途。使用者的电子邮件地址会被视为其 Google 身份。
验证使用者与身份之间关联关系的过程称为身份验证或登录，此过程旨在证明使用者确实拥有此身份。
一个使用者可能拥有多个电子邮件地址。由于 Google 服务使用电子邮件地址作为身份，因此该使用者会被视为拥有多个身份。
“用户账号”是一种数据结构，用于跟踪特定身份与 Google 服务交互时应该应用的特性、活动和配置。用户账号不是即时创建的，但需要在首次登录前进行预配。
用户账号由未对外部公开的 ID 进行标识。因此，界面或 API 要求您通过其关联的身份（如
alice@gmail.com）间接引用用户账号。尽管存在这种间接性，但所有数据和配置详细信息仍与用户账号相关联，而与身份无关。
在大多数情况下，用户账号和身份之间是一对一的关系，这使得它们容易混淆。但是，情况并非总是如此，如以下边缘用例所示：
用户账号和身份之间的关系不固定。 您可以更改用户账号的主电子邮件地址，从而将另一个身份与该用户相关联。
作为 Cloud Identity 或 Google Workspace 管理员，您甚至可以交换两个用户的主电子邮件地址。例如，如果您交换了 Alice (
alice@example.com) 和 Bob (bob@example.com) 的主电子邮件地址，那么 Alice 将使用 Bob 的旧用户账号，而 Bob 将使用 Alice 的旧用户账号。由于数据和配置与用户账号（而非身份）相关联，因此 Alice 现在会使用 Bob 的现有配置和数据（而 Bob 则会使用 Alice 的配置和数据）。下图展示了这种关系。
在非联合设置中，您还必须重置密码，以便 Alice 和 Bob 交换用户账号。在 Alice 和 Bob 使用外部 IdP 进行身份验证的联合设置中，不需要重置密码。
身份和用户之间可能并非一对一关系。一个消费者账号可以有意与多个身份关联，如下图所示。
一个身份也有可能代表两个不同的用户账号。 我们建议您避免这种情况，但如果存在有冲突的用户账号，仍可能会出现这种情况。 在这种情况下，系统会在身份验证过程中向用户显示投票屏幕，让用户选择要使用的用户账号。
Google 区分了两种类型的用户账号：消费者账号和受管用户账号。以下部分更详细地介绍了这两种类型的用户账号及其相关实体。
面向消费者的 Google
如果您拥有一个类似 alice@gmail.com 的 Gmail 电子邮件地址，那么您的 Gmail 账号就是一个消费者账号。同样，如果您在 Google 登录页面上使用创建账号链接，并且在注册时提供自己的自定义电子邮件地址（如 alice@example.com），则生成的账号也是消费者账号。
消费者账号
消费者账号由使用者自己创建，主要用于私人用途。消费者账号的创建者对账号以及使用该账号创建的所有数据拥有完全控制权。使用者在注册时使用的电子邮件地址将成为消费者账号的主电子邮件地址，并用作其身份。使用者可以向消费者账号添加电子邮件地址。这些电子邮件地址将用作辅助身份，也可用于登录。
如果消费者账号使用与 Cloud Identity 或 Google Workspace 账号的主域名或辅助域名相对应的主电子邮件地址，则此消费者账号也称为“非受管用户账号”。
消费者账号可以是任意数量的群组的成员。
面向单位的 Google
如果您的单位使用 Google 服务，则最好使用受管用户账号。这些账号称为“受管账号”，因为其生命周期和配置可由组织完全控制。
受管用户账号是 Cloud Identity 和 Google Workspace 的一个特性。
Cloud Identity 或 Google Workspace 账号
Cloud Identity 或 Google Workspace 账号是用户、群组、配置和数据的顶级容器。当公司注册 Cloud Identity 或 Google Workspace 并与租户的概念对应时，系统会创建 Cloud Identity 或 Google Workspace 账号。
Cloud Identity 和 Google Workspace 共用一个技术平台。两款产品使用同一组 API 和管理工具，并共用账号这一概念作为用户和群组的容器；此容器通过域名进行标识。在管理用户、群组和身份验证方面，这两款产品大致相同。
账号包含群组以及一个或多个组织单元。
组织单元
组织单元 (OU) 是用户账号的子容器，可让您将 Cloud Identity 或 Google Workspace 账号中定义的用户账号细分为独立的分组，以更便于管理。
组织单元以分层方式进行组织。每个 Cloud Identity 或 Google Workspace 账号都有一个根级组织单元，您可以在其下根据需要创建更多组织单元。您还可以嵌套单位部门。
Cloud Identity 和 Google Workspace 可让您按组织部门应用特定配置，例如许可分配或两步验证。这些设置会自动应用到组织单元中的所有用户，子组织单元也会继承这些设置。因此，组织单元在管理 Cloud Identity 和 Google Workspace 配置方面起着至关重要的作用。
一个用户账号不能同时属于多个单位部门，因此单位部门与群组不同。 虽然单位部门在将配置应用于用户账号时很有用，但不能用于管理访问权限。如需管理访问权限，我们建议您使用群组。
虽然单位部门类似于 Google Cloud 文件夹，但这两个实体的用途不同，并且彼此无关。
受管用户账号
受管用户账号的工作原理与消费者用户账号类似，但前者由 Cloud Identity 或 Google Workspace 账号的管理员完全控制。
受管用户账号的身份由其主电子邮件地址定义。
主电子邮件地址必须使用与添加到 Cloud Identity 或 Google Workspace 账号的主域名、辅助域名或别名域名之一相对应的域名。受管理的用户账号可以有其他别名电子邮件地址和辅助电子邮件地址，但这些地址不会被视为身份，也不能用于登录。例如，如果 Alice 使用 alice@example.com 作为她的主电子邮件地址，并将 ally@example.com 配置为别名电子邮件地址，将 alice@gmail.com 配置为辅助电子邮件地址，则 Alice 只能使用 alice@example.com 进行登录。
受管用户账号包含在单位部门中，可以是任意数量群组的成员。
受管用户账号应由真人用户（而非机器用户）使用。机器用户账号是由应用或虚拟机 (VM) 实例（而非真人）使用的特殊账号。Google Cloud 为机器用户提供服务账号。 （本文档稍后会详细介绍服务账号。）
群组
您可以通过群组将多个用户捆绑在一起。您可以使用群组管理邮寄名单，也可以为多个用户应用共同的访问权限控制或配置。
Cloud Identity 和 Google Workspace 按电子邮件地址（例如 billing-admins@example.com）标识群组。与用户的主电子邮件地址类似，群组电子邮件地址必须使用 Cloud Identity 或 Google Workspace 账号的主域名、辅助域名或别名域名之一。除非将群组用作邮寄名单，否则电子邮件地址无需与邮箱对应。身份验证仍使用用户的电子邮件（而非群组电子邮件），因此用户无法使用群组电子邮件地址登录。
群组可以将以下实体作为成员：
- 用户（受管用户账号或消费者账号）
- 其他群组
- 服务账号
与组织部门不同，群组不会充当容器：
- 用户或群组可以是任意数量群组的成员，而不仅仅是一个群组。
- 删除群组不会删除任何成员用户或群组。
群组可以包含任何 Cloud Identity 或 Google Workspace 账号的成员以及消费者账号。您可以使用禁止组织外部的成员设置，将成员限制为同一 Cloud Identity 或 Google Workspace 账号的用户账号。
外部身份
通过将 Cloud Identity 或 Google Workspace 账号与外部 IdP 联合，您可以让员工使用其现有身份和凭据登录 Google 服务。
在最基本的层面上，联合需要使用 SAML 设置单点登录，从而将 Cloud Identity 或 Google Workspace 中的身份关联到由外部 IdP 管理的身份。如需关联像 alice@example.com 这样的身份并允许其通过单点登录的方式登录 Google，您必须满足以下两个前提条件：
- 您的外部 IdP 必须识别身份
alice@example.com并允许将其用于单点登录。 - 您的 Cloud Identity 或 Google Workspace 账号必须包含一个使用
alice@example.com作为身份的用户账号。此用户账号必须在首次尝试单点登录之前就已存在。
您无需在 Cloud Identity 或 Google Workspace 中手动创建和维护用户账号，只需将基于 SAML 的单点登录与自动用户预配相结合即可自动执行此过程。自动用户预配的概念是将外部权威来源中的所有或部分用户和群组同步到 Cloud Identity 或 Google Workspace。
根据您选择的 IdP，基于 SAML 的单点登录和自动用户预配可能会由同一软件组件处理，也可能需要单独的组件。因此，网域模型区分了“SAML 身份提供商”和“外部权威来源”。
外部 SAML 身份提供商
外部 IdP 是唯一的身份验证系统，可为您的员工提供跨应用的单点登录体验。它位于 Google 外部，因此称为“外部身份提供商”。
当您启用单点登录时，Cloud Identity 或 Google Workspace 会将身份验证决策中继到 SAML IdP。就 SAML 而言，Cloud Identity 或 Google Workspace 充当服务提供方，信任 SAML IdP 代表其验证用户的身份。
每个 Cloud Identity 或 Google Workspace 账号最多可以代表一个外部 IdP。多个 Cloud Identity 或 Google Workspace 账号可以代表不同的 SAML IdP，但单个 Cloud Identity 或 Google Workspace 账号不可能使用多个 SAML IdP。
常用的外部 IdP 包括 Active Directory Federation Services (AD FS)、Azure AD、Okta 或 Ping Identity。
外部权威来源
身份的权威来源是您用来创建、管理和删除员工身份的唯一系统。它位于 Google 外部，因此称为“外部权威来源”。
在外部权威来源中，用户账号和群组可以自动预配到 Cloud Identity 或 Google Workspace。 预配可以由权威来源本身或预配中间件进行处理。
若要使自动用户预配生效，必须为用户预配 SAML IdP 能够识别的身份。如果您在身份之间进行映射（例如将 Cloud Identity 或 Google Workspace 中的身份 alice@example.com 映射到 SAML IdP 中的 u12345@corp.example.com），则 SAML IdP 和预配中间件必须执行相同的映射。
外部用户账号
外部身份提供商假定具有可跟踪名称、特性和配置的用户账号的概念。
权威来源（或预配中间件）应将所有（或部分）外部用户账号预配到 Cloud Identity 或 Google Workspace，以便提供登录体验。在许多情况下，仅将用户特性的一部分（例如电子邮件地址、名字和姓氏）传播到 Cloud Identity 或 Google Workspace 就已足够，这样可以限制数据冗余。
外部群组
如果您的外部 IdP 支持群组的概念，则可以选择将这些群组映射到 Cloud Identity 或 Google Workspace 中的群组。
映射和自动预配群组是可选的，单点登录不需要这两个步骤，但如果您要重复使用现有群组来控制 Google Workspace 或 Google Cloud 中的访问权限，这两个步骤会很有用。
Google Cloud
与其他 Google 服务一样，Google Cloud 依靠 Google 登录对用户进行身份验证。Google Cloud 还与 Google Workspace 和 Cloud Identity 紧密集成，让您能够高效地管理资源。
Google Cloud 引入了组织节点、文件夹和项目的概念。这些实体主要用于管理访问权限和配置，因此它们仅与身份管理略微相关。但是，Google Cloud 还包含其他类型的用户账号：服务账号。服务账号属于项目，其在身份管理中发挥着至关重要的作用。
组织节点
组织是 Google Cloud 资源层次结构中的根节点，也是项目和文件夹的容器。组织可让您按层次结构组织资源，并且对于集中高效地管理资源至关重要。
每个组织都属于一个 Cloud Identity 或 Google Workspace 账号。组织名称派生自相应的 Cloud Identity 或 Google Workspace 账号的主域名。
文件夹
文件夹是 Google Cloud 资源层次结构中的节点，可以包含项目、其他文件夹或两者的组合。您可以使用文件夹对共用相同 Identity and Access Management (IAM) 政策或组织政策的资源进行分组。这些政策会自动应用于文件夹中的所有项目，子文件夹也会继承这些政策。
文件夹与单位部门类似但不相关。 单位部门可帮助您管理用户并为用户应用通用配置或政策，而文件夹可帮助您管理 Google Cloud 项目并为项目应用通用配置或政策。
项目
项目是资源的容器。 项目在管理 API、结算和管理资源访问权限方面发挥着至关重要的作用。
项目与身份管理相关，因为它们是服务账号的容器。
服务账号
“服务账号”（即 Google Cloud 服务账号）是一种特殊类型的用户账号，旨在供应用和其他类型的机器用户使用。
每个服务账号都属于一个 Google Cloud 项目。 与受管用户账号一样，管理员可以完全控制服务账号的生命周期和配置。
服务账号也使用电子邮件地址作为其身份，但与受管用户账号不同，电子邮件地址始终使用 Google 拥有的网域，例如 developer.gserviceaccount.com。
服务账号不参与联合，也没有密码。在 Google Cloud 上，您可以使用 IAM 控制服务账号对计算资源（例如虚拟机 [VM] 或 Cloud Functions 函数）的权限，而无需管理凭据。在 Google Cloud 之外，您可以使用服务账号密钥让应用通过服务账号进行身份验证。
Kubernetes 服务账号
Kubernetes 服务账号是 Kubernetes 的概念，在您使用 Google Kubernetes Engine (GKE) 时相关。与 Google Cloud 服务账号类似，Kubernetes 服务账号供应用（而非真人）使用。
Kubernetes 服务账号可用于在应用调用 Kubernetes 集群的 Kubernetes API 时进行身份验证，但无法在集群外部使用。它们无法被任何 Google API 识别，因此不能替代 Google Cloud 服务账号。
将应用部署为 Kubernetes Pod 时，您可以关联 Pod 与服务账号。 此关联可让应用使用 Kubernetes API，而无需配置或维护证书或其他凭据。
通过使用 Workload Identity，您可以关联 Kubernetes 服务账号与 Google Cloud 服务账号。此关联可让应用也向 Google API 进行身份验证，而无需维护证书或其他凭据。
后续步骤
- 查看我们的身份管理参考架构。