Skip to content
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 optional OAuth2 token acquisition/token refresh callback func #700

Open
moanrose opened this issue Oct 19, 2020 · 9 comments
Open

Comments

@moanrose
Copy link

moanrose commented Oct 19, 2020

When using a OAuth2 auth mechanism for RabbitMQ. Either using https://github.com/rabbitmq/rabbitmq-auth-backend-oauth2 or as in my case - the HTTP Auth Backend with a custom OAuth2 token validator. A problem with the NServiceBus.RabbitMQ transport arises.

The OAuth tokens are short lived, while the NServiceBus.RabbitMQ transport aims to have a long lived connection - and reconnect using the same credentials supplied when configuring the Endpoint.

It would be really useful if the RabbitMQ transport configuration allowed the configuration on an optional callback func. Which should yield valid credentials, and their expiry - allowing the developer to integrate with their OAuth2 token acquisition/token refresh mechanism of choice

@bording
Copy link
Member

bording commented Oct 19, 2020

HI @moanrose,

Before we could offer anything like what you're suggesting, the RabbitMQ client that we rely on would need to have support added. I suggest filing an issue at https://github.com/rabbitmq/rabbitmq-dotnet-client to see if they have any interest in adding some sort of OAuth support to the client.

A word of warning though, I suspect you might get some resistance there about adding what you're suggesting because AMQP connections are inherently long-lived connections, so there's not really a way to integrate the idea of short-lived credentials with AMQP connections.

@moanrose
Copy link
Author

Hi @bording

It appears that this functionality has already been implemented in the RabbitMQ Java Client using an CredentailsProvider abstraction, but is not yet ported to the .NET client - so the resistance might not be that hard.

I have created an issue asking about the timeline for porting this functionality to the .NET client here rabbitmq/rabbitmq-dotnet-client#955

It is a bit unclear to me if the maintainers at Pivotal would do the port, or if it entirely community driven

@michaelklishin
Copy link

michaelklishin commented Oct 20, 2020

@bording yes, there is a way to support JWT-based authentication and token refresh, at least for AMQP 0-9-1 (not all protocols RabbitMQ supports are extensible).

@moanrose RabbitMQ and its client libraries are open source software. Our community is several orders of magnitude larger than the RabbitMQ core team. Asking others to do the work because you need it is not how open source software works.

@moanrose
Copy link
Author

@michaelklishin I am ready to put in some work. I was pretty much asking for a plan or backlog

@michaelklishin
Copy link

rabbitmq/rabbitmq-dotnet-client#956 explains what the .NET client already supports when it comes to OAuth 2/JWT, and what would be a really nice to have (and can be stolen from the Java client). It can go into a 6.x release of the client (master/7.0 has major changes internally and may ship in 2021 or so).

I don't see anything that NServiceBus or similar projects would have to do to support JWT token refresh, other than exposing a "credential provider" setting or allowing for connection factory to be modified directly.

@michaelklishin
Copy link

@moanrose OK, thank you for that. I suggest that we continue in rabbitmq/rabbitmq-dotnet-client#956 and close this until we are happy with the state of the .NET client and see what NServiceBus specifically might need to expose.

@bording
Copy link
Member

bording commented Oct 20, 2020

@bording yes, there is a way to support JWT-based authentication and token refresh, at least for AMQP 0-9-1 (not all protocols RabbitMQ supports are extensible).

@michaelklishin I see that there is a connection.update-secret protocol extension that enables this. When was this added? I don't recall ever seeing this before!

I don't see anything that NServiceBus or similar projects would have to do to support JWT token refresh, other than exposing a "credential provider" setting or allowing for connection factory to be modified directly.

Yes, this was what I was alluding to in my first reply here. Once the client exposes something, we can then surface it like we've done for other client features.

@lukebakken
Copy link
Contributor

OAuth2 support will ship in version 6.6.0 of the .NET client. I have released beta versions of the following if you'd like to test it out:

I'm currently in the process of updating documentation.

@adamralph
Copy link
Member

👍 thanks @lukebakken

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants