Remote authentication, behind caddy and cloudflare zero access

[nanocat-net]

Hello!

I have a netbox 3.4.7 behind a Caddy reverse-proxy. The whole thing is behind a Cloudflare Zero Access reverse proxy, using Google Workspace as the IdP.

I can't figure out how to make remote authentication work and I am running out of ideas to troubleshoot it!

I have the following configuration in my configuration.py:

REMOTE_AUTH_ENABLED = True
REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend'
REMOTE_AUTH_HEADER = 'Cf-Access-Authenticated-User-Email'

REMOTE_AUTH_AUTO_CREATE_USER = True
REMOTE_AUTH_DEFAULT_GROUPS = []
REMOTE_AUTH_DEFAULT_PERMISSIONS = {}

.. and when I visit https://my-netbox/, after successfully authenticating with the Cloudflare Zero Access thing, it takes me to the netbox login page.

• I've edited the gunicorn.py file to log the value of the Cf-Access-Authenticated-User-Email header, and it logs the correct value (my email address).
• I have logged the value of settings.REMOTE_AUTH_ENABLED and it outputs True.
• I've checked the output of a tcpdump -i lo -nn -s0 -A tcp port 8001 while making a request, and I can see that my Cf-Access-Authenticated-User-Email header is correctly set, and being passed to the app.
• I've tried with a user that already exists in the Django user page, and I've tried with one that doesn't already exist
• I've tried manually setting a value for REMOTE_USER and HTTP_REMOTE_USER using the header_up feature in Caddy, and verified that gunicorn is seeing those values correctly

Here's my Caddyfile just for reference:

https://my-netbox {
        log {
                output file /var/log/caddy/access.log
        }

        route /static/* {
                uri strip_prefix /static
                root * /opt/netbox/netbox/static
                file_server
        }

        @notStatic not path /static/*

        tls {
                dns cloudflare xxxxxxxx
                client_auth {
                        mode require_and_verify
                        trusted_ca_cert_file /etc/ssl/certs/origin-pull-ca.pem
                }
        }

        reverse_proxy @notStatic localhost:8001 {
                # ... things I've tried ...
                #header_up Cf-Access-Authenticated-User-Email "foo@bar.bar"
                #header_up +HTTP_REMOTE_USER "foo@bar.bar"
                #header_up +REMOTE_USER "foo@bar.bar"
        }

        file_server
}

.. but I still end up on the login page.

Can anyone give me some help with troubleshooting this? Has anyone else faced this? Where might I look to find the problem? Am I testing it correctly?

Thanks for reading! <3

[kkthxbye-code]

https://docs.netbox.dev/en/stable/configuration/remote-authentication/#remote_auth_header

When remote user authentication is in use, this is the name of the HTTP header which informs NetBox of the currently authenticated user. For example, to use the request header X-Remote-User it needs to be set to HTTP_X_REMOTE_USER. (Requires REMOTE_AUTH_ENABLED.)

[nanocat-net]

AHHHHHHH ... ok. I had this:

REMOTE_AUTH_HEADER = 'Cf-Access-Authenticated-User-Email'

... but I had to munge that string to this ...

REMOTE_AUTH_HEADER = 'HTTP_CF_ACCESS_AUTHENTICATED_USER_EMAIL'

.. prepending HTTP_, and converting the - to _. I also capitalised it but idk if that's important.

Do you think this needs to be described more obviously in the doc? It would have helped me if there was a clearer outline of how to modify that string.

[kkthxbye-code]

I personally don't think it is needed, but you are free to create a documentation issue and suggest a concrete change.

[nanocat-net]

Thanks a bunch for your quick help, @kkthxbye-code, it saved my sanity :-)

[mtinberg]

REMOTE_AUTH_HEADER = 'HTTP_CF_ACCESS_AUTHENTICATED_USER_EMAIL' .. prepending HTTP_, and converting the - to _. I also capitalised it but idk if that's important. This is a general webserver thing, headers are passed to CGIs as Environment variables, and servers maintain compatibility with that style even when using WSGI, FCGI, etc. to communicate with the appserver. Passing arbitrary Environment variables to applications can greatly change their behavior which is a security risk (eg. PATH, LD_PRELOAD, many others) so to make sure you can't override the Environment for any program/library which is a child of the web request (eg. bash, ld, libc, whatever), arbitrary header variables are pre-pended with HTTP_ and normalized so they never conflict. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison Message ID: ***@***.***>