1

我正在将网守/louketo 设置为浏览器应用程序的反向代理。我将代理部署为 kubernetes pod 中的 sidecar，在同一集群中的其他地方使用 keycloak（但通过公共 URL 访问）。Gatekeeper 位于 nginx 入口的后面，该入口执行 tls 终止。

[我已经尝试过最新的 louketo 版本和 fork oneconcern/keycloak-gatekeeper。有些差异，但问题是一样的，所以我认为这是我的配置的问题。]

网守，无论我如何设置配置，都会读取我领域的发现 url，但不会在登录时重定向。相反，它使用/oauth/authorize路径重定向到我的上游应用程序。我可以手动强制我的应用程序再次重定向到 keycloak，但是从 keycloak 返回时，网守无法识别 cookie，并在重定向循环中捕获我。

似乎我犯了一些简单的配置错误，但我已经为此工作了两天，而且我束手无策。（甚至对 go 代码进行了额外的调试，但还没有对其进行足够的研究以真正知道它在做什么。）

我的配置（尝试了许多不同变体的最佳猜测）：

        - --config=/var/secrets/auth-proxy-keycloak-config.yaml
        - --discovery-url=https://auth.my-domain.com/auth/realms/my-realm
        - --listen=:4000
        - --upstream-url=http://127.0.0.1:3000
        - --redirection-url=https://dev.my-domain.com/
        - --enable-refresh-tokens=true
        - --enable-default-deny=true
        - --resources=uri=/*|roles=developer
        - --resources=uri=/about|white-listed=true
        - --resources=uri=/oauth/*|white-listed=true

入口服务https://dev.my-domain.com并路由到端口 4000，这是身份验证代理边车。它使用 let-encrypt 证书设置，并终止 tls。我不在代理中使用 tls（我应该吗？）。端口 3000 的上游应用程序。Keycloak 位于 auth.my-domain.com。在auth-proxy-keycloak-config.yaml我有加密密钥和client_id。keycloak 客户端是为公共访问和标准流程设置的（因此我认为不需要 client_secret）。我已经摆弄了各种 uri 设置，并且还为 CORS 输入了 web origins "*" 以进行测试。

当我在浏览器中尝试受保护的 url 时，我看到：

no session found in request, redirecting for authorization  {"error": "authentication session not found"}

在代理日志中，它会将我重定向到 /oauth/authorize，而不是https://auth.my-domain.com/auth/realms/my-realm/protocol/openid-connect/auth我认为它应该重定向我的位置。

更新——正如@jan-garaj 在评论中指出的那样，/oauth/*不应该被列入白名单。（我从对其他人答案的一个可能错误的解释中得到了这一点。）然后我不得不使 cookie 不是 http-only，最后解决了这个问题 - Keycloak-gatekeeper: 'aud' claim and 'client_id' do not match。 ..之后它的工作原理！

4

1 回答 1

2

来自 Louketo-proxy 文档：

/oauth/authorize 是身份验证端点，它将生成 OpenID 重定向到提供者

所以重定向是正确的。它是 luketo-proxy 端点。这不是您的应用程序的请求，它将由 louketo-proxy 处理。它将生成另一个重定向到您的 IDP，用户需要登录。

无关：

  • 您确实需要机密的客户端和客户端机密来进行授权代码流
  • CORS 的网络来源“*”仅适用于 http 协议，https 需要明确的来源规范
于 2020-06-27T06:58:43.743 回答