-
Notifications
You must be signed in to change notification settings - Fork 60
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
Comments
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 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 |
@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 |
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 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 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. |
@michaelklishin I see that there is a
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
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
The text was updated successfully, but these errors were encountered: