问题描述
对于我们的Web应用程序，使用Keycloak作为Traefik 1.7之后的IDP，我们目前面临以下问题:
We are currently facing the following problem for our Webapplication using Keycloak as an IDP behind an Traefik 1.7:
Chrome控制台告诉我们:
Chrome console tells us:
Access to manifest at 'https://keycloak.dev.example.com/auth/realms/myrealm/protocol/openid-connect/auth?client_id=myclient&redirect_uri=...' (redirected from 'https://myfrontend.dev.example.com/manifest.json') from origin 'https://myfrontend.dev.example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
在密钥斗篷中，我们为myrealm领域内的客户端myclient设置了Web Origins = *.
In keycloak we set Web Origins = * for client myclient inside the myrealm realm.
我们已经尝试将 https://myfrontend.dev.example.com 设置为Web起源.那没有帮助.
We already tried to set https://myfrontend.dev.example.com as the Web Origins. That did not help.
我们在部署密钥斗篷的名称空间中配置了Ingress.添加注释:
We configured the Ingress inside the namespace where our keycloak is deployed. Adding the annotations:
ingress.kubernetes.io/cors-allow-origin: https://myfrontend.dev.example.com
ingress.kubernetes.io/enable-cors: "true"
它没有帮助.
过去，我们仅使用相同的子域来设置IDP.毫无疑问，这可以防止发生任何CORS问题，但是我们希望将其分开.
In the past we had a setup with the IDP just using the same subdomain. Of corse this will prevent any CORS issues, but we want to seperate this.
关于在何处添加配置以应用CORS相关标头的任何建议?谢谢.
Any suggestions on where to add configuration to apply the CORS-related headers?Thank you.
推荐答案
经过几个小时的分析，不了解此处会发生什么:
After some hours of analysis, not understanding what happens here:
- 将Web Origins设置为*是可以的，而我建议将Web Origins显式设置为正确的Origins，在这里:https://myfrontend.dev.example.com (不像Stuck的回答中那样带/*)
- 如果我们在跨域请求中使用/token端点，则可以正常工作，因为已设置了预期的响应标头
- 但是:这里的问题发生在/auth端点
- Setting the Web Origins to * is ok, while I suggest to set it explicitly to the right origins, here: https://myfrontend.dev.example.com (without the /* as in Stuck's answer)
- If we check the /token endpoint using within an cross-origin request, it works, because the expected response headers are set
- BUT: the probleme here occured with the /auth endpoint
因此，无论遇到此问题的人如何，在10/2020中使用11.x版的Keycloak都根本不支持/auth OpenID-connect OIDC端点上的CORS.这不是OIDC规范的要求，因此Keycloak(和其他工具)在此处不支持CORS.
So, whoever runs into this problem, Keycloak as in 10/2020 with version 11.x does simply not support CORS on the /auth OpenID-connect OIDC endpoint. It is not a requirement from the OIDC specs, so Keycloak (and other tools) do not support CORS here.
如果我们设置了Web Origin并启用了CORS，则它将适用于某些端点，例如/token，但对于某些人而言，例如/auth.这是因为/auth被视为仅用户的终结点，用户将明确请求或将用户重定向到，并且前端不应该以某种方式在后台向中发送请求.
If we set the Web Origin and have CORS enable, it will work for some endpoint, e.g. /token, but for some not, e.g. /auth.This is because /auth is count as a user-only endpoint, a user would explicitly request or a user would be redirected to AND NOT the frontend should somehow send requests in the background to.
我们在应用程序的一部分内实施了错误的工作流程.不是密钥斗篷(或traefik或kubernetes)问题.
We have implemented a wrong workflow inside a part of our application. Not an keycloak (or traefik or kubernetes) problem.
请在此处查看此讨论是否有任何功能更新: https://keycloak.discourse.group/t/authorizationendpoint-dos-not-support-cors/3495
Please check this discussion here for any feature updates:https://keycloak.discourse.group/t/authorizationendpoint-does-not-support-cors/3495
这篇关于Kubernetes上traefik背后的Keycloak CORS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！