Open moanrose opened 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.
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
@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.
@michaelklishin I am ready to put in some work. I was pretty much asking for a plan or backlog
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.
@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 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.
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.
👍 thanks @lukebakken
Has this been solved in NServiceBus rabbitmq transport yet? As I only found this issue on it, not documentation on how to solve this.
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.
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