[rabbitmq-discuss] ssl certificate to client lookup

[Matthias Radestock]

Lionel,

On 06/07/10 11:11, Lionel Cons wrote:
> 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.

I wasn't suggesting that clients should be able to work unauthenticated, 
but that they may not want their identity passed to consumers. So the 
question is, if the authentication is only of interest to the broker, 
why does it get passed to the *consumer*? Would it instead be sufficient 
to retain the credentials internally in the broker and present them in 
various admin tools, but not pass them to the consumers? That way we 
would also preserve message fidelity.

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

Right, except the consumer doesn't even know the message came via broker 
X. And, furthermore, the identity presented to broker X may be 
meaningless in the context of broker Y and the consumer.

So it seems to me that if you want *consumers* to know about sender 
identities then that should be handled at the app level, outside the 
messaging layer.

OTOH, servers, and those administering them, should be able to find out 
which AMQP users are responsible for certain actions (such as the 
creation of an exchange or queue, the sending or retrieval of a message) 
and their resulting artifacts (such as a created queue or exchange, or a 
stored message).


Regards,

Matthias.