将嵌套身份验证与 Google IAP 结合使用 [英] Using nested authentication with Google IAP

查看:33
本文介绍了将嵌套身份验证与 Google IAP 结合使用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在 Google Cloud Run 上部署了一个使用基本身份验证进行访问的 3rd 方网络应用程序.我还希望通过仅允许组织的 Google 身份验证用户访问来保护端点.这两种方法都使用请求的 Authorization 标头,但我无法使其工作.

我尝试关注 这篇 帖子,在一个字段中提供两个凭据.我的推理是,GCP 应该选择它支持的最强凭据机制——承载——并为 webap 保留基本凭据.我不知道 web 应用程序是否可以处理它,因为 Google 的反向代理已经禁止我访问.

curl "-HAuthorization:bearer ${bearer_token}, basic ${base64_userpw}" https://my-google-endpoint.com

-> 401 未经授权

我也试过 Proxy-Authorization 没有什么不同的结果.curl "-HProxy-Authorization: bearer ${bearer_token}" "-HAuthorization: basic ${base64_userpw}" https://my-google-endpoint.com

有没有办法让嵌套身份验证与 Google 的反向代理一起使用?我能够通过仅提供承载者来绕过反向代理,但自然而然地在服务中碰壁.通过在代理端停用身份验证,我能够使用基本凭据对服务进行身份验证.

附注:我没有使用浏览器访问 web 应用程序,而是使用命令行工具.

解决方案

不能将授权机制与 IAP 混合使用.bearer 关键字之后的所有内容都被视为令牌字符串.

一种解决方案是将您的基本授权 HTTP 标头从使用 Authorization 更改为自定义 HTTP 标头.类似于 X-MyApp-Authorization.然后,您的应用会处理自定义标头以处理基本授权机制.

[更新 2021-08-17]

我原来的回答有部分错误.Google 的解决方案目前已失效.

Cloud Run 是 Google Cloud IAP 的幕后推手.发出请求的客户端可以使用两个 HTTP 授权标头:

  • 授权:<应用程序授权令牌>
  • 代理授权:持有者 IDENTITY_TOKEN>

如果在 Proxy-Authorization 标头中找到有效的 ID 令牌,IAP 会使用它来授权请求​​.授权请求后,IAP 将Authorization 标头传递给您的应用程序,而不处理内容.

从代理授权标头进行身份验证

这意味着 OP 使用 Proxy-Authorization 标头走在正确的轨道上.但是,此功能不起作用.

创建身份令牌:

使用 curl 验证令牌是否适用于需要 Invoker 角色的 Cloud Run 端点:

curl -H "Authorization: Bearer $TOKEN";$端点

那行得通.现在尝试 Proxy-Authorization 标头:

curl -H "Proxy-Authorization: Bearer $TOKEN";$端点

失败并返回 403.

现在尝试两个标题:

curl -H "Proxy-Authorization: Bearer $TOKEN";-H 授权:持有人 $ANOTHER_TOKEN"$端点

失败并显示 401无法验证访问令牌"

gcloud auth 打印身份令牌

我正在使用文档化的方法来使用两个授权标头,但此功能不起作用.

PHP SDK 直到 2021 年 6 月 25 日才添加了代理授权标头支持.我根据 Google 的示例创建了一个测试应用程序.同样的错误也失败了.

2021 年 6 月 25 日补丁

I deployed a 3rd party webapp which uses basic authentication for access on Google Cloud Run. I additionally wanted to protect the endpoint by allowing only Google-authenticated users of the organization access. Both these methods use the Authorization header of the request and I cannot get it to work.

I tried following this post, providing both credentials in one field. My reasoning was, that GCP should select the strongest credential mechanism it supports - bearer - and leave the basic credentials for the webap. I have no idea if the webapp could have dealt with it because Google's reverse proxy already barred my access.

curl "-HAuthorization: bearer ${bearer_token}, basic ${base64_userpw}" https://my-google-endpoint.com

-> 401 Unauthorized

I also tried Proxy-Authorization with no different result. curl "-HProxy-Authorization: bearer ${bearer_token}" "-HAuthorization: basic ${base64_userpw}" https://my-google-endpoint.com

Is there a way to get nested authentication to work with Google's reverse proxy? I was able to get past the reversed proxy by only supplying the bearer but naturally hit the wall at the service. With deactivated authentication on proxy side I was able to authenticate with the service using the basic credentials.

P.S.: I am not using a browser to access the webapp but command line tools.

解决方案

You cannot mix Authorization mechanisms with IAP. Everything after the bearer keyword is considered the token string.

One solution is to change your Basic Authorization HTTP header from using Authorization to a custom HTTP header. Something like X-MyApp-Authorization. Then your app processes the custom header to handle the Basic Authorization mechanism.

[Update 2021-08-17]

My original answer is partially wrong. Google's solution is currently broken.

Cloud Run is behind Google Cloud IAP. The client making a request can use two HTTP Authorization headers:

  • Authorization: <application authorization token>
  • Proxy-Authorization: Bearer <IDENTITY_TOKEN>

If a valid ID token is found in a Proxy-Authorization header, IAP authorizes the request with it. After authorizing the request, IAP passes the Authorization header to your application without processing the content.

Authenticating from Proxy-Authorization Header

This means the OP was on the right track using the Proxy-Authorization header. However, this feature does not work.

Create an Identity Token:

Use curl to verify that the token works with a Cloud Run endpoint that requires the Invoker role:

curl -H "Authorization: Bearer $TOKEN" $endpoint

That works. Now try the Proxy-Authorization header:

curl -H "Proxy-Authorization: Bearer $TOKEN" $endpoint

That fails with a 403.

Now try both headers:

curl -H "Proxy-Authorization: Bearer $TOKEN" -H "Authorization: Bearer $ANOTHER_TOKEN" $endpoint

That fails with 401 "The access token could not be verified"

gcloud auth print-identity-token

I am using documented methods to use two authorization headers, but this feature does not work.

The PHP SDK did not have the proxy-authorization header support added until June 25, 2021. I created a test application from Google's example. That also failed with the same errors.

June 25, 2021 Patch

这篇关于将嵌套身份验证与 Google IAP 结合使用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆