REMOTE_AUTH not getting the username

[dfluff]

Hi,
I'm very new to NetBox, and I want to set it up to use OIDC authentication.

I've got it all working behind Apache. On first load I get bounced over to Google to authenticate and then get redirected back, BUT Netbox is not seeing/honouring the REMOTE_USER. I get the not-yet-logged-in page when I am redirected back, and if I click the Login button I get the standard log in form.

I've put a test.php file in /static containing just phpinfo() and so I can see that REMOTE_USER and the various OIDC variables are being correctly set. I've tried setting the REMOTE_AUTH_HEADER to REMOTE_USER, or OIDC_CLAIM_email but neither have made a difference.

Here's my Netbox config:

# Remote authentication support
REMOTE_AUTH_ENABLED = True
REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend'
REMOTE_AUTH_HEADER = 'REMOTE_USER'
REMOTE_AUTH_AUTO_CREATE_USER = True
REMOTE_AUTH_DEFAULT_GROUPS = []
REMOTE_AUTH_DEFAULT_PERMISSIONS = {}

And here's the relevant part of my Apache config:

OIDCCryptoPassphrase {removed}
OIDCProviderMetadataURL https://accounts.google.com/.well-known/openid-configuration
OIDCClientID {removed}
OIDCClientSecret {removed}
OIDCRedirectURI https://netbox.{removed}/redirect_url/
OIDCScope "openid email"
OIDCOAuthRemoteUserClaim email
OIDCRemoteUserClaim email
<Location />
    AuthType openid-connect
    Require valid-user
</Location>

Can anyone point me to where I might be going wrong? My only hunch is the OIDCRedirectURI. Setting it to the / top level didn't work, but then I found a post (about Apache OIDC in general) stating that it needed to be a path under the top level, but that it didn't matter what that path was, and so used their example of /redirect_url/. Should that URI be something specific, or is this a red-herring and the problem lies elsewhere?

Cheers,
--Dave

[candlerb]

If the header is Remote-User: then you need REMOTE_AUTH_HEADER = 'HTTP_REMOTE_USER' (note the HTTP_ prefix). OIDCRedirectURI can be any path that you like that won't interfere with the application.

Here's my working config. Netbox (v2.11):

REMOTE_AUTH_ENABLED = True
REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend'
REMOTE_AUTH_HEADER = 'HTTP_REMOTE_USER'
REMOTE_AUTH_AUTO_CREATE_USER = True
REMOTE_AUTH_DEFAULT_GROUPS = []
REMOTE_AUTH_DEFAULT_PERMISSIONS = {}

Apache2 (under Ubuntu 18.04):

        # Fix problem with Firefox: # https://github.com/zmartzone/mod_auth_openidc/issues/404
        ErrorDocument 401 " "

        OIDCProviderMetadataURL https://accounts.google.com/.well-known/openid-configuration
        OIDCClientID <SNIP>
        OIDCClientSecret <SNIP>

        OIDCAuthRequestParams hd=mydomain.com
        OIDCRedirectURI /oauth2callback
        OIDCCryptoPassphrase <SNIP>
        OIDCScope "openid email"
        OIDCSessionInactivityTimeout 43200

        # Keep in mind some of the OIDC Providers (OP) don't guarantee the uniqueness of the email claim
        OIDCRemoteUserClaim email
        RequestHeader unset REMOTE_USER
        RequestHeader set REMOTE_USER expr=%{REMOTE_USER}
        # These are probably not needed, but interesting to see
        OIDCPassUserInfoAs json
        OIDCPassClaimsAs headers

        <Location />
                AuthType openid-connect
                Require claim hd:mydomain.com
        </Location>

        <Location /api/>
            <RequireAny>
                AuthType openid-connect
                Require claim hd:mydomain.com
                # Allow access to /api/ with token instead of Google Auth
                # https://httpd.apache.org/docs/2.4/howto/access.html#env
                Require expr "%{HTTP:Authorization} =~ /^Token /"
            </RequireAny>
        </Location>

The hd claim is only if you have a Google Apps managed domain. You don't need to restrict to a managed domain, but if you don't, you're allowing access to anyone with a gmail account. In that case, you probably want to restrict access to specific Google accounts, and/or disable AUTO_CREATE_USER in Netbox. Auto-created users won't be members of any groups unless you set REMOTE_AUTH_DEFAULT_GROUPS, so as long as the default access is no permissions, you're probably OK.

If you don't want unauthorized users even to reach the Netbox front page, you should be able to use Require user x y z or Require claim sub:x sub:y sub:z, or use a groups file (a2enmod authz_groupfile). The following was taken from a different config in a non-Netbox environment:

      <Location />
         AuthType openid-connect
         AuthGroupFile /etc/apache2/groups.txt
         Require group netbox
      </Location>

where groups.txt contains E-mail addresses, if you are using OIDCRemoteUserClaim email:

netbox: foo@example.com bar@example.com

Also, if you don't like the idea of opening up API token authentication to the whole world, then you can allow API clients by source IP address instead:

        <Location /api/>
            <RequireAny>
                AuthType openid-connect
                Require claim hd:mydomain.com
                # List API clients here
                Require ip 192.168.1.100 192.168.1.200
            </RequireAny>
        </Location>

But note that if Require ip matches, then the Google Auth credentials are not passed on (i.e. the REMOTE_USER header). This means you can't have web browser users on those IP addresses, only API clients.

[dsmithbbc]

Perfect - thanks for the detailed reply. Changing the REMOTE_AUTH_HEADER to HTTP_REMOTE_USER wasn't enough to fix the problem, but thanks to being able to look over your working config it looks like the Apache config of

        RequestHeader unset REMOTE_USER
        RequestHeader set REMOTE_USER expr=%{REMOTE_USER}

was also what was missing in my case. Now both of those changes are in place everything is working as expected.

Thanks, also, for pointing out the fact that, as currently configured, anyone with a google account would have access. I had spotted this and intended to turn off the REMOTE_AUTH_AUTO_CREATE_USER once I'd managed to create my own account. Your hint about stopping any access at all to addresses not in a group-file is very useful though, I shall certainly be implementing that!

--Dave