Use of tokens via API not using permissions of associated user when remote auto is enabled.

[John Schubert]

On a netbox 2.10.4 system with remote auth enabled, using a token
associated with a user with super-user status, the permissions from
REMOTE_AUTH_DEFAULT_GROUPS is used instead of the permissions from the
associated user of the token. After the API call a user named (null) is
created in the users list. If I give that default group with additional
permissions it works.

Do I need to enable something to force the usage of permissions of the
associated user for the token?

Thanks

-John

[Brian Candler]

Can you show your actual config, especially REMOTE_AUTH_HEADER?

A user named "(null)" is wrong.  You may have specified the wrong setting for REMOTE_AUTH_HEADER, although I'd say it's a bug in Netbox if it permits a missing or empty header.  Try using tcpdump to see what header is actually being sent to Netbox (i.e. tcpdump port 8001 or whatever gunicorn is listening on)

My proxy sends "Remote-User: xxx", using this apache config:

RequestHeader set REMOTE_USER expr=%{REMOTE_USER}

and the corresponding setting in Netbox is REMOTE_AUTH_HEADER = 'HTTP_REMOTE_USER'  (note the "HTTP_" prefix is required)

[John Schubert]

# Remote authentication support
REMOTE_AUTH_ENABLED = True
REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend'
REMOTE_AUTH_HEADER = 'HTTP_X_REMOTE_USER'
REMOTE_AUTH_AUTO_CREATE_USER = True
REMOTE_AUTH_DEFAULT_GROUPS = ['Default_view']
REMOTE_AUTH_DEFAULT_PERMISSIONS = []

This works fine for actual users.

--
You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/df8b1527-b57c-4282-b448-f51376a72452n%40googlegroups.com.

[Brian Candler]

So the question is, is your proxy ever actually sending "X-Remote-User: (null)" as part of the request for that superuser? Only tcpdump will show you.

The reason I suspect that is because Python would say "None" not "(null)"

[John Schubert]

Apache would be sending null. API calls bypass remote auth.

I have been assuming if a token is used, it assumes the identity associated with that token. What I am taking from this is remote_user overrides everything?

Is this a bug, or can I make this a feature request?

Thanks

-John

To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/fc55866c-b2f7-4f52-980e-a5d3c448f11dn%40googlegroups.com.

[Brian Candler]

On Thursday, 4 February 2021 at 16:06:56 UTC jos...@psu.edu wrote:

Apache would be sending null. API calls bypass remote auth.

I'll believe it when I see the tcpdump.

 

I have been assuming if a token is used, it assumes the identity associated with that token. What I am taking from this is remote_user overrides everything?

There is no "token".  There is just a username.  The username is taken verbatim from whichever HTTP header you configured Netbox to look at.  That's all there is.

If this user doesn't currently exist in the Netbox users table, then it is created automatically (if you've set REMOTE_AUTH_AUTO_CREATE_USER = True)

Therefore, if you see a user called "(null)" being created in your database, the most likely explanation is that the HTTP header contained literally "(null)" as its content.

Is this a bug, or can I make this a feature request? 

I see no evidence so far of Netbox not doing what it's been told to do.

[Brian Candler]

Sorry, replied without reading properly.  API calls do indeed use the API token, in which case, the remote auth shouldn't be used.

[Brian Candler]

I've double-checked the production system I have which uses remote auth, and also has API users.  No "(null)" user has been created in the database.  However, the API users are not superusers, and do not have staff status.

If you have a reproducible way to show that an API user who is also a superuser creates a spurious entry in the users table, using a fresh Netbox install and curl, then do please report a bug.

However I'd observe that API client endpoints normally *don't* provide a REMOTE_AUTH user header as well.  Only a trusted HTTP proxy (e.g. upstream Apache or Nginx) would be able to do that.  If an arbitrary API user were able to supply the REMOTE_AUTH header then they'd be able to spoof any login, since the REMOTE_AUTH header is trusted completely.  Do your API users *additionally* authenticate to the proxy?

[Brian Candler]

Google groups is gobbling all further discussion on this topic.  I suggest moving to Github Discussions.