External authentication #1912

@jeremystretch commented on GitHub (Aug 8, 2018):

It sounds like this should be folded into #1989. The idea also needs to be fleshed out a lot more:

What are the proposed headers?
How do you handle user creation and deletion?
Illustrate how an existing tool would employ this functionality to authenticate a user
Any conflicts between this and the existing UI/API authentication

@jeremystretch commented on GitHub (Aug 8, 2018): It sounds like this should be folded into #1989. The idea also needs to be fleshed out a lot more: * What are the proposed headers? * How do you handle user creation and deletion? * Illustrate how an existing tool would employ this functionality to authenticate a user * Any conflicts between this and the existing UI/API authentication

adam commented

@awlx commented on GitHub (Aug 9, 2018):

Yep, sounds like those two could be solved together.

What are the proposed headers?
Most common seem to be REMOTE_USER and Authorization. Maybe it would be useful to have some other headers to pass E-Mail address or something.
Or the way Graylog does it with configurable Headers:
http://docs.graylog.org/en/2.4/pages/users_and_roles/external_auth.html#single-sign-on
How do you handle user creation and deletion?
I would propose to just add any existing user and no automatic deletion process in Netbox itself. Since nobody without external could log into Netbox anyway and a few users shouldn't slow down Netbox.
Other solution is to not create the user at all and just work with the forwarded permissions but I think this needs a bigger code change?
Illustrate how an existing tool would employ this functionality to authenticate a user
Icinga2 and Graylog already have the ability to do so. See here:
https://www.icinga.com/docs/icingaweb2/latest/doc/05-Authentication/#external-authentication
http://docs.graylog.org/en/2.4/pages/users_and_roles/external_auth.html#single-sign-on
Any conflicts between this and the existing UI/API authentication.
That is a good question I cannot answer at the moment. Basically the code needs to skip the login page of the UI when it detects the header and the option to do external auth is enabled in the config. Maybe we should also add a variable to only allow certain hosts to pass these strings otherwise it could add some security issues if we just accept the REMOTE_USER header from everywhere ;).

@awlx commented on GitHub (Aug 9, 2018): Yep, sounds like those two could be solved together. - What are the proposed headers? Most common seem to be REMOTE_USER and Authorization. Maybe it would be useful to have some other headers to pass E-Mail address or something. Or the way Graylog does it with configurable Headers: http://docs.graylog.org/en/2.4/pages/users_and_roles/external_auth.html#single-sign-on - How do you handle user creation and deletion? I would propose to just add any existing user and no automatic deletion process in Netbox itself. Since nobody without external could log into Netbox anyway and a few users shouldn't slow down Netbox. Other solution is to not create the user at all and just work with the forwarded permissions but I think this needs a bigger code change? - Illustrate how an existing tool would employ this functionality to authenticate a user Icinga2 and Graylog already have the ability to do so. See here: https://www.icinga.com/docs/icingaweb2/latest/doc/05-Authentication/#external-authentication http://docs.graylog.org/en/2.4/pages/users_and_roles/external_auth.html#single-sign-on - Any conflicts between this and the existing UI/API authentication. That is a good question I cannot answer at the moment. Basically the code needs to skip the login page of the UI when it detects the header and the option to do external auth is enabled in the config. Maybe we should also add a variable to only allow certain hosts to pass these strings otherwise it could add some security issues if we just accept the REMOTE_USER header from everywhere ;).

adam commented

@rsepulvedacl commented on GitHub (Aug 17, 2018):

Grafana has a very useful way to authenticate users. I'm writing a proxy based in PHP and cURL and it's working very well.

I'm using SimpleSAMLphp to authenticate users when they try to connect to Grafana through this proxy. Once authenticated, the proxy passes some user's data to Grafana through the headers.

You can see some documentation from Grafana here: http://docs.grafana.org/tutorials/authproxy/.

I'd like to see something similar into Netbox. 😃

@rsepulvedacl commented on GitHub (Aug 17, 2018): Grafana has a very useful way to authenticate users. I'm writing a proxy based in PHP and cURL and it's working very well. I'm using SimpleSAMLphp to authenticate users when they try to connect to Grafana through this proxy. Once authenticated, the proxy passes some user's data to Grafana through the headers. You can see some documentation from Grafana here: http://docs.grafana.org/tutorials/authproxy/. I'd like to see something similar into Netbox. 😃

adam commented

@cimnine commented on GitHub (Aug 17, 2018):

What are the proposed headers?

I think the exact names should be configurable.

Any conflicts between this and the existing UI/API authentication.

Additionally to checking the authentication cookie, Netbox would also need to check for the header.
But I could see problems with the API, as it relies on headers for authentication.

@cimnine commented on GitHub (Aug 17, 2018): > What are the proposed headers? I think the exact names should be configurable. > Any conflicts between this and the existing UI/API authentication. Additionally to checking the authentication cookie, Netbox would also need to check for the header. But I could see problems with the API, as it relies on headers for authentication.

adam commented

2025-12-29 17:20:21 +01:00

@jeremystretch commented on GitHub (Aug 22, 2018):

I would propose to just add any existing user and no automatic deletion process in Netbox itself.

The user also needs to be assigned permissions and/or groups in order to have any write access.

Other solution is to not create the user at all and just work with the forwarded permissions but I think this needs a bigger code change?

A valid user must be created in the database. This is a requirement of the framework and schema.

@jeremystretch commented on GitHub (Aug 22, 2018): > I would propose to just add any existing user and no automatic deletion process in Netbox itself. The user also needs to be assigned permissions and/or groups in order to have any write access. > Other solution is to not create the user at all and just work with the forwarded permissions but I think this needs a bigger code change? A valid user must be created in the database. This is a requirement of the framework and schema.

adam commented

@awlx commented on GitHub (Aug 23, 2018):

The user also needs to be assigned permissions and/or groups in order to have any write access.

Maybe if the group which is forwarded matches an existing group in Netbox, we could work with those permissions? Otherwise just create the user with a default group (configurable).

@awlx commented on GitHub (Aug 23, 2018): > The user also needs to be assigned permissions and/or groups in order to have any write access. Maybe if the group which is forwarded matches an existing group in Netbox, we could work with those permissions? Otherwise just create the user with a default group (configurable).

adam commented

2025-12-29 17:20:21 +01:00

@globoudou commented on GitHub (Oct 2, 2018):

I'm on similar project, trying to use MS Kerberos Auth with Netbox. Globally it works with the following configuration :

reverse proxy apache 2.4.6 perform the kerb auth on /login url as follow :
AuthType GSSAPI
GssapiCredStore /etc/keytab
Require valid-user
RewriteEngine On
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
RewriteRule "^(.*)$" "/"
RequestHeader set KAUTHUSER "%{RU}e" env=RU
RequestHeader unset Authorization
add django RemoteUser in netbox/settings.py :
AUTHENTICATION_BACKENDS = [ 'django.contrib.auth.backends.RemoteUserBackend', ]
MIDDLEWARE = ( ... , 'django.contrib.auth.middleware.PersistentRemoteUserMiddleware', ... )
change REMOTE_USER with KAUTHUSER in django/contrib/auth/middleware.py :
header = "HTTP_KAUTHUSER"

In reverse-proxy configuration we can't deal with REMOTE_USER, because django is looking for a system variable, not an http header. This is the reason why apache rewrite it to KAUTHUSER http header.

Forcing the authentication in Netbox (LOGIN_REQUIRED = True), it works as expected. The user's samaccountname@REALM must be provisioned in Netbox, and the SSO is working.

The problem is when the user try to use the "logout" button. The redirect scheme is :
/logout/ ==302==> / ==302==> /login/?next=/ ==500
It failed with error 500 :
_thread._localobject as no attribute changed_objects in netbox/extras/middleware.py line 28
After that I must restart the Netbox instance to log again.

I don't understand what is the problem...

@globoudou commented on GitHub (Oct 2, 2018): I'm on similar project, trying to use MS Kerberos Auth with Netbox. Globally it works with the following configuration : - reverse proxy apache 2.4.6 perform the kerb auth on /login url as follow : `AuthType GSSAPI` `GssapiCredStore /etc/keytab` `Require valid-user` `RewriteEngine On` `RewriteCond %{LA-U:REMOTE_USER} (.+)` `RewriteRule . - [E=RU:%1]` `RewriteRule "^(.*)$" "/"` `RequestHeader set KAUTHUSER "%{RU}e" env=RU` `RequestHeader unset Authorization` - add django RemoteUser in netbox/settings.py : `AUTHENTICATION_BACKENDS = [ 'django.contrib.auth.backends.RemoteUserBackend', ]` `MIDDLEWARE = ( ... , 'django.contrib.auth.middleware.PersistentRemoteUserMiddleware', ... )` - change REMOTE_USER with KAUTHUSER in django/contrib/auth/middleware.py : `header = "HTTP_KAUTHUSER"` In reverse-proxy configuration we can't deal with REMOTE_USER, because django is looking for a system variable, not an http header. This is the reason why apache rewrite it to KAUTHUSER http header. Forcing the authentication in Netbox (`LOGIN_REQUIRED = True`), it works as expected. The user's samaccountname@REALM must be provisioned in Netbox, and the SSO is working. The problem is when the user try to use the "logout" button. The redirect scheme is : `/logout/ ==302==> / ==302==> /login/?next=/ ==500` It failed with error 500 : `_thread._localobject as no attribute changed_objects` in netbox/extras/middleware.py line 28 After that I must restart the Netbox instance to log again. I don't understand what is the problem...

adam commented

2025-12-29 17:20:21 +01:00

@cimnine commented on GitHub (Oct 2, 2018):

PerssitentRemoteUserMiddleware

Not sure if typo on Github or in your config, but this should probably be PersistentRemoteUserMiddleware, as per Documentation (Using Remote User on Login Pages Only).

@cimnine commented on GitHub (Oct 2, 2018): > PerssitentRemoteUserMiddleware Not sure if typo on Github or in your config, but this should probably be `PersistentRemoteUserMiddleware`, as per [Documentation (Using Remote User on Login Pages Only)](https://docs.djangoproject.com/en/2.1/howto/auth-remote-user/#using-remote-user-on-login-pages-only).

adam commented

@globoudou commented on GitHub (Oct 2, 2018):

PerssitentRemoteUserMiddleware

Not sure if typo on Github or in your config, but this should probably be PersistentRemoteUserMiddleware, as per Documentation (Using Remote User on Login Pages Only).

Yes... error on keyboard... it was correct in my conf.

@globoudou commented on GitHub (Oct 2, 2018): > > PerssitentRemoteUserMiddleware > > Not sure if typo on Github or in your config, but this should probably be `PersistentRemoteUserMiddleware`, as per [Documentation (Using Remote User on Login Pages Only)](https://docs.djangoproject.com/en/2.1/howto/auth-remote-user/#using-remote-user-on-login-pages-only). Yes... error on keyboard... it was correct in my conf.

adam commented

@DanSheps commented on GitHub (Jan 4, 2019):

Just to add on here, I would love if Duo was supported.

@DanSheps commented on GitHub (Jan 4, 2019): Just to add on here, I would love if Duo was supported.

adam commented

@cimnine commented on GitHub (Jan 4, 2019):

You would only be able to do this using a OIDC, OAuth or SAML reverse proxy, for example the Keycloak Security Proxy. That's as far as the proposed implementation would go.

@cimnine commented on GitHub (Jan 4, 2019): You would only be able to do this using a OIDC, OAuth or SAML reverse proxy, for example the [Keycloak Security Proxy][ksp]. That's as far as the proposed implementation would go. [ksp]: https://www.keycloak.org/docs/3.2/server_installation/topics/proxy.html

adam commented

@rsepulvedacl commented on GitHub (Jan 5, 2019):

I could use Shibboleth on Apache, doing the following changes in the NetBox code:

I modified the file /opt/netbox/netbox/netbox/settings.py, adding the following lines:

MIDDLEWARE = (
[...]
    'utilities.middleware.CustomRemoteUser', # I added this line at the end of the list
)
[...]
AUTHENTICATION_BACKENDS = [ 'django.contrib.auth.backends.RemoteUserBackend', ] # I added this line at the end of the file

I also added the following lines at the end of /opt/netbox/netbox/utilities/middleware.py:

from django.contrib.auth.middleware import RemoteUserMiddleware

class CustomRemoteUser(RemoteUserMiddleware):
    header = 'HTTP_REMOTE_USER'

In the file /opt/netbox/netbox/netbox/configuration.py, I changed to False the following line:

LOGIN_REQUIRED = False

You can also use another external authentication method, changing the header if necessary, and you can use redirections in Apache for /login and /logout URL's.

These changes are based on @globoudou's comment.

@rsepulvedacl commented on GitHub (Jan 5, 2019): I could use Shibboleth on Apache, doing the following changes in the NetBox code: I modified the file `/opt/netbox/netbox/netbox/settings.py`, adding the following lines: ```python MIDDLEWARE = ( [...] 'utilities.middleware.CustomRemoteUser', # I added this line at the end of the list ) [...] AUTHENTICATION_BACKENDS = [ 'django.contrib.auth.backends.RemoteUserBackend', ] # I added this line at the end of the file ``` I also added the following lines at the end of `/opt/netbox/netbox/utilities/middleware.py`: ```python from django.contrib.auth.middleware import RemoteUserMiddleware class CustomRemoteUser(RemoteUserMiddleware): header = 'HTTP_REMOTE_USER' ``` In the file `/opt/netbox/netbox/netbox/configuration.py`, I changed to `False` the following line: ```python LOGIN_REQUIRED = False ``` You can also use another external authentication method, changing the header if necessary, and you can use redirections in Apache for `/login` and `/logout` URL's. These changes are based on @globoudou's comment.

adam commented

@awlx commented on GitHub (Jan 9, 2019):

@rsepulvedacl I tried to reproduce your setup on v2.5.2 but for some reason it is not working at all.

Am I missing a step from your description? I changed everything you mentioned and added the following to my nginx config (for now it's static for tests).

proxy_hide_header Authorization; proxy_set_header HTTP_REMOTE_USER 'netbox';

The user netbox exists and is able to login if I change everything back to the previous state.

@awlx commented on GitHub (Jan 9, 2019): @rsepulvedacl I tried to reproduce your setup on v2.5.2 but for some reason it is not working at all. Am I missing a step from your description? I changed everything you mentioned and added the following to my nginx config (for now it's static for tests). ` proxy_hide_header Authorization; proxy_set_header HTTP_REMOTE_USER 'netbox'; ` The user netbox exists and is able to login if I change everything back to the previous state.

adam commented

@rsepulvedacl commented on GitHub (Jan 11, 2019):

@awlx, try it again without the HTTP_ prefix:

proxy_hide_header Authorization;
proxy_set_header REMOTE_USER 'netbox';

You could be really passing HTTP_HTTP_REMOTE_USER to NetBox with your settings. If for some reason, this doesn't work, change the header settings in both: nginx and /opt/netbox/netbox/utilities/middleware.py, but you should preserve the HTTP_ prefix in this last file.

I only tested this with Apache, using Shibboleth. The setting I used on Apache is the following:

RequestHeader set REMOTE_USER expr=%{REMOTE_USER}

You can also try with or without quotes around the user name. Good luck!

@rsepulvedacl commented on GitHub (Jan 11, 2019): @awlx, try it again without the `HTTP_` prefix: ``` proxy_hide_header Authorization; proxy_set_header REMOTE_USER 'netbox'; ``` You could be really passing `HTTP_HTTP_REMOTE_USER` to NetBox with your settings. If for some reason, this doesn't work, change the header settings in both: nginx and `/opt/netbox/netbox/utilities/middleware.py`, but you should preserve the `HTTP_` prefix in this last file. I only tested this with Apache, using Shibboleth. The setting I used on Apache is the following: ``` RequestHeader set REMOTE_USER expr=%{REMOTE_USER} ``` You can also try with or without quotes around the user name. Good luck!

adam commented

@rsepulvedacl commented on GitHub (Jan 11, 2019):

@awlx, I don't know nginx very well, but I found some settings that could be useful here:
https://developer.okta.com/blog/2018/08/28/nginx-auth-request#bonus-who-logged-in

@rsepulvedacl commented on GitHub (Jan 11, 2019): @awlx, I don't know nginx very well, but I found some settings that could be useful here: https://developer.okta.com/blog/2018/08/28/nginx-auth-request#bonus-who-logged-in

adam commented

@aficustree commented on GitHub (Jan 24, 2019):

@awlx , what did you end up getting to work? I need to do something similar but instead use OAUTH2. I was going to use the nginx oauth2 proxy and then make the changes to middleware/settings/configuration.py as above. It looks like that plugin pulls the UPN of the auth'd user to $upstream_http_x_auth_request_user which I'd assume we set as the REMOTE_USER header. Waiting on the app to be enabled by our directory team but curious if you ended up getting your use-case working.

@aficustree commented on GitHub (Jan 24, 2019): @awlx , what did you end up getting to work? I need to do something similar but instead use OAUTH2. I was going to use the [nginx oauth2 proxy](https://github.com/pusher/oauth2_proxy) and then make the changes to middleware/settings/configuration.py as above. It looks like that plugin pulls the UPN of the auth'd user to $upstream_http_x_auth_request_user which I'd assume we set as the REMOTE_USER header. Waiting on the app to be enabled by our directory team but curious if you ended up getting your use-case working.

adam commented

https://gist.github.com/leoluk/16d91ec22d833945c7ac7ed2b3b05a27

@leoluk commented on GitHub (Jan 24, 2019):

We ended up implementing a custom OAuth provider via social_django by using a custom settings.py file.

If you want to try something similar, maybe this helps:

Hoping for a proper upstream hook.

@leoluk commented on GitHub (Jan 24, 2019): We ended up implementing a custom OAuth provider via social_django by using a custom settings.py file. If you want to try something similar, maybe this helps: https://gist.github.com/leoluk/16d91ec22d833945c7ac7ed2b3b05a27 Hoping for a proper upstream hook.

adam commented

@aficustree commented on GitHub (Jan 24, 2019):

very clean set of monkey patches. well done. almost see how this could indeed be generalized into a proper extensible authentication framework.

@aficustree commented on GitHub (Jan 24, 2019): very clean set of monkey patches. well done. almost see how this could indeed be generalized into a proper extensible authentication framework.

adam commented

@aficustree commented on GitHub (Feb 14, 2019):

@leoluk , curious, followed your gist using the AzureAD social Django backend but how do I actually trigger the backend to fire? I see the custom url as ^oauth/ but the login page doesn't seem to hit it and if I just goto localhost/oauth/ I get a 404 with not matching the pattern

^oauth/ ^login/(?P<backend>[^/]+)/$ [name='begin']
^oauth/ ^complete/(?P<backend>[^/]+)/$ [name='complete']
^oauth/ ^disconnect/(?P<backend>[^/]+)/$ [name='disconnect']
^oauth/ ^disconnect/(?P<backend>[^/]+)/(?P<association_id>\d+)/$ [name='disconnect_individual']

feel like I'm close but just missing something obvious.

my backends are set as follows:

AUTHENTICATION_BACKENDS = (
    'social_core.backends.azuread_tenant.AzureADTenantOAuth2',
    'django.contrib.auth.backends.ModelBackend',
)

@aficustree commented on GitHub (Feb 14, 2019): @leoluk , curious, followed your gist using the AzureAD social Django backend but how do I actually trigger the backend to fire? I see the custom url as ^oauth/ but the login page doesn't seem to hit it and if I just goto localhost/oauth/ I get a 404 with not matching the pattern ``` ^oauth/ ^login/(?P<backend>[^/]+)/$ [name='begin'] ^oauth/ ^complete/(?P<backend>[^/]+)/$ [name='complete'] ^oauth/ ^disconnect/(?P<backend>[^/]+)/$ [name='disconnect'] ^oauth/ ^disconnect/(?P<backend>[^/]+)/(?P<association_id>\d+)/$ [name='disconnect_individual'] ``` feel like I'm close but just missing something obvious. my backends are set as follows: ```python AUTHENTICATION_BACKENDS = ( 'social_core.backends.azuread_tenant.AzureADTenantOAuth2', 'django.contrib.auth.backends.ModelBackend', ) ```

adam commented

@leoluk commented on GitHub (Feb 14, 2019):

Something like LOGIN_URL = '/oauth/login/azuread/' should take care of redirecting you to the proper login page (you would have to check the Django Social docs on how exactly the backend is called).

@leoluk commented on GitHub (Feb 14, 2019): Something like `LOGIN_URL = '/oauth/login/azuread/'` should take care of redirecting you to the proper login page (you would have to check the Django Social docs on how exactly the backend is called).

adam commented

@aficustree commented on GitHub (Feb 14, 2019):

ah thanks, that was the tip I needed to look at the social Django code and discovered I should have used oauth/login/azuread-tenant-oauth2/

@aficustree commented on GitHub (Feb 14, 2019): ah thanks, that was the tip I needed to look at the [social Django](https://github.com/python-social-auth/social-core/blob/master/social_core/backends/azuread_tenant.py) code and discovered I should have used `oauth/login/azuread-tenant-oauth2/`

adam commented

@aficustree commented on GitHub (Feb 15, 2019):

for some reason the login button doesn't seem to pick up the LOGIN_URL changes. No idea why but it just keeps with the regular login page. It works if I go direct to the URL but not if I click the login button.

@aficustree commented on GitHub (Feb 15, 2019): for some reason the login button doesn't seem to pick up the LOGIN_URL changes. No idea why but it just keeps with the regular login page. It works if I go direct to the URL but not if I click the login button.

adam commented

@bluikko commented on GitHub (Jun 10, 2019):

Should the modifications in https://github.com/digitalocean/netbox/issues/2328#issuecomment-451677322 work at 2.5.13?

I have authentication at Apache working but Netbox does not seem to do anything with those changes - the user is not with admin rights and the "login" feature works as normal.

@bluikko commented on GitHub (Jun 10, 2019): Should the modifications in https://github.com/digitalocean/netbox/issues/2328#issuecomment-451677322 work at 2.5.13? I have authentication at Apache working but Netbox does not seem to do anything with those changes - the user is not with admin rights and the "login" feature works as normal.

adam commented

@rsepulvedacl commented on GitHub (Jun 10, 2019):

@bluikko, the modifications should work. Please consider that this method won't make any changes to login and logout buttons. You should consider to create a redirection and/or use rewrite on Apache.

It's been a long time since I implemented this, so I don't remember whether users are created automatically or not, but I remember that users won't be administrators automatically, unless you make some more improvements to this monkey patch or decide to make them administrators by hand.

@rsepulvedacl commented on GitHub (Jun 10, 2019): @bluikko, the modifications should work. Please consider that this method won't make any changes to login and logout buttons. You should consider to create a redirection and/or use rewrite on Apache. It's been a long time since I implemented this, so I don't remember whether users are created automatically or not, but I remember that users won't be administrators automatically, unless you make some more improvements to this monkey patch or decide to make them administrators by hand.

adam commented

@bluikko commented on GitHub (Jun 11, 2019):

@rsepulvedacl I see. Thanks. Unfortunately it is a problem for me if the user permissions would need to be manually managed.

I hope the developers would consider this enhancement request and integrate it properly with LDAP.

@bluikko commented on GitHub (Jun 11, 2019): @rsepulvedacl I see. Thanks. Unfortunately it is a problem for me if the user permissions would need to be manually managed. I hope the developers would consider this enhancement request and integrate it properly with LDAP.

adam commented

@davidc commented on GitHub (Jul 8, 2019):

I don't think bloating Netbox away from its core functionality is helpful or maintainable or a good use of development time, nor a wise decision as messing up authentication/authorisation is potentially very dangerous.

Leave authentication to the web server front-ends which already have plenty of options available, in a mature state of development.

For example, why on earth would someone devote the huge amount of effort to implementing SAML authentication in Netbox (#1677) instead of simply using e.g. Apache2 with mod_auth_mellon in front (as I do). Same for #118.

The options are countless and, no matter how many are implemented in Netbox, there will always be calls for more, so why even go down this route?

But, Netbox does needs to have better support for already-externally-authorised users:

Respect the headers (that the administrator has explicitly defined in Netbox configuration) for already-authorised users.
A way to automatically create the Netbox internal user when a new already-authorised user is detected. The admin should be able to specify in the config file what Netbox groups such a user will be added to.
If external auth is in use, disable internal login/logout pages and allow customisation of the target URL of login/logout links (or remove the login/logout links entirely at the administrator's option).
Documentation on how to configure this, which should be plainly obvious for anyone looking for "another way to auth to Netbox". And documentation on how to bootstrap this process - i.e. how to create or rename an existing admin user to their SSO username.

I have implemented https://github.com/netbox-community/netbox/issues/2328#issuecomment-451677322 and it works fine for 1, but it should be a configuration option rather than an edit to core files that will be lost on update. Then the "loose ends" 2-4 should be implemented.

@davidc commented on GitHub (Jul 8, 2019): I don't think bloating Netbox away from its core functionality is helpful or maintainable or a good use of development time, nor a wise decision as messing up authentication/authorisation is potentially very dangerous. Leave authentication to the web server front-ends which already have plenty of options available, in a mature state of development. For example, why on earth would someone devote the huge amount of effort to implementing SAML authentication in Netbox (#1677) instead of simply using e.g. Apache2 with mod_auth_mellon in front (as I do). Same for #118. The options are countless and, no matter how many are implemented in Netbox, there will always be calls for more, so why even go down this route? But, Netbox **does** needs to have better support for already-externally-authorised users: 1. Respect the headers (that the administrator has explicitly defined in Netbox configuration) for already-authorised users. 2. A way to automatically create the Netbox internal user when a new already-authorised user is detected. The admin should be able to specify in the config file what Netbox groups such a user will be added to. 3. If external auth is in use, disable internal login/logout pages and allow customisation of the target URL of login/logout links (or remove the login/logout links entirely at the administrator's option). 4. Documentation on how to configure this, which should be plainly obvious for anyone looking for "another way to auth to Netbox". And documentation on how to bootstrap this process - i.e. how to create or rename an existing admin user to their SSO username. I have implemented https://github.com/netbox-community/netbox/issues/2328#issuecomment-451677322 and it works fine for 1, but it should be a configuration option rather than an edit to core files that will be lost on update. Then the "loose ends" 2-4 should be implemented.

adam commented

@leoluk commented on GitHub (Jul 8, 2019):

The nice thing about Django is that is has a large ecosystem of high quality authentication backends which can easily be used with Netbox, like in the snippet above or my openshift-netbox role: https://github.com/leoluk/openshift-netbox/blob/master/openshift/netbox/openshift_auth.py

These don't belong in the core, but a well-defined set of hooks for users to configure their own authentication would solve most of these use cases. In my particular case, these are the only modifications made:

Overwriting the logout URL such that, in addition to terminating the user session, the user gets logged out of an external IdP (https://github.com/leoluk/openshift-netbox/blob/master/openshift/netbox/openshift_auth.py)
For any login provider which uses callbacks, the callback URL needs to be accessible before the user is logged in. Right now, this requires a modification to LoginRequiredMiddleware and the root URLs (https://github.com/leoluk/openshift-netbox/blob/master/openshift/netbox/openshift_middleware.py and https://github.com/leoluk/openshift-netbox/blob/master/openshift/netbox/openshift_urls.py).
Various extra settings.py configurations to load the provider, enable and configure it (https://github.com/leoluk/openshift-netbox/blob/master/openshift/netbox/settings.py).

I agree with @davidc that HTTP headers are the best approach for "generic" authentication.

@leoluk commented on GitHub (Jul 8, 2019): The nice thing about Django is that is has a large ecosystem of high quality authentication backends which can easily be used with Netbox, like in the snippet above or my openshift-netbox role: https://github.com/leoluk/openshift-netbox/blob/master/openshift/netbox/openshift_auth.py These don't belong in the core, but a well-defined set of hooks for users to configure their own authentication would solve most of these use cases. In my particular case, these are the only modifications made: - Overwriting the logout URL such that, in addition to terminating the user session, the user gets logged out of an external IdP (https://github.com/leoluk/openshift-netbox/blob/master/openshift/netbox/openshift_auth.py) - For any login provider which uses callbacks, the callback URL needs to be accessible before the user is logged in. Right now, this requires a modification to LoginRequiredMiddleware and the root URLs (https://github.com/leoluk/openshift-netbox/blob/master/openshift/netbox/openshift_middleware.py and https://github.com/leoluk/openshift-netbox/blob/master/openshift/netbox/openshift_urls.py). - Various extra settings.py configurations to load the provider, enable and configure it (https://github.com/leoluk/openshift-netbox/blob/master/openshift/netbox/settings.py). I agree with @davidc that HTTP headers are the best approach for "generic" authentication.

adam commented

@tombastianello commented on GitHub (Sep 13, 2019):

If anyone is interested in being able to use pass-through authentication form an authentication proxy such as pusher/oauth2_proxy, I've created a custom image build here: https://gitlab.com/tom.bastianello/netbox-proxy-auth

The changes are minimal and it captures the email of the user authenticated by the proxy.

@tombastianello commented on GitHub (Sep 13, 2019): If anyone is interested in being able to use pass-through authentication form an authentication proxy such as **pusher/oauth2_proxy**, I've created a custom image build here: [https://gitlab.com/tom.bastianello/netbox-proxy-auth](url) The changes are minimal and it captures the email of the user authenticated by the proxy.

adam commented

@bluikko commented on GitHub (Sep 13, 2019):

@tombastianello I am definitely interested in this. Does your patch require manual creation of users in Netbox (for each REMOTE_USER account) or no additional users are needed in Netbox?

Clicking your link goes to a wrong place.

Edit: just took a look at it. Can the variable be changed? REMOTE_USER is the standard one in my opinion but I'm not familiar with oauth2 and never saw the "PREAUTH_COOKIE" var before.

Also, what is the purpose of the login.html file? My use case for this is Kerberos/GSSAPI so a login page will never be needed.

Respectfully, Netbox should support this out of box. The earlier discussion shows that it might not be that complex at basic level; but maybe it is more complex than a few lines if manually creating the users in Netbox would not be needed. I'd be fine with mapping all preauthenticated users to admin.

@bluikko commented on GitHub (Sep 13, 2019): @tombastianello I am definitely interested in this. Does your patch require manual creation of users in Netbox (for each REMOTE_USER account) or no additional users are needed in Netbox? Clicking your link goes to a wrong place. Edit: just took a look at it. Can the variable be changed? REMOTE_USER is the standard one in my opinion but I'm not familiar with oauth2 and never saw the "PREAUTH_COOKIE" var before. Also, what is the purpose of the `login.html` file? My use case for this is Kerberos/GSSAPI so a login page will never be needed. Respectfully, Netbox should support this out of box. The earlier discussion shows that it might not be that complex at basic level; but maybe it is more complex than a few lines if manually creating the users in Netbox would not be needed. I'd be fine with mapping all preauthenticated users to admin.

adam commented

@tombastianello commented on GitHub (Sep 13, 2019):

@bluikko The authentication proxy adds a cookie (containing basic user details like their email) for the specified domain the to the client browser, when you are setting up said proxy, you have the option to choose the name of the cookie to use, the PREAUTH_COOKIE environment variable tells the netbox authentication module what cookie to look for.

The login.html file is only there so that the user gets a message (most of the time very brief) that their credentials are being checked. I didn't want to re-work netbox too much so that it was easy to maintain and little changes had to be made.

Lastly, users don't need to be added manually, they are automatically added to netbox with a blank password (no password is technically needed because the application is already hidden behind the authentication proxy).

If you need any more help with running it in kubernetes I can provide an example template for the deployment and service/ingress.

@tombastianello commented on GitHub (Sep 13, 2019): @bluikko The authentication proxy adds a cookie (containing basic user details like their email) for the specified domain the to the client browser, when you are setting up said proxy, you have the option to choose the name of the cookie to use, the **PREAUTH_COOKIE** environment variable tells the netbox authentication module what cookie to look for. The `login.html` file is only there so that the user gets a message (most of the time very brief) that their credentials are being checked. I didn't want to re-work netbox too much so that it was easy to maintain and little changes had to be made. Lastly, users don't need to be added manually, they are automatically added to netbox with a blank password (no password is technically needed because the application is already hidden behind the authentication proxy). If you need any more help with running it in kubernetes I can provide an example template for the deployment and service/ingress.

adam commented

@bluikko commented on GitHub (Sep 13, 2019):

@tombastianello It sounds a lot like what I need.

If I understand correctly PREAUTH_COOKIE is similar to the REMOTE_USER variable. That contains the logon name of the preauthenticated user when using mod_auth_gssapi or mod_auth_kerberos. But that variable is not base64-encoded. Example from my use case:

REMOTE_USER=test.user@DOMAIN.CORP.COMPANY.TLD

I could probably disable the base64-decoding myself and change the variable name.

I will definitely look at testing your code (in the coming weeks when there's time for this). I'm not using Docker for NetBox but it seems straightforward enough.

Thanks.

@bluikko commented on GitHub (Sep 13, 2019): @tombastianello It sounds a lot like what I need. If I understand correctly `PREAUTH_COOKIE` is similar to the `REMOTE_USER` variable. That contains the logon name of the preauthenticated user when using `mod_auth_gssapi` or `mod_auth_kerberos`. But that variable is not base64-encoded. Example from my use case: ``` REMOTE_USER=test.user@DOMAIN.CORP.COMPANY.TLD ``` I could probably disable the base64-decoding myself and change the variable name. I will definitely look at testing your code (in the coming weeks when there's time for this). I'm not using Docker for NetBox but it seems straightforward enough. Thanks.

adam commented

@tombastianello commented on GitHub (Sep 13, 2019):

@bluikko The base64 encoding/decoding is a valid point, I've just updated the code with a new variable to enable/disable that. Give it a go and if you have any issues let me know and I'll include the changes.

@tombastianello commented on GitHub (Sep 13, 2019): @bluikko The base64 encoding/decoding is a valid point, I've just updated the code with a new variable to enable/disable that. Give it a go and if you have any issues let me know and I'll include the changes.

adam commented

@sdktr commented on GitHub (Oct 15, 2019):

Hi Tom, can you provide the kubernetes based example you’re referring to above? Thanks!

@sdktr commented on GitHub (Oct 15, 2019): Hi Tom, can you provide the kubernetes based example you’re referring to above? Thanks!

adam commented

@tombastianello commented on GitHub (Nov 6, 2019):

Hi Tom, can you provide the kubernetes based example you’re referring to above? Thanks!

Hi @sdktr,
Sorry for the delay, example deployment and ingress can be found here:
https://gitlab.com/tom.bastianello/netbox-proxy-auth/tree/master/examples/kubernetes

If anyone needs help adding this to netbox directly, let me know and I'd be happy to help, I can potentially clean up the code and submit a pull request. @jeremystretch

@tombastianello commented on GitHub (Nov 6, 2019): > Hi Tom, can you provide the kubernetes based example you’re referring to above? Thanks! Hi @sdktr, Sorry for the delay, example deployment and ingress can be found here: https://gitlab.com/tom.bastianello/netbox-proxy-auth/tree/master/examples/kubernetes If anyone needs help adding this to netbox directly, let me know and I'd be happy to help, I can potentially clean up the code and submit a pull request. @jeremystretch

adam commented

@CrackerJackMack commented on GitHub (Dec 29, 2019):

I have a working docker, kubernetes, nginx+oauth2_proxy and netbox related patches working so it is optionally enabled. How would you like these pull requests? One per feature? All in one? My works are based on v2.6.9 but I'm sure I could port them to develop.

@CrackerJackMack commented on GitHub (Dec 29, 2019): I have a working docker, kubernetes, nginx+[oauth2_proxy](https://github.com/pusher/oauth2_proxy) and netbox related patches working so it is optionally enabled. How would you like these pull requests? One per feature? All in one? My works are based on v2.6.9 but I'm sure I could port them to develop.

adam commented

@sdktr commented on GitHub (Dec 30, 2019):

I have a working docker, kubernetes, nginx+oauth2_proxy and netbox related patches working so it is optionally enabled. How would you like these pull requests? One per feature? All in one? My works are based on v2.6.9 but I'm sure I could port them to develop.

I think only the netbox -part is desired in this repo. A netbox PR including documentation on how to enable/configure it. Maybe a seperate issue in the 'netbox-docker' repo outlining how you did it with your k8s based setup?

@sdktr commented on GitHub (Dec 30, 2019): > I have a working docker, kubernetes, nginx+[oauth2_proxy](https://github.com/pusher/oauth2_proxy) and netbox related patches working so it is optionally enabled. How would you like these pull requests? One per feature? All in one? My works are based on v2.6.9 but I'm sure I could port them to develop. I think only the netbox -part is desired in this repo. A netbox PR including documentation on how to enable/configure it. Maybe a seperate issue in the 'netbox-docker' repo outlining how you did it with your k8s based setup?

adam commented

@bootc commented on GitHub (Dec 30, 2019):

@CrackerJackMack I'd like to have your K8s components please to integrate into bootc/netbox-chart. This is a setup I would very much like to be able to use and a scenario I'd like to have in the chart.

@bootc commented on GitHub (Dec 30, 2019): @CrackerJackMack I'd like to have your K8s components please to integrate into [bootc/netbox-chart](https://github.com/bootc/netbox-chart). This is a setup I would very much like to be able to use and a scenario I'd like to have in the chart.

adam commented

@jeremystretch commented on GitHub (Jan 16, 2020):

I've been going over the discussion here and in other issues, trying to determine the scope for this change. I think it boils down to two different approaches:

Extend NetBox's internal authentication to recognize a certain HTTP header (e.g. REMOTE-USER) set by a reverse proxy (nginx or Apache) and assign the current user based on its value.
Install a Django app to provide external authentication (similar to how django-auth-ldap works currently).

As the second case should be handled by #3351 (plugin support), this issue should focus on the first case: HTTP header-based authentication. Of course, a complete implementation of this feature entails not only user assignment, but user creation and group assignment (for granting of permissions) as well.

There are some good references linked in the chat above, such as Grafana's implementation, but we need to thoroughly define the login/logout workflow before any serious progress can be made.

@jeremystretch commented on GitHub (Jan 16, 2020): I've been going over the discussion here and in other issues, trying to determine the scope for this change. I think it boils down to two different approaches: 1. Extend NetBox's internal authentication to recognize a certain HTTP header (e.g. `REMOTE-USER`) set by a reverse proxy (nginx or Apache) and assign the current user based on its value. 2. Install a Django app to provide external authentication (similar to how `django-auth-ldap` works currently). As the second case should be handled by #3351 (plugin support), this issue should focus on the first case: HTTP header-based authentication. Of course, a complete implementation of this feature entails not only user assignment, but user creation and group assignment (for granting of permissions) as well. There are some good references linked in the chat above, such as [Grafana's implementation](https://grafana.com/docs/grafana/latest/auth/auth-proxy/), but we need to thoroughly define the login/logout workflow before any serious progress can be made.

adam commented

@jeremystretch commented on GitHub (Feb 18, 2020):

It's surprising this hasn't gotten any more feedback in the past month. We really need to work on scoping this out fully and defining a working model for this to be implemented. Would anyone like to volunteer to take the lead? We need at least a few solid use cases for reference I think.

@jeremystretch commented on GitHub (Feb 18, 2020): It's surprising this hasn't gotten any more feedback in the past month. We really need to work on scoping this out fully and defining a working model for this to be implemented. Would anyone like to volunteer to take the lead? We need at least a few solid use cases for reference I think.

adam commented

@kobayashi commented on GitHub (Feb 19, 2020):

If no objection here, I handle this to implement a header for proxy authentication.

@kobayashi commented on GitHub (Feb 19, 2020): If no objection here, I handle this to implement a header for proxy authentication.

adam commented

@kobayashi commented on GitHub (Feb 19, 2020):

Extend NetBox's internal authentication to recognize a certain HTTP header (e.g. REMOTE-USER) set by a reverse proxy (nginx or Apache) and assign the current user based on its value.

Install a Django app to provide external authentication (similar to how django-auth-ldap works currently).

For this issue, agree to focus on the first one to authenticate with a proxy like apache or nginx in front of netbox.

@kobayashi commented on GitHub (Feb 19, 2020): > 1. Extend NetBox's internal authentication to recognize a certain HTTP header (e.g. `REMOTE-USER`) set by a reverse proxy (nginx or Apache) and assign the current user based on its value. > 2. Install a Django app to provide external authentication (similar to how `django-auth-ldap` works currently). For this issue, agree to focus on the first one to authenticate with a proxy like apache or nginx in front of netbox.

adam commented

@CrackerJackMack commented on GitHub (Feb 21, 2020):

I don't have time for an official PR (sorry). But I'm are using https://github.com/pusher/oauth2_proxy ~~with https://github.com/divio/django-simple-sso~~ with some very minor alterations to netbox.

There is also https://github.com/agoragames/nginx-google-oauth as well as https://github.com/cloudflare/nginx-google-oauth which have different headers.

For hosted solutions there is https://teams.cloudflare.com/access/index.html and https://cloud.google.com/iap/

I'll see if I can post a gist of the patch this weekend. Maybe a good starting point for a more generic solution to support more auth proxies.

edit: mispoke about django-simple-sso, this was a previous attempt

@CrackerJackMack commented on GitHub (Feb 21, 2020): I don't have time for an official PR (sorry). But I'm are using https://github.com/pusher/oauth2_proxy ~with https://github.com/divio/django-simple-sso~ with some very minor alterations to netbox. There is also https://github.com/agoragames/nginx-google-oauth as well as https://github.com/cloudflare/nginx-google-oauth which have different headers. For hosted solutions there is https://teams.cloudflare.com/access/index.html and https://cloud.google.com/iap/ I'll see if I can post a gist of the patch this weekend. Maybe a good starting point for a more generic solution to support more auth proxies. edit: mispoke about django-simple-sso, this was a previous attempt

adam commented

@bluikko commented on GitHub (Feb 22, 2020):

@CrackerJackMack maybe I am wrong but at least some of your links seem to do authentication with external sources. I believe that this issue is about using the "preauthentication" headers set by the web server?

For example I am using GSSAPI where the web server sets REMOTE_USER HTTP header and all NetBox would need to do for basic support is to check for presence of that header.

It would be good if NetBox could be told to automatically give administrator rights to the users. Several web apps that I administer can split authentication and authorization so that authentication is done based on the HTTP headers and then authorization is done in the web app, for example by using LDAP to check group memberships of the user in REMOTE_USER.
This would be great but I'd even be happy if just the basic case would be supported.

@bluikko commented on GitHub (Feb 22, 2020): @CrackerJackMack maybe I am wrong but at least some of your links seem to _do_ authentication with external sources. I believe that this issue is about using the "preauthentication" headers set by the web server? For example I am using GSSAPI where the web server sets REMOTE_USER HTTP header and all NetBox would need to do for basic support is to check for presence of that header. It would be good if NetBox could be told to automatically give administrator rights to the users. Several web apps that I administer can split authentication and authorization so that authentication is done based on the HTTP headers and then authorization is done in the web app, for example by using LDAP to check group memberships of the user in REMOTE_USER. This would be great but I'd even be happy if just the basic case would be supported.

adam commented

@CrackerJackMack commented on GitHub (Feb 22, 2020):

@bluikko You are only partially wrong I believe. They specifically exist to auth, and set HTTP headers. All the links I provided act as a trusted reverse proxy which you can trust that authentication and authorization was handled prior to setting and sending the HTTP headers. In the simplest, most crude examples:

Google/Cloudflare ---> nginx ---> gunicorn(django)

nginx ---> oauth2_proxy ---> gunicorn(django)

nginx --> ngx_http_auth_request_module[---> oauth2_proxy] --> gunicorn(django)

Depending on the solution and if it's configurable with that solution, all of them set HTTP headers with we inherently trust. This choice is based entirely on this snippet from https://docs.djangoproject.com/en/3.0/howto/auth-remote-user/

Warning

Be very careful if using a RemoteUserMiddleware subclass with a custom HTTP header. You must be sure that your front-end web server always sets or strips that header based on the appropriate authentication checks, never permitting an end-user to submit a fake (or “spoofed”) header value. Since the HTTP headers X-Auth-User and X-Auth_User (for example) both normalize to the HTTP_X_AUTH_USER key in request.META, you must also check that your web server doesn’t allow a spoofed header using underscores in place of dashes.

This warning doesn’t apply to RemoteUserMiddleware in its default configuration with header = 'REMOTE_USER', since a key that doesn’t start with HTTP_ in request.META can only be set by your WSGI server, not directly from an HTTP request header.

If you need more control, you can create your own authentication backend that inherits from RemoteUserBackend and override one or more of its attributes and methods.

The not-pr-worthy gist I promised. It also includes a more complicated nginx auth_request module setup to defer to oauth2_proxy using a side request.
https://gist.github.com/CrackerJackMack/8f0e84b2d6ca981f4262b5fa5136375c

@CrackerJackMack commented on GitHub (Feb 22, 2020): @bluikko You are only partially wrong I believe. They specifically exist to auth, and set HTTP headers. All the links I provided act as a trusted reverse proxy which you can trust that authentication and authorization was handled prior to setting and sending the HTTP headers. In the simplest, most crude examples: ``` Google/Cloudflare ---> nginx ---> gunicorn(django) nginx ---> oauth2_proxy ---> gunicorn(django) nginx --> ngx_http_auth_request_module[---> oauth2_proxy] --> gunicorn(django) ``` Depending on the solution and if it's configurable with that solution, all of them set HTTP headers with we inherently trust. This choice is based entirely on this snippet from https://docs.djangoproject.com/en/3.0/howto/auth-remote-user/ >Warning >Be very careful if using a RemoteUserMiddleware subclass with a custom HTTP header. You must be sure that your front-end web server always sets or strips that header based on the appropriate authentication checks, never permitting an end-user to submit a fake (or “spoofed”) header value. Since the HTTP headers X-Auth-User and X-Auth_User (for example) both normalize to the HTTP_X_AUTH_USER key in request.META, you must also check that your web server doesn’t allow a spoofed header using underscores in place of dashes. >This warning doesn’t apply to RemoteUserMiddleware in its default configuration with header = 'REMOTE_USER', since a key that doesn’t start with HTTP_ in request.META can only be set by your WSGI server, not directly from an HTTP request header. > If you need more control, you can create your own authentication backend that inherits from RemoteUserBackend and override one or more of its attributes and methods. The not-pr-worthy gist I promised. It also includes a more complicated nginx auth_request module setup to defer to oauth2_proxy using a side request. https://gist.github.com/CrackerJackMack/8f0e84b2d6ca981f4262b5fa5136375c

adam commented

@sdktr commented on GitHub (Feb 23, 2020):

Hi @CrackerJackMack , shouldn’t the ‘user normalization’ be part of the frontend proxy’s job? I think it opens up a whole can of possible rules that end up beging maintained in Netbox on how to interpret the header?

@sdktr commented on GitHub (Feb 23, 2020): Hi @CrackerJackMack , shouldn’t the ‘user normalization’ be part of the frontend proxy’s job? I think it opens up a whole can of possible rules that end up beging maintained in Netbox on how to interpret the header?

adam commented

@CrackerJackMack commented on GitHub (Feb 23, 2020):

@sdktr Funny enough, the proxies would argue that it's the application's problem to clean up things if desired 😆

This is one of those annoying external authentication issues everyone likes to gloss over in their "Have them login with facebook!" blog posts. The issue isn't a issue with external authentication on a technical level, but more so that you have no idea how the login system works externally or what it will return in the headers and/or cookie data.

There are some agreed upon standards to help adoption, but they aren't a hard rule.

First, we have to choose an upstream auth service and see what header is does, or can send back to us. The auth service could do oauth2, SAML, openid connect, LDAP, ... We don't really know how users actually login to the service. Depending on the external authentication the headers could be a combination or just a single set of the following headers

X-Goog-Authenticated-User-Email & X-Goog-Authenticated-User-Id
X-Forwarded-User & X-Forwarded-Email
X-Auth-Request-User and X-Auth-Request-Email response
Cf-Access-Authenticated-User-Email & Cf-Access-Jwt-Assertion 2
Whatever header you want to foward
skipping JWT validation
skipping referrer userinfo only headers
skipping azure or SAML examples for now

Next problem. Are the username and email forwarded to us usable as is? Well that's really dependent on the downstream application (netbox & administrator). If usernames are intended to be emails then you just use X-Forwarded-Email and ignore -User for example. are the username and email prefixed as to help identify the upstream: accounts.google.com:username@gsuite.domain.com?

I had a 3rd point but I can't recall what it is right now.

@CrackerJackMack commented on GitHub (Feb 23, 2020): @sdktr Funny enough, the proxies would argue that it's the application's problem to clean up things if desired 😆 This is one of those annoying external authentication issues everyone likes to gloss over in their "Have them login with facebook!" blog posts. The issue isn't a issue with external authentication on a technical level, but more so that you have no idea how the login system works externally or what it will return in the headers and/or cookie data. There are some agreed upon standards to help adoption, but they aren't a hard rule. First, we have to choose an upstream auth service and see what header is does, or can send back to us. The auth service could do oauth2, SAML, openid connect, LDAP, ... We don't really know how users actually login to the service. Depending on the external authentication the headers could be a combination or just a single set of the following headers * [X-Goog-Authenticated-User-Email & X-Goog-Authenticated-User-Id](https://cloud.google.com/iap/docs/identity-howto) * [X-Forwarded-User & X-Forwarded-Email](https://pusher.github.io/oauth2_proxy/configuration) * [X-Auth-Request-User and X-Auth-Request-Email response](https://pusher.github.io/oauth2_proxy/configuration) * [Cf-Access-Authenticated-User-Email & Cf-Access-Jwt-Assertion](https://developers.cloudflare.com/access/setting-up-access/managing-user-sessions/) [2](https://blog.cloudflare.com/multi-sso-and-cloudflare-access-adding-linkedin-and-github-teams/) * [Whatever header you want to foward](https://github.com/agoragames/nginx-google-oauth) * skipping JWT validation * skipping referrer userinfo only headers * skipping azure or SAML examples for now Next problem. Are the username and email forwarded to us usable as is? Well that's really dependent on the downstream application (netbox & administrator). If usernames are intended to be emails then you just use X-Forwarded-Email and ignore -User for example. are the username and email prefixed as to help identify the upstream: `accounts.google.com:username@gsuite.domain.com`? I had a 3rd point but I can't recall what it is right now.

adam commented

@jeremystretch commented on GitHub (Feb 27, 2020):

I think it makes sense to implement this feature by introducing two new abilities.

First, I propose implementing a custom subclass of Django's RemoteUserBackend. We can provide hooks into this class in the form of configuration parameters to control attributes such as:

The HTTP header name
Whether to automatically create new user accounts on login
Groups/permissions to assign to the user
Username "cleaning" (e.g. adding/removing prefixes)

The configuration parameter for this might look something like:

REMOTE_AUTH_CONFIG = {
    'HTTP_HEADER': 'REMOTE_USER',
    'AUTO_CREATE': True,
    'DEFAULT_GROUPS': [...],
    'DEFAULT_PERMISSIONS': [...],
}

The remote authentication backend will be enabled only if REMOTE_AUTH_CONFIG is defined. (The current ViewExemptModelBackend will still be in place as a fallback for local authentication.) This will likely address the majority of use cases for this feature.

The second component is to allow the injection of a custom backend class, to be inserted at the beginning of AUTHENTICATION_BACKENDS. This would take the form of a separate configuration parameter, e.g.

REMOTE_AUTH_BACKEND = 'path.to.my.custom.backend'

REMOTE_AUTH_CONFIG and REMOTE_AUTH_BACKEND would be mutually exclusive to avoid confusion.

I believe this strikes a nice balance between built-in support and custom extensibility, and should be fairly low-effort to maintain long-term.

@jeremystretch commented on GitHub (Feb 27, 2020): I think it makes sense to implement this feature by introducing two new abilities. First, I propose implementing a custom subclass of Django's [RemoteUserBackend](https://docs.djangoproject.com/en/stable/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend). We can provide hooks into this class in the form of configuration parameters to control attributes such as: * The HTTP header name * Whether to automatically create new user accounts on login * Groups/permissions to assign to the user * Username "cleaning" (e.g. adding/removing prefixes) The configuration parameter for this might look something like: ``` REMOTE_AUTH_CONFIG = { 'HTTP_HEADER': 'REMOTE_USER', 'AUTO_CREATE': True, 'DEFAULT_GROUPS': [...], 'DEFAULT_PERMISSIONS': [...], } ``` The remote authentication backend will be enabled only if `REMOTE_AUTH_CONFIG` is defined. (The current ViewExemptModelBackend will still be in place as a fallback for local authentication.) This will likely address the majority of use cases for this feature. The second component is to allow the injection of a custom backend class, to be inserted at the beginning of `AUTHENTICATION_BACKENDS`. This would take the form of a separate configuration parameter, e.g. ``` REMOTE_AUTH_BACKEND = 'path.to.my.custom.backend' ``` `REMOTE_AUTH_CONFIG` and `REMOTE_AUTH_BACKEND` would be mutually exclusive to avoid confusion. I believe this strikes a nice balance between built-in support and custom extensibility, and should be fairly low-effort to maintain long-term.

adam commented

@jeremystretch commented on GitHub (Feb 28, 2020):

In the interest of moving the conversation along, I've introduced PR #4299. This largely implements what I described, however I opted to use individual configuration parameters rather than a dictionary for easier validation. The following can be used to enable and configure built-in remote user authentication:

REMOTE_AUTH_ENABLED = True
REMOTE_AUTH_HEADER = 'HTTP_REMOTE_USER'  # Default
REMOTE_AUTH_AUTO_CREATE_USER = True  # Default
REMOTE_AUTH_DEFAULT_GROUPS = ['Network Engineering', 'Operations']
REMOTE_AUTH_DEFAULT_PERMISSIONS = ['extras.run_script']

This is sufficient to:

Configure the HTTP header which indicates the name of the authenticated user
Automatically create the user if it doesn't already exist
Automatically assign arbitrary groups/permissions

If further customization is needed, there is another setting which can be used to swap out the built-in backend with a custom one:

REMOTE_AUTH_BACKEND = 'path.to.my.custom.backend'

There was some discussion above around manipulating the user name. The backend class does provide a hook for that, but I'm not sure what degree of flexibility would be appropriate. I think at most we can allow the configuration of a regular expression that will match the desired portion of the username passed by the reverse proxy. This would allow us to, for example, strip the username portion from an email address, but anything more complicated than that would require a custom authentication backend.

@jeremystretch commented on GitHub (Feb 28, 2020): In the interest of moving the conversation along, I've introduced PR #4299. This largely implements what I described, however I opted to use individual configuration parameters rather than a dictionary for easier validation. The following can be used to enable and configure built-in remote user authentication: ```python REMOTE_AUTH_ENABLED = True REMOTE_AUTH_HEADER = 'HTTP_REMOTE_USER' # Default REMOTE_AUTH_AUTO_CREATE_USER = True # Default REMOTE_AUTH_DEFAULT_GROUPS = ['Network Engineering', 'Operations'] REMOTE_AUTH_DEFAULT_PERMISSIONS = ['extras.run_script'] ``` This is sufficient to: 1. Configure the HTTP header which indicates the name of the authenticated user 2. Automatically create the user if it doesn't already exist 3. Automatically assign arbitrary groups/permissions If further customization is needed, there is another setting which can be used to swap out the built-in backend with a custom one: ```python REMOTE_AUTH_BACKEND = 'path.to.my.custom.backend' ``` There was some discussion above around manipulating the user name. The backend class _does_ provide a hook for that, but I'm not sure what degree of flexibility would be appropriate. I think at most we can allow the configuration of a regular expression that will match the desired portion of the username passed by the reverse proxy. This would allow us to, for example, strip the username portion from an email address, but anything more complicated than that would require a custom authentication backend.

adam commented

@chaomodus commented on GitHub (Mar 4, 2020):

All of this sounds very good, I was wondering how feasible it would be to also provide a remote auth header name for groups or some sort of group mapping mechanism (similar to REMOTE_AUTH_HEADER, but like REMOTE_AUTH_GROUPS), or would the standard suggestion would be to use a remote_auth_backend for that?

@chaomodus commented on GitHub (Mar 4, 2020): All of this sounds very good, I was wondering how feasible it would be to also provide a remote auth header name for groups or some sort of group mapping mechanism (similar to REMOTE_AUTH_HEADER, but like REMOTE_AUTH_GROUPS), or would the standard suggestion would be to use a remote_auth_backend for that?

adam commented