SOAProuting is a tough problem. On one hand, you want the ability for a message to transparentlypass through a chain of intermediaries. The flexibility and architecturalcreativity enabled by dynamic message routing is attractive. On the other hand,dynamic message routing is basically a man-in-the-middle attackwaiting to happen. When it comes to routing, balancing flexibility and securityis tough.

Signing the addressing headers helps guarantee security. Binding the addressingheaders to the message body with a signature ensures that your message will endup at a service whose address URI matches the Address URI to which the messagewas sent. Routing capability is accomplished through the Via property of theDestination EPR (which is not present on the wire, and thus not included in anysignature). Machine A can send a message to “urn:foo via soap.msmq://private”,which can be picked up by Machine B and sent to “urn:foo via http://public”. The “urn:foo” partof the destination cannot be altered without destroying the integrity of thesignature. Thus, Machine A is guaranteed that the message will be delivered tosome service named “urn:foo”.

Simplesignatures do not, however, guarantee that your message will get to the real“urn:foo” service. A hacker could set up a malicious “urn:foo”service and deliver your message to “urn:foo via soap.tcp://malicious”by compromising one of the intermediaries in the chain. Securing your messageagainst compromised intermediaries can be accomplished with encryption; you canencrypt the message body with the asymmetric key of the real “urn:foo”service. That way, even if a malicious router sends the message to someone youdon’t trust, that message will be useless to them because they lack theappropriate key to decrypt it. Alternatively, you could encrypt the addressingheaders so that only trusted routers can decrypt them. Realistically, in thename of paranoia, I think you’d probably be smart to do both if you’rereally concerned with message security.