that's probably something you can do with a Plugin or Interceptor. On Wed, Jun 3, 2020 at 12:02 PM Dirkjan Ochtman <d...@apache.org> wrote: > > 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
-- Clebert Suconic
