> For Core messages, it appears there is a way to check the provenance of a message.
That's correct. > For AMQP messages, it appears there is no way to currently do this. That's also correct. > ...the question is how the product in question can get similar provenance/security information for AMQP messages as is available for Core messages. Currently the product in question cannot get similar provenance/security information for AMQP messages as is available for Core messages. The core protocol is specific to the ActiveMQ Artemis broker. It is not standardized. We (the community) can essentially change it in whatever way we want. This is not true of the AMQP protocol. It is standardized. The broker cannot ignore the AMQP 1.0 specification as that may break applications which are expecting compliance with the specification. This was discussed on the Jira where Robbie says, "The AMQP 1.0 application-properties section and properties section (which carries an explicit user-id field) of an message are considered immutable in transit." In other words, we cannot change these properties as such a change would violate the AMQP 1.0 specification. That said, section 3.2.4 of the AMQP 1.0 specification [1] defines the "user-id" message property and defines it as, "The identity of the user responsible for producing the Message. The client sets thisvalue, and it MAY be authenticated by intermediaries." My recommendation would be to use this field when producing messages and then implement the org.apache.activemq.artemis.core.server.plugin.ActiveMQServerMessagePlugin#beforeSend() method in a plugin on the broker which checks this property against the value returned by org.apache.activemq.artemis.core.server.ServerSession#getValidatedUser. Justin [1] http://www.amqp.org/sites/amqp.org/files/amqp.pdf On Wed, Jun 3, 2020 at 11:09 AM 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 >
