NetBox v3.1-beta1 is now available!

[jeremystretch]

Hey folks, I'm excited to announce that the first beta release for NetBox v3.1 is now available! This release knocks out a ton of long-awaited milestone items, including:

• Contact Objects (#1344)
• Wireless Networks (#3979)
• Dynamic Configuration Updates (#5883)
• First Hop Redundancy Protocol (FHRP) Groups (#6235)
• Conditional Webhooks (#6238)
• Interface Bridging (#6346)
• Multiple ASNs per Site (#6732)
• Single Sign-On (SSO) Authentication (#7649)

There are plenty of minor additions and improvements as well. You can find the full release notes here.

As with previous beta releases, we have deployed a dedicated demo instance for evaluation. You can log in with the username admin and password admin. Please do not alter these credentials.

Give it a spin and let us know what you think! Please be sure to submit any bug reports or change requests as a GitHub issue. We expect the beta period to last a few weeks, and with the community's participation and feedback, I'm confident we can release v3.1.0 in early December.

Thanks everyone!

[jeremystretch]

I'm surprised there hasn't been any feedback regarding SSO support yet. Has anyone tried it?

[yrro]

Fundamentally, the assumption that many applications make that usernames are immutable, meaningful to the user, unique, or even that users have a username at all, is wrong.

When users sign in to an application via OpenID Connect, the application is provided with a token containing claims about the user's identity. Some common claims are name, email and so on. But there's no standard for a claim for username!

What applications need during login is to be able to identify a user record (if it exists) that matches the identity of the user logging in. For this purpose the OpenID Connect specification gives you the iss (issuer) and sub (subject) claim. The promise from the identity provider is that these attributes uniquely identify a user, and that the attributes are immutable.

Simply put, an application ideally needs to record the iss and sub claims in its user database, and use those values and those values alone to look for an existing user record during login. If the application wants to have a username, that's totally fine, there is a preferred_username claim for that. The application is free to provision a user using that claim as its username. But the application should bear in mind that this value is neither unique nor immutable, and it's up to the application to deal with conflicts when the occur.

---

This isn't as complicated as it sounds. Here's a practical example. Let's say a user signs in with the claims {'iss': 'myprovider', 'sub': '12345', 'preferred_username': 'alice', 'name': 'Alice Jones'}. There's no user row with a matching iss and sub, so the application inserts a new row for the Alice, with id 1.

Some time later, Alice changes their name to Bob. They sign in to the application, which receives the claims {'iss': 'myprovider', 'sub': '12345', 'preferred_username': 'bob', 'name': 'Bob Jones'}. The application is able to find user id 1 based on the iss and sub claims. At this point it will update the record with the new name claim. But, let's say the application doesn't want to deal with changing usernames, so it leaves its username value alone.

Now, a second user signs in to the application. The application receives the claims {'iss': 'myprovider', 'sub': '23456', 'preferred_username': 'alice', 'name': 'Alice Smith'}. The application uses iss and sub to look for a user record, doesn't find one, and so inserts user id 2. But there's already an alice in the database, and the application can't handle duplicate usernames. Well, the preferred_username is only a provisioning hint, so it's perfectly valid for the application to give user id 2 a username of alice-ghlxy for disambiguation.

---

Now, in practical terms we've got to deal with the assumptions made by Django (that users have a unique username that is meaningful to the user, i.e., not just a synthetic string of charcters) and python-social-auth (the understandable but nonetheless questionable choices made in its AzureADOAuth2 class to use the upn claim in its get_user_id) function.

My first idea was to patch in my own implementation of this class that returns f'{iss}+{sub}' for the user ID. But that will result in this value showing up in the user interface, which is not so good for user experience.

So my next idea was to provide my own logic for that looks up a user record based on f{iss}+{sub}. But I've got nowhere to store these values!

In an ideal world Django would recognize the need for a separate field on its User class to story the user's identity. And then all Django applications would get that for free. But I'm not going to hold my breath waiting for that to be agreed on and implemented and then released, and for django-social-auth to adopt it...

[mnj]

I'm working on getting our dev instance of Netbox to run on 3.1-beta1, with SSO to AzureAD (following #7649 (comment)) but have an additional challenge of getting it to work with the docker image, with custom configuration files. Right now I'm stuck with an error from Azure AD "AADSTS700016: Application with identifier 'None'", so feels like some config isn't getting picked up.

This feature is something we are really looking forward to hitting non beta (even with the limitation yrro talks about, it will still be really useful here), ill get back if I figure out what's up, could likely be related to the docker image, than something with the changes in 3.1.

The current issue I have so far:
No client_ID getting set in the login url:
https://login.microsoftonline.com/common/oauth2/authorize?client_id=None&redirect_uri=https://netbox-dev.xxx/oauth/complete/azuread-tenant-oauth2/ , which correctly gives it the error message "AADSTS700016: Application with identifier 'None'".

All the SOCAL_AUTH settings have been added to configuration.py:
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_RESOURCE
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID

No idea why they are not getting picked up :S

If I manually add the client_id, the auth workflow succeeds, but then I get sent back to netbox, on:
https://netbox-dev.xxx/oauth/complete/azuread-tenant-oauth2/

Which just returns a server error:
`<class 'social_core.exceptions.AuthCanceled'>

Authentication process canceled

Python version: 3.9.5
NetBox version: 3.1-beta1`

So no success here with Azure AD as the backend at least :(

[mnj]

Digging some further, with DEBUG on, it only picks up SOCIAL_AUTH_JSONFIELD_ENABLED = True / AUTHENTICATION_BACKENDS =
['social_core.backends.azuread_tenant.AzureADTenantOAuth2', 'netbox.authentication.ObjectPermissionBackend'] , but none of the rest of the SOCIAL_AUTH variables, in the django debug toolbar, maybe something is missing from the netbox docker image to get this working :S

[mnj]

Finally some progress, can't say where the real issue lies (Netbox, or the Netbox Docker image), but just having the variables in configuration.py (or a custom config file in the docker image) ) wasn't working for me at all, they didn't get picked up for these specific SOCIAL_AUTH variables, but they did for anything else I added like ADMIN_USERS, but what did the trick was manually adding:
globals()['SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_RESOURCE'] = 'xxx'
globals()['SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY'] = 'xxx'
globals()['SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET'] = 'xxx'
globals()['SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID'] = 'xxx'
to /opt/netbox/netbox/netbox/settings.py, which is obviously not the intended way to do this, but my knowledge of django/netbox is non existent.

[mnj]

With the changes made by tobiasge : netbox-community/netbox-docker#653
It's working fine, with the netbox docker image / 3.1-beta1 here as well.

[PieterL75]

Regarding the ASN:
As an ISP Datacenter Engineer, I never assign ASN's to sites. but rather to subnets.
Different cores (in the same site) have different ASN's. We even have full eBGP (with private ASN) in our spine/leaf network
In my field of work, it would make more sense to connect aggregates (or prefixes) to ASN's rather than physical locations.
When I think of it, a device should also be a relation. The ASN is configured on the device, and has prefixes as child relations.

[candlerb]

For me it would have to be prefixes rather than aggregates: e.g. where you have a RIPE aggregate but announce /24 chunks of it from different ASNs.

[DanSheps]

We are starting with sites, however that doesn't mean this is the final state. If someone wants to open a FR with a use case (and I would think hard about the use case(s)). Right now, I could see a valid use case for both devices (this device peers with this AS) and prefixes (this prefix is announced by this AS).

[jhammond-git]

If we were going to accurately reflect private ASN's, we would be assigning them at the device level, with the site carrying our public ASN since we only have one public per site at this time (not including customer ASNs). I'm far less concerned about prefixes, in my situation.

[nickper]

I'm a little late to the party, an far to late for v3.1. But I will drop it here for now.
The ability to assign ASN's to an aggregate or prefix would be nice. We assign prefixes to different sites. Which use the same ASN.
Now we solve this with a custom field.