API user impersonation

[steffenschumacher]

Hey,
So we’re in the process of adopting netbox, and while the UI will be used directly by logged in users, our plan is to do most CRUD via a wrap-around system which manages assets in netbox, but also updates dns, dhcp, aci, config, nsx, monitoring tools etc etc. (looking to use #ns1 dns/dhcp btw)
We’ve been using the ldap module for netbox and a single token for the API, but ideally the changes made via the API would be done so they are recorded as done by the logged in user (via oauth2/Azure AD) in the wrapper system.
In theory this should be possible if Oauth is supported for the API - but I’m not sure it is, even though the netbox UI might support users logging in?
Can someone clarify the options if they exist?

thanks

[candlerb]

I'm pretty sure that API requests can be authenticated either by a token or as a normally logged-in user - since the GUI makes a few API calls via AJAX, e.g. for populating drop-down selectors, and this doesn't allocate tokens to the user.

Therefore, I think that if you stick Netbox behind a HTTP reverse proxy, which implements your OpenID (or whatever) authentication, and use Netbox "external" authentication, it should work - for controlling access both to GUI and API, and hence associating API calls with the real user.

I have Netbox set up that way for normal GUI access (with Apache2 + mod_auth_openidc). At the moment I don't force the API clients to fetch OpenID identity tokens; I have a bypass setup so that if you present an Authorization: token ... then that is used instead. But I don't see in principle why the API clients couldn't use OpenID tokens.

[steffenschumacher]

Right,
So effectively enable the remote_auth_enabled option and have nginx do the authentication, and then netbox will still do authorization based on eg ldap integration?
Or can nginx somehow also pass the netbox roles from the decoded token?
Would it be a major overhaul of netbox to add support for https://django-auth-adfs.readthedocs.io/en/latest/
It reads to be M$ specific, but I also get the impression it’s rfc based, so it should also support other Oauth/open ID connect vendors?

[candlerb]

I do the authorization based on local users/groups in Netbox. I don't know if you can do LDAP group authorization when using external authentication, nor whether you can map any claims in HTTP headers to groups.

I have no idea about how hard it would be to integrate django-auth-adfs. Personally I'd prefer something standard (i.e. OpenID Connect) rather than Microsoft proprietary; if necessary via some middle box like Keycloak.

[jcralbino]

I have a similar use case where I want logged in users to run custom scripts while maintaining their permissions.

As I am making the custom scripts using calls to the api, I plan to make the api call using the token associated with the logged in user. Therefore API Impersonating is used here.

This will have as a prerequisite that all users logged in netbox ( I use ldap authentication) will need to have a token associated. Although the process of creating a remote user entry in netbox is automated when the user logs in first, the creation of the token in netbox is not . So that needs to be handled separately by a script ( checking netbox users and associating a api token to it )

Therefore all custom scripts will need to get first information of logged in user, then the token associated with it. Then running the script will allowed based in the user profile achieving the required API Impersonating behaviour.

I found that authenticating all api calls using the openid via reverse proxy interesting but it will also additional complexity, not justified for my scenarios at least for the moment.
Also it will also tricky to use for custom scripts if we want to perform changes via api.

[candlerb]

Custom scripts typically use the Django ORM directly, rather than the REST API. There are lots of advantages in doing so, including the ability to use database transactions properly.

I'm not sure whether changelogs are made automatically for changes made by custom scripts. If necessary, you can get the details of the user making the request from the Django request object.