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

API User impersonation #6207

New Issue
Closed
opened 2025-12-29 19:38:01 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:38:01 +01:00
Owner
Copy Link

Originally created by @steffenschumacher on GitHub (Mar 14, 2022).

NetBox version

v3.1.9

Feature type

New functionality

Proposed functionality

(This is a second attempt at arguing for this feature - can't help thinking of a particular Einstein quote, but here goes 😏..)
Allow user impersonation for api requests with authorisation override.
Using an http header attribute, eg. “impersonate”=“some-user" and api token, then if the user of the api token is authorised to impersonate users, then the request is authenticated as “some-user”, if this user exists.
Furthermore, if this request has http attribute “impersonate_authorisation”=“false”, then the authorisation privileges of this request will be those of the api token owner instead of the impersonated user - otherwise it will be of the impersonated user.

Use case

We have a homegrown middleware on top of netbox, which enable users to modify assets in netbox in an assisted fashion, and we would prefer if write operations in netbox were done on behalf of users, whom we don’t want to grant direct write access to netbox. Users are sync'ed into netbox via LDAP
While it is possible fetch automatically provisioned tokens from preexisting users and use those, then this option would require netbox write privileges for the users. Privileges we prefer to be read only, so we ensure that only valid modifications are done in netbox (via the assisting middleware and directly by a few netbox admins).
To achieve this, I believe it is required to both be able to impersonate some specific user, and then also to indicate whether authorisation should be done using the impersonated user, or the actual 'system' user who is doing the impersonation.

We could merely use the system user, but then we loose out on most of the brilliant change log functionality in netbox, since all changes will be done by the system user.

Database changes

None

External dependencies

None

Originally created by @steffenschumacher on GitHub (Mar 14, 2022). ### NetBox version v3.1.9 ### Feature type New functionality ### Proposed functionality _(This is a second attempt at arguing for this feature - can't help thinking of a particular Einstein quote, but here goes 😏..)_ **Allow user impersonation for api requests with authorisation override.** Using an http header attribute, eg. `“impersonate”=“some-user"` and api token, then if the user of the api token is authorised to impersonate users, then the request is authenticated as “some-user”, if this user exists. Furthermore, if this request has http attribute `“impersonate_authorisation”=“false”`, then the authorisation privileges of this request will be those of the api token owner instead of the impersonated user - otherwise it will be of the impersonated user. ### Use case We have a homegrown middleware on top of netbox, which enable users to modify assets in netbox in an assisted fashion, and we would prefer if write operations in netbox were done on behalf of users, whom we **don’t want to grant direct write access to netbox**. Users are sync'ed into netbox via LDAP While it is possible fetch automatically provisioned tokens from preexisting users and use those, then this option would require netbox write privileges for the users. Privileges we prefer to be read only, so we ensure that only valid modifications are done in netbox (via the assisting middleware and directly by a few netbox admins). To achieve this, I believe it is required to both be able to impersonate some specific user, and then also to indicate whether authorisation should be done using the impersonated user, or the actual 'system' user who is doing the impersonation. We could merely use the system user, but then we loose out on most of the brilliant change log functionality in netbox, since all changes will be done by the system user. ### Database changes None ### External dependencies None
adam added the type: featurepending closure labels 2025-12-29 19:38:01 +01:00
adam closed this issue 2025-12-29 19:38:01 +01:00
adam commented 2025-12-29 19:38:01 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Mar 14, 2022):

An idea is to add a 'user group' of users that that token is allowed to impersonate ?
That group can be ldap synced, so no extra maintenance there.
Also if no 'impersonate' user is provided, then the token will use the regular assigned user.
The only caveat I see, is that this one token will get a lot of rights to a lot if users. and that might not be something we want..
The FR #8233 might help securing that token, so that it can only be used from specific source ips

@PieterL75 commented on GitHub (Mar 14, 2022): An idea is to add a 'user group' of users that that token is allowed to impersonate ? That group can be ldap synced, so no extra maintenance there. Also if no 'impersonate' user is provided, then the token will use the regular assigned user. The only caveat I see, is that this one token will get a lot of rights to a lot if users. and that might not be something we want.. The FR #8233 might help securing that token, so that it can only be used from specific source ips
adam commented 2025-12-29 19:38:02 +01:00
Author
Owner
Copy Link

@steffenschumacher commented on GitHub (Mar 14, 2022):

Sure - I think fencing in which users that are allowed to be impersonated is a good thing.
The token allowed to impersonate would have privileges to do pretty much anything even without this feature, so that caveat is not specific to this FR..

@steffenschumacher commented on GitHub (Mar 14, 2022): Sure - I think fencing in which users that are allowed to be impersonated is a good thing. The token allowed to impersonate would have privileges to do pretty much anything even without this feature, so that caveat is not specific to this FR..
adam commented 2025-12-29 19:38:02 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 14, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (May 14, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:38:02 +01:00
Author
Owner
Copy Link

@steffenschumacher commented on GitHub (May 14, 2022):

Closing as this proved too complex and niche..

@steffenschumacher commented on GitHub (May 14, 2022): Closing as this proved too complex and niche..
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 pending closure type: feature
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#6207
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?