node.js - Keycloak NodeJS 适配器忽略 X-Forwarded-Proto

Question

keycloak-connect ，即 recommended NodeJS adapter来自 Keycloak 文档，当 protected 应用程序位于 Apache 反向代理后面时，不会考虑 X-Forwarded-Proto header 。

事实上，redirectUri 是这样构建的:

let host = request.hostname;
let headerHost = request.headers.host.split(':');
let port = headerHost[1] || '';
let protocol = request.protocol;*
let hasQuery = ~(request.originalUrl || request.url).indexOf('?');

let redirectUrl = protocol + '://' + host + (port === '' ? '' : ':' + port) + (request.originalUrl || request.url) + (hasQuery ? '&' : '?') + 'auth_callback=1';

request.protocol 由于反向​​代理始终为“http”，因此redirectUri 没有预期的协议(protocol)(HTTPS)。

如果这是故意的而不是错误，那么即使客户端重定向到 HTTPS，在redirectUri 中使用 HTTP 是否存在安全缺陷？难道 token 不能同时暴露吗？

Answer 1

事实证明，这是 protected 应用程序端的配置问题，这也涉及其他 Keycloak 适配器，例如 Java Servlet Filter适配器或 Spring adapter .

默认情况下，任何 protected 应用程序都会忽略 X-Forwarded-Proto header 。

NodeJS

需要配置所使用的 Web 框架(例如 Express)以考虑代理 header 。

对于 express ，the documentation声明应用程序应该信任代理，例如:

app.set('trust proxy', 'loopback');

Java 适配器

对于 Spring，需要做的配置非常少，如 per the docs ，在 application.properties 中:

server.tomcat.remote-ip-header=x-forwarded-for
server.tomcat.protocol-header=x-forwarded-proto 

对于Java Servlet Filter，有以下几种解决方案:

可以将 Tomcat 阀门添加到 server.xml 中:

<Valve className="org.apache.catalina.valves.RemoteIpValve" 
           internalProxies="127.0.0.1" 
           remoteIpHeader="x-forwarded-for" 
           proxiesHeader="x-forwarded-by" 
           protocolHeader="x-forwarded-proto" /> 

也可以在之前Keycloak的过滤器适配器实现一个新的Servlet过滤器，在web.xml中注册，就像this example中一样。 .