[rabbitmq-discuss] ssl certificate to client lookup

[Lionel Cons]

Matthias Radestock writes:
 > 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.

The "public messaging service" is exactly the model we try to work
towards. In such a model, the service provider needs to protect its
resources. Unauthenticated clients may get directed to a sacrificial
broker so that abuses do not harm authenticated clients. Similarly,
authenticated clients that do not want to expose their "identity" may
get a different level of service. Clients who play by the rules
(i.e. authentication plus traceability) may get better service.

I don't believe you can build a decent public messaging service
without a minimum security.

 > What distinguishes a trusted sender from an untrusted sender?

The server must know who is allowed to use its services or not, so it
must have a kind of user list. I could imagine something like a
per-user flag telling whether this user is trusted or not. When using
a shovel, if the connecting user is trusted, the shovel will be
somehow trusted.

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

There are two ways to achieve message authentication: outside or
inside of messaging.

Outside, the producer signs the message body and the consumer checks
the signature. There are no requirements on the brokers but only the
consumer knows who the sender is. This is good for the clients, not
for the messaging service.

Inside, all intermediaries (broker, proxy, shovel...) must be trusted.
Otherwise, a rogue intermediary could do evil things with the message.
This is good for the messaging service as it can control who does
what, not for the clients, unless they trust the messaging service.

So to answer your question, if the consumer trusts X and Y then it can
know the sender identity via "inside" authentication. If it does not
trust the service, it has to use "outside" authentication.

Cheers,

Lionel