starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Groups passed in an HTTP header are not applied to existing users #7346

New Issue
Closed
opened 2025-12-29 20:22:10 +01:00 by adam · 2 comments
adam commented 2025-12-29 20:22:10 +01:00
Owner
Copy Link

Originally created by @amuckart on GitHub (Dec 13, 2022).

NetBox version

v3.3.9

Python version

3.9

Steps to Reproduce

I'm using Keycloak as an OIDC provider, and using oauth2-proxy and nginx for authentication (though the only bit that's interacting with Netbox is the nginx proxy_pass).

The authentication works fine and oauth2-proxy/nginx send the group list in an X-Groups header.

The groups already exist in Netbox.

To reproduce, clear all cookies from netbox and keycloak and log into netbox. I'm guessing you could fudge this without needing the actual IDAM by setting the headers by hand but I haven't tried.

Nginx config snippet:

  location / {
    auth_request /oauth2/auth;
    error_page 401 = /oauth2/sign_in;

    # pass information via X-User and X-Email headers to backend,
    # requires running with --set-xauthrequest flag
    auth_request_set $user   $upstream_http_x_auth_request_preferred_username;
    auth_request_set $email  $upstream_http_x_auth_request_email;
    auth_request_set $groups $upstream_http_x_auth_request_groups;
    proxy_set_header X-User  $user;
    proxy_set_header X-Email $email;
    proxy_set_header X-Groups $groups;

Headers passed in the request are:

GET / HTTP/1.0
X-User: alasdairmuckart
X-Email: alasdairmuckart@<domain>
X-Groups: netbox_staff,netbox_superuser,sysadmins,users,netbox_user,alasdairmuckart
X-Forwarded-Host: cat-wlgwil-test-netbox1.wgtn.cat-it.co.nz
X-Real-IP: ::ffff:172.17.216.168
X-Forwarded-Proto: https
Host: 127.0.0.1:8001
Connection: close
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-NZ,en;q=0.7,en-US;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://test-netbox1.<domain>/user/profile/
DNT: 1
Cookie: _oauth2_proxy=[DATA REDACTED]
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Sec-GPC: 1

Relevant section of configuration.py

# Keycloak via oauth2-proxy
REMOTE_AUTH_ENABLED = True
REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend'
REMOTE_AUTH_HEADER = 'HTTP_X_USER'
REMOTE_AUTH_AUTO_CREATE_USER = True
REMOTE_AUTH_DEFAULT_GROUPS = ['netbox_user']
REMOTE_AUTH_DEFAULT_PERMISSIONS = {}
REMOTE_AUTH_GROUP_HEADER = 'HTTP_X_GROUPS'
REMOTE_AUTH_GROUP_SYNC_ENABLED = True
REMOTE_AUTH_GROUP_SEPARATOR = ','
REMOTE_AUTH_STAFF_GROUPS = ['netbox_staff']
REMOTE_AUTH_SUPERUSER_GROUPS = ['netbox_superuser']

Expected Behavior

  • When I log into netbox my user's groups are set to the list of groups configured in the IDAM and passed in the configured HTTP header.

Observed Behavior

  • The groups from the HTTP header are only applied to newly-created users or if the user->group mapping has already been made in the admin interface.
  • If the user exists but has no groups, the groups in the IDAM are ignored.
  • If the user exists but has different group(s) than the ones in the HTTP header, the correct ones are very briefly assigned, and then removed leaving the group list empty. Reloading the admin interface at just the right time shows this happening, and the same can be seen in the user's profile.
Originally created by @amuckart on GitHub (Dec 13, 2022). ### NetBox version v3.3.9 ### Python version 3.9 ### Steps to Reproduce I'm using Keycloak as an OIDC provider, and using [oauth2-proxy](https://oauth2-proxy.github.io/oauth2-proxy/) and nginx for authentication (though the only bit that's interacting with Netbox is the nginx proxy_pass). The authentication works fine and oauth2-proxy/nginx send the group list in an `X-Groups` header. The groups already exist in Netbox. To reproduce, clear all cookies from netbox and keycloak and log into netbox. I'm guessing you could fudge this without needing the actual IDAM by setting the headers by hand but I haven't tried. Nginx config snippet: ```text location / { auth_request /oauth2/auth; error_page 401 = /oauth2/sign_in; # pass information via X-User and X-Email headers to backend, # requires running with --set-xauthrequest flag auth_request_set $user $upstream_http_x_auth_request_preferred_username; auth_request_set $email $upstream_http_x_auth_request_email; auth_request_set $groups $upstream_http_x_auth_request_groups; proxy_set_header X-User $user; proxy_set_header X-Email $email; proxy_set_header X-Groups $groups; ``` Headers passed in the request are: ```text GET / HTTP/1.0 X-User: alasdairmuckart X-Email: alasdairmuckart@<domain> X-Groups: netbox_staff,netbox_superuser,sysadmins,users,netbox_user,alasdairmuckart X-Forwarded-Host: cat-wlgwil-test-netbox1.wgtn.cat-it.co.nz X-Real-IP: ::ffff:172.17.216.168 X-Forwarded-Proto: https Host: 127.0.0.1:8001 Connection: close User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-NZ,en;q=0.7,en-US;q=0.3 Accept-Encoding: gzip, deflate, br Referer: https://test-netbox1.<domain>/user/profile/ DNT: 1 Cookie: _oauth2_proxy=[DATA REDACTED] Upgrade-Insecure-Requests: 1 Sec-Fetch-Dest: document Sec-Fetch-Mode: navigate Sec-Fetch-Site: same-origin Sec-Fetch-User: ?1 Sec-GPC: 1 ``` Relevant section of `configuration.py` ```python # Keycloak via oauth2-proxy REMOTE_AUTH_ENABLED = True REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend' REMOTE_AUTH_HEADER = 'HTTP_X_USER' REMOTE_AUTH_AUTO_CREATE_USER = True REMOTE_AUTH_DEFAULT_GROUPS = ['netbox_user'] REMOTE_AUTH_DEFAULT_PERMISSIONS = {} REMOTE_AUTH_GROUP_HEADER = 'HTTP_X_GROUPS' REMOTE_AUTH_GROUP_SYNC_ENABLED = True REMOTE_AUTH_GROUP_SEPARATOR = ',' REMOTE_AUTH_STAFF_GROUPS = ['netbox_staff'] REMOTE_AUTH_SUPERUSER_GROUPS = ['netbox_superuser'] ``` ### Expected Behavior - When I log into netbox my user's groups are set to the list of groups configured in the IDAM and passed in the configured HTTP header. ### Observed Behavior - The groups from the HTTP header are only applied to newly-created users or if the user->group mapping has already been made in the admin interface. - If the user exists but has no groups, the groups in the IDAM are ignored. - If the user exists but has different group(s) than the ones in the HTTP header, the correct ones are very briefly assigned, and then removed leaving the group list empty. Reloading the admin interface at just the right time shows this happening, and the same can be seen in the user's profile.
adam added the type: bugstatus: under review labels 2025-12-29 20:22:10 +01:00
adam closed this issue 2025-12-29 20:22:10 +01:00
adam commented 2025-12-29 20:22:11 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Dec 13, 2022):

I cannot replicate it with the exact config you provided.

What I did:

  • Set X-User header to helloworld.
    • User is created with no groups as expected
  • Set the X-Groups header to netbox_test
    • Press the logout button and on next auth the user is a member of netbox_test
  • Change the X-Groups header to netbox_test2,netbox_test3
    • Press the logout button and on next auth the user is member of netbox_test2 and netbox_test3 but not netbox_test.

Am I misunderstanding anything?

@kkthxbye-code commented on GitHub (Dec 13, 2022): I cannot replicate it with the exact config you provided. What I did: * Set X-User header to helloworld. * * User is created with no groups as expected * Set the X-Groups header to `netbox_test` * * Press the logout button and on next auth the user is a member of `netbox_test` * Change the X-Groups header to `netbox_test2,netbox_test3` * * Press the logout button and on next auth the user is member of netbox_test2 and netbox_test3 but not netbox_test. Am I misunderstanding anything?
adam commented 2025-12-29 20:22:11 +01:00
Author
Owner
Copy Link

@amuckart commented on GitHub (Dec 14, 2022):

Thanks kkthxbye-code. I am not sure what I was screwing up but the logout step seems to have been key and I'm getting the expected behaviour now. Thanks for validating this.

@amuckart commented on GitHub (Dec 14, 2022): Thanks [kkthxbye-code](https://github.com/kkthxbye-code). I am not sure what I was screwing up but the logout step seems to have been key and I'm getting the expected behaviour now. Thanks for validating this.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: under review type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#7346
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?