[rabbitmq-discuss] ssl certificate to client lookup

[Matthias Radestock]

Lionel,

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 
be persisted.

>  > - 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
> not.

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 
message
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.


Regards,

Matthias.