forward_auth
一个专用的(opinionated)指令,它会把请求复制给认证网关,认证网关可以决定是否应该继续处理,或者需要跳转到一个登录页面。
Caddy的reverse_proxy能够向外部服务执行“预检查请求”,但此指令专门针对认证用例定制。它实际上只是使用一个更长、更常见配置(如下)的便捷方式。
此指令会把uri重写后,向配置的上游发出GET请求:
- 如果上游响应
2xx状态码,则允许访问,copy_headers中的头字段会被复制到原始请求,并继续处理。 - 否则,如果上游响应任何其他状态码,则上游响应会被复制回客户端。这个响应通常应包含重定向到认证网关登录页面的内容。
如果这并不完全是你想要的行为,可以以下面的扩展形式为基础,按需自定义。
支持reverse_proxy的所有子指令,并将它们传递给底层的reverse_proxy处理器。
语法
forward_auth [<matcher>] [<upstreams...>] {
uri <to>
copy_headers <fields...> {
<fields...>
}
}
-
<upstreams...> 是要向其发送认证请求的上游(后端)列表。
-
uri 是在发送给上游的请求上设置的URI(路径和查询)。这通常是认证网关的验证端点。
-
copy_headers 是在请求获得成功状态码时,要从响应复制到原始请求的HTTP头字段列表。
可通过
>后接新名称来重命名字段,例如Before>After。如果你更喜欢可读性,也可以使用块来逐行列出所有字段。
由于此指令是反向代理上带有预设行为的包装器,你可以使用reverse_proxy的任何子指令来自定义它。
扩展形式
forward_auth指令等同于以下配置。像Authelia这样的认证网关适合这个预设。如果你的网关不适合,可以借用下面的配置并按需自定义,而不是使用forward_auth快捷方式。
reverse_proxy <upstreams...> {
# 始终使用 GET,避免消耗传入请求的
# 请求体
method GET
# 将 URI 改为认证网关的
# 验证端点
rewrite <to>
# 转发原始方法和 URI,
# 因为它们会在上面被重写;这
# 是对 reverse_proxy 已设置的其他
# X-Forwarded-* 头的补充
header_up X-Forwarded-Method {method}
header_up X-Forwarded-Uri {uri}
# 成功响应时,复制响应头
@good status 2xx
handle_response @good {
# 例如,对每个 copy_headers 字段……
request_header Remote-User {rp.header.Remote-User}
request_header Remote-Email {rp.header.Remote-Email}
}
}
示例
Authelia
在通过反向代理提供你的应用之前,将认证委托给Authelia:
# 提供认证网关本身
auth.example.com {
reverse_proxy authelia:9091
}
# 提供你的应用
app1.example.com {
forward_auth authelia:9091 {
uri /api/authz/forward-auth
copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
}
reverse_proxy app1:8080
}
更多信息,请参阅Authelia文档中与Caddy集成的说明。
Tailscale
将认证委托给Tailscale(目前名为nginx-auth,但它仍可与Caddy一起使用),并使用copy_headers的替代语法来重命名复制的头(注意每个头中的>):
forward_auth unix//run/tailscale.nginx-auth.sock {
uri /auth
header_up Remote-Addr {remote_host}
header_up Remote-Port {remote_port}
header_up Original-URI {uri}
copy_headers {
Tailscale-User>X-Webauth-User
Tailscale-Name>X-Webauth-Name
Tailscale-Login>X-Webauth-Login
Tailscale-Tailnet>X-Webauth-Tailnet
Tailscale-Profile-Picture>X-Webauth-Profile-Picture
}
}