具有 SSO 的 Google 帐号未按预期重定向到 IdP

Question

我一直在尝试以 Google Identity 作为服务提供商并以 ADFS 作为 IdP 来设置 SSO。

我认为我已经正确配置了 ADFS，并且 Cloud Identity 至少部分正确，因为当使用 service.google.com/a/domain.com 的显式组织 URL 时，我可以使用 ADFS SSO 成功登录到 Google Drive 和 Google Groups，因此我相信 SAML 请求/响应工作正常。我还可以确定这是一次成功的 SSO 登录，因为我可以立即以同一用户身份访问其他服务。例如，访问https://drive.google.com/a/domain.com，通过 SSO，然后访问https://console.cloud.google.com立即工作，无需进一步登录。

但是，当通过登录页面直接访问任何服务时（https://accounts.google.com或者https://console.cloud.google.com) 会导致提示输入 Google 用户名（预期行为），然后提示输入 Google 密码（非预期，因为 domain.com 启用了第三方 SSO）。

文档和观看此用户发布的演示几年前表现出了我所期望的行为：

1. 使用权https://console.cloud.google.com
2. 输入用户名/邮箱
3. 重定向至 SSO 页面

步骤 3 会提示输入 Google ID 密码。

我曾尝试使用非超级管理员的测试用户来排除与该特殊角色有关的任何事情，但没有成功。

还有其他人经历过这种行为吗？

干杯。

更新 - 2019 年 11 月 4 日

添加并丰富以下评论，以防有人在我之后遇到类似的问题。希望我不是一个人！

我一直在与 Google 支持人员合作，以了解这些服务的预期行为。这涉及多个部分，我们仍在研究最后一个部分。

最终我们得出的结论是：

a) 没有适用于 console.cloud.google.com 的特定域服务 URL（即没有 /a/domain.com URL）- 已由 Google 工程团队确认

b) 组织超级管理员永远不会被重定向到 IdP 以获取标准服务 URL - 这并不奇怪，但没有很好的记录

c) 设置网络掩码时，服务 URL console.cloud.google.com 的 SSO 实际上已被禁用 - 仍然确认这一点，因为它似乎与网络掩码的目的背道而驰。

总体而言，Google 支持技术人员建议更新部分文档，我对使用 service.google.com（在我的情况下为 console.cloud.google.com）时的网络掩码行为（点 c）的响应提出质疑。目前，文档仅明确说明使用域特定 URL（/a/domain.com URL）时的网络掩码行为。

需要更新的主要文件 -https://support.google.com/a/answer/6369487

Answer 1

我也曾遇到过同样的第三方 IDP 重定向问题。由于我使用了网络掩码，因此我的用户在直接访问 Google 服务（例如 mail.google.com）时不会被重定向到我们的 IDP。阅读您的帖子后，我偶然发现了 Google 的网络映射结果帮助页面：

注意：对于网络掩码设置，目前只有特定于域的服务 URL（例如 service.google.com/a/example.com）会重定向到 SSO 登录页面。

您的用例可能与我的不同，因此这个答案可能不适合您。我只是想在将其推广到我们整个组织之前测试一下 Google 第三方 IDP 身份验证。因此，我使用了网络掩码。鉴于上述简介中阐明的限制，我选择利用 Google 的第三方 IDP 的组织单位和群组分配功能。

1. 我使用组织单位和群组分配功能将根组织单位设置为用户使用 Google 登录。
2. 我清除/禁用了我设置的网络掩码
3. 然后我创建了一个单独的测试 SSOTest SSO组，将我的测试用户分配到该组，并指定该组应使用组织的第三方 SSO 配置文件。

现在，我成功地观察到了预期的重定向到我们的第三方 IDP，当用户在测试 SSOTest SSO我创建的组尝试直接登录 Google 服务。