-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable single sign-on (SSO) support natively #7649
Comments
This would be great to have built-in. I already patch in The main features I would look for:
No database changes are needed in my use case. |
Awesome, thank you @nahun! |
A comment from the PoV of someone who will use this to authenticate against his organization's Azure Active Directory once the code lands: Whatever OpenID Connect implementation you choose, please make sure that it uses the tuple of ( This is because user names change from time to time, and matching user records against the correct claim saves users a lot of time and effort when those renames happen. Some docs for reference:
https://openid.net/specs/openid-connect-core-1_0.html#ClaimStability and
Anyway - it's not quite as simple as using Also - a +1 for updating groups based on the |
Well, given that the necessary modifications to core seem fairly minor, maybe it makes sense to include @yrro We're going to be constrained by the backends provided by |
Working off of the docs and @nahun's example I was able to get a bare minimum implementation of python-social-auth up and running pretty quickly in the |
Thanks Jeremy! I got my use case working in the Here is what I put in LOGIN_REQUIRED = True
REMOTE_AUTH_BACKEND = 'social_core.backends.azuread_tenant.AzureADTenantOAuth2'
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_RESOURCE = '{{ AzureAD App Registration Client ID }}'
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY = '{{ AzureAD App Registration Client ID }}'
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET = '{{ AzureAD App Registration Client Secret }}'
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID = '{{ Azure Tenant ID }}'
SOCIAL_AUTH_PIPELINE = (
'social_core.pipeline.social_auth.social_details',
'social_core.pipeline.social_auth.social_uid',
'social_core.pipeline.social_auth.auth_allowed',
'social_core.pipeline.social_auth.social_user',
'social_core.pipeline.user.get_username',
'netbox.custom_pipeline.set_username',
'social_core.pipeline.user.create_user',
'social_core.pipeline.social_auth.associate_user',
'social_core.pipeline.social_auth.load_extra_data',
'social_core.pipeline.user.user_details',
'netbox.custom_pipeline.set_role'
) And then I still placed a My only request is to set a "default" Auth Backend so that it doesn't load the |
IMO it's best to leave it open to the user, much like we do with the
We could expose Django's |
I'm going to tag this for v3.1. We'll likely continue to improve the implementation but I think even the minimal implementation achieved thus far is valuable. |
My guess is my example of setting username and mapping roles to groups would be the most basic and common. Really is a guess though.
For me, exposing |
Closes #7649: Add support for SSO
I've gone ahead and merged the MVP implementation for this. I expect to continue work under the |
Just wanted to add some feedback about this. Although adding the social-auth app works fine for frontend authentication, it doesn't provide a good mechanism for API auth. There is a mechanism provided by https://github.com/RealmTeam/django-rest-framework-social-oauth2, although the project appears dead It may be best to adjust the netbox For example, if using Mozilla Django OIDC, that plugin provides the ability to enable both frontend and API auth overrides, but the following files need changing:
These changes work with the existing REMOTE_AUTH_ variables, by specifying a Django compatible auth class (in this case mozilla OIDC) I think that in the spirit of the REMOTE_AUTH mechanism, it would be better to allow the user to determine what auth mechanism works best for their use case, but provide some sort of mechanism for the user to make the necessary changes, outlined above and pretty much the same in the recently merged PR. If netbox incorporated some sort of improvements to allow for these changes as more of an addon/override rather than a modification to the netbox code, that may make everyone happy. Then examples could be provided for common mechanisms such as social-auth, mozilla-oidc, ... |
I guess I'll chime in with my hat as the maintainer of the somewhat spaghetti but still functional netbox-plugin-azuread that my previous employer and a few others have been using to authenticate into Netbox via Azure Active Directory. First off, I'm really excited to see this functionality getting first class support. I'll be looking forward to the day when I can deprecate the plugin fully and point towards Netbox proper. As far as functionality goes, I'm no Azure AD expert at all so the main things I would echo are what nahun already mentioned about attributes and mapping roles. In addition to that, it makes sense to filter roles too since it's a bit redundant importing potentially thousands of user roles when only a few are used. That said, I'm assuming you'd be mirroring Azure AD groups into Django land. When it comes to UX, the main fiddly bits are login and redirect/reply URIs. I don't think the reply URIs matter so much ( For this case, perhaps it makes sense to just surface n number of buttons in the login template that show up as users enable different auth backends instead of treating it too differently. I can see someone enabling a billion backends and then complaining when buttons slide off the page though haha. Anyway, I haven't had a play with the beta just yet so I'll let you know if I have any feedback and I'm looking forward to seeing it progress! |
That depends on the token claims configured upon the Azure AD App Registration by the Azure AD Application Administrator. The proper (dare I say "modern") way to do it is to define roles (e.g,, viewer, editor, admin, staff) on the App Registration, and then configure the mapping of users (or groups) to roles upon the corresponding Azure AD Enterprise Application (which is confusingly also often described as "the service principal" in various places). As a result, the the app's ID token will include a The other, legacy way of doing it is to configure the App Registration's ID Token to include a TL;DR: define roles on the App Registration, determine who gets what roles on the Enterprise Application, and the On the application side, something has to consume the |
NetBox version
v3.0.8
Feature type
New functionality
Proposed functionality
This FR seeks to introduce built-in support for single sign-on authentication using
python-social-auth
, and specificallysocial-app-django
(formerlydjango-social-auth
). This is a continuation of the discussion under #2328.Currently, NetBox defines two authentication backends:
This FR will allow administrators to either replace or supplement the default
REMOTE_AUTH_BACKEND
with one provided bypython-social-auth
. More detail on the proposed implementation can be found in the project's documentation.I haven't dug into this much yet, so I'm not sure what sort of roadblocks we might run into. We'll also need to ensure to avoid any conflicts with NetBox's object-based permissions system, although those should be minor as that deals with authorization rather than authentication.
Use case
This will allow NetBox administrators to enable one or more of the supported authentication backends (e.g. Google, Okta, GitHub, etc.) for authenticating NetBox users, in addition to the local authentication and custom remote authentication options already provided.
Database changes
The Django app will install several models, but they will be managed outside of NetBox. I don't believe any database changes are necessary within NetBox itself.
External dependencies
social-auth-app-django
andsocial-auth-core
will be introduced as required dependencies. Additional packages may be needed depending on the configured backend(s), however they should be optional.The text was updated successfully, but these errors were encountered: