On Wed, Jun 3, 2020 at 5:47 PM Justin Bertram <jbert...@apache.org> wrote:
> > I would like to better understand how this is supposed to work... > > What specifically do you not understand? > For Core messages, it appears there is a way to check the provenance of a message. For AMQP messages, it appears there is no way to currently do this. I have a use case with a product that embeds an Artemis broker and whose security model apparently relies on using the validated user value in an Artemis Core message. Because the Core protocol is implementation-defined and (as far as I can tell) undocumented and I would like to talk to this product from a non-JVM context, I'd like to use AMQP instead. As such, the question is how the product in question can get similar provenance/security information for AMQP messages as is available for Core messages. > > ...and see if there are any improvements that could be made here. > > I imagine improvements could be made, but that question is pretty vague. > Are you referring specifically to your suggestion on the Jira? You asked, > "...could it perhaps make sense for Artemis throw an error if the > `HDR_VALIDATED_USER` contents, if present, do not match the `validatedUser` > for the connection on the server side? Otherwise, how can downstream > applications have access to the authenticated user for a given incoming > AMQP message?" > > I didn't quite understand your question. Are you asking if Artemis could be > changed so that if the user sending the message sets the > "_AMQ_ValidatedUser" property with a value that doesn't match the name of > the user which the broker validates for that user's connection then the > broker would reject the message with an exception? > Yes, that is my suggestion. This is merely a minimal Artemis change that I imagine could satisfy my use case (to have message provenance for AMQP messages similar to what's available for Core messages). If there is a better way, I could potentially spend some time investigating it. > For what it's worth, a foundational tenet of most messaging applications > (especially asynchronous ones) is a fundamental separation of consumers and > producers. Generally speaking this simplifies application design and > facilitates better scaling. By having the consumers care about who sent the > message they are consuming this tenet is broken. You may want to revisit > your application design to see if this is absolutely necessary. To be > clear, this feature was implemented in Artemis for backwards compatibility > with ActiveMQ 5.x. > The product is not of my design. They are using Artemis for a client-server RPC protocol. I imagine they selected Artemis for this because they're looking for exactly-once delivery which is desirable for their enterprise transaction uses, but I don't know all the details. Thanks for the feedback, Dirkjan
