Particular / NServiceBus.RabbitMQ

RabbitMQ transport for NServiceBus
https://docs.particular.net/nservicebus/rabbitmq/
Other
88 stars 60 forks source link

Enable optional OAuth2 token acquisition/token refresh callback func #700

Open moanrose opened 4 years ago

moanrose commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 https://github.com/rabbitmq/rabbitmq-dotnet-client/issues/955

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

michaelklishin commented 4 years ago

@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 commented 4 years ago

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

michaelklishin commented 4 years ago

https://github.com/rabbitmq/rabbitmq-dotnet-client/issues/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 commented 4 years ago

@moanrose OK, thank you for that. I suggest that we continue in https://github.com/rabbitmq/rabbitmq-dotnet-client/issues/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 commented 4 years ago

@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 commented 1 year ago

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 commented 1 year ago

👍 thanks @lukebakken

unixunion commented 2 weeks ago

Has this been solved in NServiceBus rabbitmq transport yet? As I only found this issue on it, not documentation on how to solve this.

boblangley commented 1 week ago

OAuth2 support has not been added to the RabbitMQ transport. This issue will be updated when works starts to add support. There is no ETA at this time.