GCP IAP JWT authentication

[cova-fe]

NetBox version

v3.0.8

Feature type

New functionality

Proposed functionality

Netbox should be able to use GCP IAP JWT token to create or authenticate users. IAP passes a signed token with email and ID of the user, so we can get those information and use them for the auth phase. I implemented a quick PoC and it is a few lines change.

Use case

Installation of netbox in GCP could make use of IAP authentication offered by GCP.

Database changes

No response

External dependencies

No response

[DanSheps]

Duplicate of #7649

[cova-fe]

I'm not sure it is duplicate. What I propose is to use the header provided in IAP authentication that contains username and ID. No oidc, no external backends. It is just a different form of basic auth provided by a web browser. The #7649 refers to something else, more involved, afaics.

[cova-fe]

Basically:
cova-fe@50900d9

[DanSheps]

How is this different then what the social auth provides under the Google backend (More specifically, what does this get us that the social auth does not?)

[cova-fe]

I guess that it provides less, actually. But it is a different situation. I'm using it to have a "basic auth" approach (requests will get an header that you can use and that's it). No need to set up callbacks and so forth. social auth is a bit more complex to setup.

[l1bra2013]

Per #7649 (comment) - this could probably be implemented using a user provided class implementing the Django auth + REST auth interfaces. Netbox would just need to provide sufficient configuration options to allow users to override commonly used authentication related options so that everyone doesn't have to modify the netbox code to incorporate the desired auth solution.

[cova-fe]

Avoiding to make changes in core code would be indeed great. However, the discussion seems to be more related to OIDC. To implement JWT auth I guess that the class will need to access http headers. Implementing REST and stuff like that wouldn't be a bit overkill for something that just checks an header and gets back username (that is already authenticated)? However, if you have an example of the direction you would like to follow, I'll be happy to have a look

[github-actions]

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.

[cova-fe]

Before this issue gets closed, is there any change that it could be looked at? We are using this approach right now and moving to OIDC will cause some (unneeded) headaches :)

[thatmattlove]

I understand the intent here, and I think it's a good idea. That said, I don't like that this is GCP-specific. JWT is an open standard and we could easily work with them without relying on a GCP-specific dependency. I've used PyJWT in the past with great success. It seems to me the only thing we'd need to do differently is specific which header to read and use GCP's (or any provider's) JWKS endpoint for key validation. These could both be provided via configuration settings, and therefore be used with any authentication provider.

In practice, I think the way to implement this would be as another NetBox remote authentication backend. Something like netbox.authentication.JWTBackend, with some configuration settings like:

• JWT_HEADER (string, required, specifies which HTTP header from which to read the JWT value)
• JWT_JWKS_URL (string, optional, specifies the JWKS URL for public key validation, doesn't validate signing key by default)
• JWT_AUDIENCE (string, optional, doesn't validate audience by default)
• JWT_USERNAME_CLAIM (string, optional, uses email by default)

That's just off the top of my head, I'm sure there's room for improvement, should we decide to move forward with this.

Once implemented, it would work very much like netbox.authentication.RemoteUserBackend, the primary difference being that instead of only reading a specific HTTP header for the username attribute, additional validation is done, and additional attributes could be extracted. For example, netbox.authentication.RemoteUserBackend is likely susceptible to replay attacks, whereas proper JWT validation would mitigate that by ensuring the value passed from the server side is both signed by the expected party and valid at the time of use. Additional claims could also be extracted from the JWT, such as the user's full name, role, username (which wouldn't have to be their email), etc.

At any rate, I'd be happy to contribute to this if we decide to move forward with it.

[github-actions]

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]

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.