本文提供有关将外部身份与 Identity-Aware Proxy (IAP) 而非 Google 账号一起使用的其他信息。
概览
IAP 可控制对您在 Google Cloud 上运行的 App Engine 应用和 Compute Engine 虚拟机的访问权限。它利用用户身份和请求上下文来确定是否应允许用户访问。IAP 是 BeyondCorp 的构件之一，后者是一个让每位员工都能在不借助 VPN 的情况下通过不受信任的网络顺利开展工作的企业安全模型。
默认情况下，IAP 使用 Google 身份和 IAM。通过利用 Identity Platform，您可以使用各种外部身份提供商对用户进行身份验证，例如：
- 电子邮件地址/密码
- OAuth（Google、Facebook、Twitter、GitHub、Microsoft 等）
- SAML
- OIDC
- 电话号码
- 自定义
- 匿名
如果您的应用已经在使用外部身份验证系统，并且将用户迁移到 Google 账号不切实际，那么这将非常有用。
多租户
Identity Platform 多租户最初是为 B2B 方案设计的，其中一家公司向其他公司出售服务。在这些情况下，开发者通常希望将用户群隔离到被隔离的池中。这些孤岛称为租户。
考虑下面的虚构关系图：
在此示例中，Acme 是汽车制造商（代理商），它使用 Identity Platform 向经销商（租户）提供服务。这些经销商又为其客户、员工和承包商提供服务。尽管制造商拥有服务，但是每个经销商可以使用各自的一组身份提供商进行身份验证。用户会话和数据按租户确定范围，因此，如果用户与多个经销商有关系，则每个经销商将分别进行处理。
根据您的使用场景，您可以采用多种方式来构建租户层次结构。
没有租户
仅在需要隔离资源时才需要多租户。并非所有应用都具有此要求。例如，如果您只有一个 App Engine 应用，并且想阻止对网络外部所有用户的访问权限，则无需多租户。默认情况下，Identity Platform 按项目存储用户并对其进行身份验证，因此在这种情况下不需要其他配置。
另一个示例是一家拥有数家子公司的综合企业。即使每个子公司都有自己的托管身份验证系统（使用 OIDC 或 SAML），所有员工也可能共享相同的高级福利，例如医疗保健、假期和工资。在这种情况下，在项目级层进行身份验证就足够了。
每项资源一个租户
默认情况下，非租户 Identity Platform 令牌在项目级层有效。从理论上讲，这意味着用户可以向一项 IAP 资源进行身份验证，然后使用令牌访问同一项目中的另一服务。这存在安全隐患。
为了防止令牌泄露，请通过为每个 IAP 分配自己的租户来隔离该 IAP。在特定于租户的上下文中生成的令牌仅对该特定租户有效。如果用户尝试访问使用其他租户的另一个 IAP 资源，系统会要求他们再次进行身份验证。
每项资源多个租户
一个 IAP 资源可以有多个与之关联的租户。
当用户访问资源时，您可以使用多个选项来确定要使用的租户。例如，您可以提示用户首先输入他们的电子邮件，然后以编程方式找到与电子邮件地址的网域匹配的租户。或者，您可以显示一个列出所有有效租户的界面，并要求用户选择一个。
用户可以属于具有不同访问权限级别的多个租户。虽然您无法使用 IAM 来管理具有外部身份的访问权限控制，但由 IAP 生成的 JSON 网络令牌会带有来自 Identity Platform ID 令牌的声明，并且应用可以基于这些声明过滤访问权限。
多租户场景的一个示例是雇员福利公司，该公司有许多客户共享一个网站门户。用户访问门户时，他们首先会选择所在的公司（租户），然后使用其公司凭据向其雇主使用的任何提供商进行身份验证。