How proxy authentication works in searchguard security plugin?

Search Guard
1

If you think it is a bug report or you have a technical issue, please answer the following questions. For general questions, you can delete these questions.

Elasticsearch version:
7.12.1
Server OS version:
7.4.1708
Kibana version (if relevant):
7.12.1
Browser version (if relevant):
Chrome
Browser OS version (if relevant):

Describe the issue:
We have an SSO for our company and using that I’m passing

user_header: "x-user"
    roles_header: "x-group"

e.g
    user_header: "tong"
    roles_header: "admin"

That’s all changes I have done in configuration and applied using sgadmin.sh, the user tong does not exist in the internal elastic database.

My question is if I’m using proxy authentication does the username I’m passing in user_header: “x-user” needs to exist in the internal database of the elasticsearch? if yes how can I bypass that?

I’m trying to bypass LDAP with our own SSO.
Steps to reproduce:
1.
2.
3.

Expected behavior:

Provide configuration:
elasticsearch/config/elasticsearch.yml
xpack.security.enabled: false
######## Start Search Guard Demo Configuration ########

WARNING: revise all the lines below before you go into production

searchguard.ssl.transport.pemcert_filepath: esnode.pem
searchguard.ssl.transport.pemkey_filepath: esnode-key.pem
searchguard.ssl.transport.pemtrustedcas_filepath: root-ca.pem
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.http.enabled: true
searchguard.ssl.http.pemcert_filepath: esnode.pem
searchguard.ssl.http.pemkey_filepath: esnode-key.pem
searchguard.ssl.http.pemtrustedcas_filepath: root-ca.pem
searchguard.allow_unsafe_democertificates: true
searchguard.allow_default_init_sgindex: true
searchguard.authcz.admin_dn:

  • CN=kirk,OU=client,O=client,L=test, C=de
    searchguard.restapi.roles_enabled: [“SGS_ALL_ACCESS”]
    ######## End Search Guard Demo Configuration ########

elasticsearch/plugins/search-guard-7/sgconfig/sg_config.yml

sg_config:
    dynamic:
        http:
          anonymous_auth_enabled: false
          xff:
            enabled: true
            internalProxies: '103.104.122.8' # Kibana IP
            remoteIpHeader:  'x-forwarded-for'
        authc:
          proxy_auth_domain:
            description: "Authenticate via proxy"
            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

kibana/config/kibana.yml (if relevant)

    searchguard.auth.type: "proxy"
    searchguard.proxycache.user_header: x-proxy-user
    searchguard.proxycache.roles_header: x-proxy-roles
    searchguard.proxycache.proxy_header_ip: "103.104.122.8"
    elasticsearch.requestHeadersWhitelist: [ "Authorization", "sgtenant", "x-forwarded-for", "x-user", "x-group" ]

Provide logs:
Elasticsearch
Kibana (if relevant)

Screenshots (if relevant):

Errors in browser console (if relevant):
{“statusCode”:401,“error”:“Unauthorized”,“message”:“Response Error”}
Additional data:

2

curl --insecure -H “x-proxy-user:admin” -H “x-proxy-roles:admin” -H “x-forwarded-for:103.104.122.8” -X GET https://localhost:9200/_searchguard/authinfo?pretty
Unauthorized

3

kibana.log

{“type”:“response”,“@timestamp”:“2021-07-27T21:22:50+07:00”,“tags”:,“pid”:46792,“method”:“get”,“statusCode”:401,“req”:{“url”:“/”,“method”:“get”,“headers”:{“x-forwarded-for”:“116.109.97.177”,“x-proxy-user”:“admin”,“x-proxy-roles”:“admin”,“host”:“elasticsearch”,“connection”:“close”,“cache-control”:“max-age=0”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9”,“accept-encoding”:“gzip, deflate”,“accept-language”:“vi-VN,vi;q=0.9,fr-FR;q=0.8,fr;q=0.7,en-US;q=0.6,en;q=0.5”},“remoteAddress”:“103.104.122.8”,“userAgent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36”},“res”:{“statusCode”:401,“responseTime”:34,“contentLength”:68},“message”:“GET / 401 34ms - 68.0B”}

5

Hi @tong6462 I managed to reproduce and will investigate this further shortly, seems to be an issue with internalProxies whitelisting.
As a workaround I managed to make it work with below setting instead, but this might not work for your use case, as it whitelists all IPs:

internalProxies: ".*"

6

Thanks.I have fixed it then it’s work

7

Glad to hear it’s resolved for you.
Also wanted to bring your attention to the 3 lines in your kibana.yml:

   searchguard.proxycache.user_header:
   searchguard.proxycache.roles_header:
   searchguard.proxycache.proxy_header_ip:

Proxycache has been deprecated therefore these lines have no impact now and can be safely removed.

Also, I’ve noticed an inconsistency in the above config, which I’m sure was fixed at your end but might cause confusion for other users of the forum:

sg_config.yml lists headers:

config:
     user_header: "x-proxy-user"
     roles_header: "x-proxy-roles"

However the SSO is producing “x-user” and “x-group”.
These need to match up and be whitelisted in kibana.yml under:
elasticsearch.requestHeadersWhitelist
to work correctly.

8

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.