基于代理的身份验证
如果您已经有了单点登录(SSO)解决方案,您可能希望将其用作身份验证后端。
大多数解决方案作为位于 UDB-SX 和安全插件前面的代理运行。如果代理身份验证成功,代理会在 HTTP 头字段中添加(已验证的)用户名及其(已验证的)角色。这些字段的名称取决于您使用的 SSO 解决方案。
然后,安全插件从请求中提取这些 HTTP 头字段,并使用这些值来确定用户的权限。
启用代理检测
要为 UDB-SX 启用代理检测,请在 config.yml 的 xff 部分进行配置:
---
_meta:
type: "config"
config_version: 2
config:
dynamic:
http:
anonymous_auth_enabled: false
xff:
enabled: true
internalProxies: '192\.168\.0\.10|192\.168\.0\.11'
remoteIpHeader: 'x-forwarded-for'
您可以配置以下设置:
| 名称 | 描述 |
|---|---|
enabled |
启用或禁用代理支持。默认值为 false。 |
internalProxies |
包含所有受信任代理 IP 地址的正则表达式。模式 .* 信任所有内部代理。 |
remoteIpHeader |
包含主机名链的 HTTP 头字段名称。默认值为 x-forwarded-for。 |
为了确定请求是否来自受信任的内部代理,安全插件将 HTTP 请求的远程地址与配置的内部代理列表进行比较。如果远程地址不在列表中,插件会将请求视为客户端请求。
启用代理身份验证
在 proxy HTTP 验证器部分配置承载已验证用户名和角色的 HTTP 头字段名称:
proxy_auth_domain:
http_enabled: true
transport_enabled: true
order: 0
http_authenticator:
type: proxy
challenge: false
config:
user_header: "x-proxy-user"
roles_header: "x-proxy-roles"
authentication_backend:
type: noop
| 名称 | 描述 |
|---|---|
user_header |
包含已验证用户名的 HTTP 头字段。默认值为 x-proxy-user。 |
roles_header |
包含以逗号分隔的已验证角色名称列表的 HTTP 头字段。安全插件将在此头字段中找到的角色用作后端角色。默认值为 x-proxy-roles。 |
roles_separator |
角色的分隔符。默认值为 ,。 |
启用扩展代理身份验证
安全插件有一个 proxy 类型的扩展版本,允许您传递额外的用户属性以用于文档级安全。除了 type: extended-proxy 和 attr_header_prefix 外,配置是相同的:
proxy_auth_domain:
http_enabled: true
transport_enabled: true
order: 0
http_authenticator:
type: extended-proxy
challenge: false
config:
user_header: "x-proxy-user"
roles_header: "x-proxy-roles"
attr_header_prefix: "x-proxy-ext-"
authentication_backend:
type: noop
| 名称 | 描述 |
|---|---|
attr_header_prefix |
代理用于提供用户属性的头前缀。例如,如果代理提供 x-proxy-ext-namespace: my-namespace,请在文档级安全查询中使用 ${attr.proxy.namespace}。 |
示例
以下示例在一个三节点 UDB-SX 集群前使用 nginx 代理。为简单起见,我们为 x-proxy-user 和 x-proxy-roles 使用硬编码值。在真实示例中,您将动态设置这些头信息。该示例还包括一个用于扩展代理的注释头。
events {
worker_connections 1024;
}
http {
upstream udbsx {
server node1.example.com:10200;
server node2.example.com:10200;
server node3.example.com:10200;
keepalive 15;
}
server {
listen 8090;
server_name nginx.example.com;
location / {
proxy_pass https://udbsx;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header x-proxy-user test;
proxy_set_header x-proxy-roles test;
#proxy_set_header x-proxy-ext-namespace my-namespace;
}
}
}
相应的最小化 config.yml 如下所示:
---
_meta:
type: "config"
config_version: 2
config:
dynamic:
http:
xff:
enabled: true
internalProxies: '172.16.0.203' # the nginx proxy
authc:
proxy_auth_domain:
http_enabled: true
transport_enabled: true
order: 0
http_authenticator:
type: proxy
#type: extended-proxy
challenge: false
config:
user_header: "x-proxy-user"
roles_header: "x-proxy-roles"
#attr_header_prefix: "x-proxy-ext-"
authentication_backend:
type: noop
重要部分是启用 X-Forwarded-For (XFF) 解析并正确设置内部代理的 IP:
enabled: true
internalProxies: '172.16.0.203' # nginx proxy
在这种情况下,nginx.example.com 运行在 172.16.0.203 上,因此将此 IP 添加到内部代理列表中。请确保将 internalProxies 设置为最少数量的 IP 地址,以便安全插件仅接受来自受信任 IP 的请求。
UDB-SX Dashboards 代理身份验证
要将代理身份验证与 UDB-SX Dashboards 一起使用,最常见的配置是将代理放在 UDB-SX Dashboards 前面,并让 UDB-SX Dashboards 将用户和角色头信息传递给安全插件。
在这种情况下,HTTP 调用的远程地址是 UDB-SX Dashboards 的 IP,因为它直接位于 UDB-SX 前面。将 UDB-SX Dashboards 的 IP 添加到内部代理列表中:
---
_meta:
type: "config"
config_version: 2
config:
dynamic:
http:
xff:
enabled: true
remoteIpHeader: "x-forwarded-for"
internalProxies: '<udbsx-dashboards-ip-address>'
为了将从验证代理添加的用户和角色头信息从 UDB-SX Dashboards 传递到安全插件,请将它们添加到 udbsx_dashboards.yml 中的 HTTP 头允许列表中:
udbsx.requestHeadersAllowlist: ["securitytenant","Authorization","x-forwarded-for","x-proxy-user","x-proxy-roles"]
您还必须在 udbsx_dashboards.yml 中启用身份验证类型:
udbsx_security.auth.type: "proxy"
udbsx_security.proxycache.user_header: "x-proxy-user"
udbsx_security.proxycache.roles_header: "x-proxy-roles"