This is the last part of my 3-part blog series on the recently released Service Bus preview features. 

[This post series is based on preview features that are subject to change]

part 1: Message Pump

part 2: Auto-expiration

Queue/Subscription Shared Access Authorization

Service Bus uses Windows Azure AD Access Control (a.k.a. Access Control Service or ACS) for authentication. And it uses claims generated by ACS for authorizations. For each Service Bus namespace, there’s a corresponding ACS namespace of the same name (suffixed with “-sb”). In this ACS namespace, there’s a “owner” server identity, for which ACS issues three net.windows.servicebus.action claims with values Manage, Listen, and Send. These claims are in turn used by Service Bus to authorize user for different operations. Because “owner” comes with all three claims, he is entitled to perform any operations that are allowed by Service Bus. I wrote a blog article talking about why it’s a good practice to create additional server identities with minimum access rights - these additional identities can only perform a limited set of operations that are designated to them.

However, there are still two problems: first, by default the security scope of these claims are global to the namespace. For example, once a user is granted Listen access, he can listen to any queues and subscriptions. If you want granular access control at entity level, you’ll need to create additional Relying Parties with entity paths as realms, and a “longest prefix match” policy is applied when authorization is performed (see this doc). Second, identity management is cumbersome as you have to go through ACS and manage service identities.  With Service Bus preview features, you’ll be able to create authorization rules by users or clients. And because you can apply multiple authorization rules, you can manage end user access rights separately even if they share the same queue or subscription. This design gives you great flexibility in managing access rights.

Now let’s walk through a sample to see how that works. In this scenario I’ll create two queues for three users: Tom, Jack, and an administrator. Tom has send/listen access to the first queue. Jack has send/listen access to the second queue. In addition, he can also receive messages from the first queue. The administrator can manage both queues. Their access rights are summarized in the following table:

1. Create a new Windows Console application.
2. Install the preview NuGet package:

   install-package ServiceBus.Preview

3. Implement the Main() method:

   static void Main(string[] args)
   {
     var queuePath1 = "sasqueue1";
     var queuePath2 = "sasqueue2";
   
     NamespaceManager nm = new NamespaceManager(
       ServiceBusEnvironment.CreateServiceUri("https", "[Your SB namespace]", string.Empty),
       TokenProvider.CreateSharedSecretTokenProvider("owner", "[Your secret key]"));
   
     QueueDescription desc1 = new QueueDescription(queuePath1);
     QueueDescription desc2 = new QueueDescription(queuePath2);
   
     desc1.Authorization.Add(new SharedAccessAuthorizationRule("ForTom", "pass@word1", new AccessRights[] { AccessRights.Listen, AccessRights.Send }));
               
     desc2.Authorization.Add(new SharedAccessAuthorizationRule("ForJack", "pass@word2", new AccessRights[] { AccessRights.Listen, AccessRights.Send }));
     desc2.Authorization.Add(new SharedAccessAuthorizationRule("ForJack", "pass@word2", new AccessRights[] { AccessRights.Listen }));
               
     desc1.Authorization.Add(new SharedAccessAuthorizationRule("ForAdmin", "pass@word3", new AccessRights[] { AccessRights.Manage }));
     desc2.Authorization.Add(new SharedAccessAuthorizationRule("ForAdmin", "pass@word3", new AccessRights[] { AccessRights.Manage }));
   
     nm.CreateQueue(desc1);
     nm.CreateQueue(desc2);
   }

Okay, that’s not the most exciting code. But it should be fairly easy to understand. For each queue I’m attaching multiple SharedAccessAuthorizationRule, in which I can specify the shared key, as well as assigned rights associated with the rule. And I have implemented desired security policy with few lines of code. These entity-level keys have several advantages (comparing to the two problems stated above): first, they provide fine-granular user access control. Second, they are easier to manage. And third, when they are compromised,  the damage can be constrained within the scope of affected entity or even affected user only.

This concludes my 3-part blog series on Service Bus preview features. Many thanks to Abhishek Lal for help and guidance on the way, and to the friends on Twitter who helped to get the words out. Thank you for reading!