When working with the topic pattern in Azure Service Bus it is easy to get up and running for a demo, but when you come to implement a real world solution you probably need to implement a more fine grained level of security than you demo would implement. As an example in demo’s everyone uses the root SAS key which has Send, Listen and Manage permissions for the entire namespace. Easy to get up and running but if your in a real world scenario you might have two business partners as the listeners for your subscriptions. In this case you need to implement a different key for each partner and to ensure they can not get messages that are not intended for them. In this case the root key is not appropriate.
The problem however is that in Azure Service Bus you can not implement an authorization policy on a specific subscription, you can only implement it on the topic. This means I can restrict who can send to the topic but not separate different identities for each subscription. Not to worry though in Azure Service Bus a subscription has a property called “forward to”. This property allows you to specify that all messages received by a subscription are forwarded to another messaging entity such as a queue or another topic. In this case we would be able to forward messages to a queue and then implement an authorization rule for the queue to restrict who can get messages. We could forward the messages from each subscription to a separate queue and that would allow us to implement the fine grained level of security we mentioned above.
Demo
The below video shows a demo of implementing this pattern.
Code
The code used in the demo can be downloaded from here
http://cscblogsamples.blob.core.windows.net/publicblogsamples/ServiceBus.Topic.Authorize.zip
