[rabbitmq-discuss] RPC authenticity relies on routing key?
tonyg at lshift.net
Tue Mar 23 15:30:45 GMT 2010
Nathaniel Haggard wrote:
> Machine D sends a message to exchange E1 with routing key send_to_A to
> execute a remote procedure call on A. A replies back using another
> exchange E2 with routing key results_of_A, but A could easily use the
> key results_of_B. Does rabbitmq have a way of making A only use the
> key results_of_A?
> Is there a better way to make sure the results from an RPC to A are
> really from A and not from B?
Yes. You can either *sign* messages from A (and this doesn't have to be
an expensive operation) such that D can verify the authenticity of the
reply, or you can simulate object capabilities:
- let D declare a private reply queue with a long, unguessable
name only known to D.
- let D pass this name to A in the RPC request.
- let A use the name to send the reply back to D.
If D is careful not to let anyone else know about the secret queue name
(a UUID will do), then it can be sure that messages arriving on the
queue come from A or from parties that A has transitively trusted with
> I think it would not scale well (in the thousands) if A, B, C each had
> permissions to write to one queue exchanges E2, E3, and E4, but maybe
> that's wrong too.
Thousands of different RabbitMQ user IDs should work just fine. Might be
awkward to manage, but should work just fine. (You might look in to BQL
for a rapidly evolving utility for managing large amounts of rabbity
More information about the rabbitmq-discuss