[rabbitmq-discuss] ssl certificate to client lookup
matthias at rabbitmq.com
Tue Jul 6 09:08:07 BST 2010
Lionel Cons wrote:
> ActiveMQ has it: http://activemq.apache.org/jmsxuserid.html.
...and AMQP 0-8/9/9-1 has the user-id basic content property. Alas it
has no defined semantics.
> > - How do consumers establish sufficient trust into the server (to supply
> > the correct information)?
> They have no choice: a broker is by definition a trusted entity. For
> instance, consumers expect brokers to deliver message bodies unaltered.
There are messaging scenarios where the broker cannot be trusted
sufficiently. Imagine your bank communicating with another bank over a
public AMQP server. Standard crypto techniques at the end points, opaque
to the broker, work in that setup.
What we are looking at here is something different: systems where apps
*do* trust the broker and want manifestations of that trust, such as
identities of authenticated users, to be reflected into the messaging world.
> > - How do producers establish sufficient trust into the server (to not
> > pass on information about their identity when they do not intent to, to
> > not fake such information, etc)?
> Idem. Producers already trust the brokers, for instance to deliver the
> messages to the right consumers. For the "information about their
> identity", if this may be a concern, it would be easy to have a broker
> flag specifying whether authentication information is passed or not.
I don't think a broker flag is enough here. Step outside the enterprise
world and consider a public AMQP messaging service. I can envisage cases
where the sender will want to control whether its identity is revealed
to consumers. Much like it tells the broker whether the message should
> > - How does one deal with proxies/shovels, i.e. entities that relay
> > information? Do messages passing through them have their original sender
> > info replaced? Or does the proxy/shovel identity get appended somehow?
> This is a very good question.
> I've worked on a very simple model with boolean trust. Either the
> sender of the message (this could be a shovel) is trusted or it is
What distinguishes a trusted sender from an untrusted sender?
> - if it is trusted, the broker accepts authentication information as
> provided by the sender and simply appends what it knows, i.e. the
> identity of the sender
So in a hypothetical scenario where
1) sender authenticates with broker X as user A and sends message
2) proxy authenticates with broker X as user B and consumes message
3) proxy authenticates with broker Y as user C and sends the consumed
4) consumer authenticates with broker Y as user D and consumes message
what sender identity information ends up in the message sent to the
final consumer? It seems to me that if the consumer is interested in the
identity of the original sender it needs to trust broker Y - let's take
that as a given - as well as the proxy and broker X. How can it
establish that trust, since it's not directly interacting with either of
them? Furthermore, the identity with which user A authenticates to
broker X may be completely meaningless to the one the consumer.
This conflation of application level identities with broker
authentication identities is problematic.
One analogy is authenticated smtp. When I send a message to an SMTP
server that requires authentication, the identity I supply is usually
meaningless outside the administrative domain of that server.
> AFAIK, AMQP 1.0 has two different things (I hope the terminology is right):
> - the bare message, with properties
> - the annotated, with extra header and footer
In AMQP 0-8/9/9-1 there is just one set of properties/headers.
basic.deliver and basic.get-ok contain additional information, such as
the exchange to which the message was published and the routing key, but
that is not extensible.
More information about the rabbitmq-discuss