[rabbitmq-discuss] RPC authenticity relies on routing key?

[Tony Garnock-Jones]

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?

No, but...

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

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

Regards,
  Tony