The Windows Azure Service Bus provides both brokered messaging (better known as queues) and relay capabilities between applications, and is secured using using Windows Azure Active Directory (formally Access Control Services or ACS). When creating a new service bus namespace, a default identity with the name Owner is created. This blog post will show you why you should not use this default entity, even though every demo on the web does so.

I’ve Read This Before….

This is not a new topic. If you search for “Azure Service Bus owner identity”, you will see several posts talking about why you should not use the owner identity. However, I feel that they missed one important point (or maybe I’ve been skimming more then reading and glossed over it) and that is, the owner identity’s password and symmetric key are set to the same value as the namespace’s management service password and key.

Owner isn’t Special

To put it another way, as far as the service bus and Windows Azure Active Directory is concerned, there is nothing special about owner. The name isn’t special, the account doesn’t have a secret GUID behind the scenes, it just happens to get created with full admin access. So let’s take a look at what that access is, and how you can change it in order to better protect your usage of the Service Bus.

When you click on the Access Key button in the Windows Azure Management Portal, you get your first glimpse at the owner identity and the default key. Remember that key value for later.

The Common Problem – Too much access

Access Control Services works on the concept of identities and claims. For a given identity, you can specify zero or more claims. Applications can then use the identity for authentication and the claims as authorization. Click the ‘Open ACS Management Portal’ link to get to the ACS management portal. You can also access it by typing in the well formed URL: https://YourNameSpace-sb.accesscontrol.windows.net.

The first thing we are going to look at are the claims. So click on Rule groups and then the Default Rule Group for Service Bus,

and you’ll end up with a list of predefined rules (claims) for the owner identity.

Each of the rules checks to see if the identity name is owner, and then outputs 1 of three values, Manage, Listen and Send. In the screen shot below you can see the output claim is Listen. The other two rules are exactly the same, but have Manage and Send as the claims. This documentation explains security more in depth, and also defines what rights the three claims grant.

So after reviewing the documentation, and making an educated guess based on the name of the claims, I think you can see where our first problem lies. The owner identity has full control over our root namespace. So you certainly do not want to be handing these credentials out to third parties, but at the same time, you should always be using the least required set of permissions (claims) when you architect a solution, even if you are the only consumer.

For simple applications, all you should really need is send and listen. A lot of examples will use the API call CreateIfNotExists, which will create a new queue if the specified queue doesn’t exist. This is bad for two reasons, first, you’ll invoke a call to the service bus each time to check if the queue exists, and second, it requires your identity to have the manage claim. Now if you have a legitimate reason for creating queues on the fly, then by all means grant your identity the manage claim.

The Identity and Management Service Should not be the Same

So now that you’ve removed the unnecessary claims from owner, let’s take a look at the second problem with the default setup. Start by clicking on Service Identities, and then click on owner.

Click on owner, and then click on Symmetric Key and then Password to view the values for those credentials. As you can see, they are the same value and match the default key shown in the Azure Management Portal.

Now, click on Management Service and then SBManagement Client. The management service allows you to programmatically create and manage identities and rules in ACS.

You’ll see we again have a symmetric key and password who’s values are the exact same as the owner identity.

So not only does the default owner identity have full control over your root namespace, the same password is also used for the management service. This is the point that I think some of the other articles miss. 

My Approach

So the first thing you should do after creating a new namespace via the Azure management portal is to go in and change the Management Service credentials. I would also recommend deleting the owner identity password, and setting the end date for the symmetric key to Today – 1 so that it is expired.

Then create one identity per service which requires access, and give it only the claims it needs. To ease the management burden I would use the command line tool SBAztool. This allows you to manage identities and claims from the command line, saving time and allowing you the opportunity to automate management. 

One thing I didn’t go into detail on, but is worth mentioning, is that you CAN assign permissions at a finer granularity then the root namespace. This means you can grant Listen, Manage and Send claims on individual queues, topics and subscriptions. An example of where this would be useful, is that you could create an identity for a business partner that only has send permissions on a specific queue used to accept orders from outside your system.

I Lied, Owner is Special

So why not just delete the owner identity all together? Well, it turns out that owner is special….to the Azure Management portal. When you click on the Access Key link, it looks for an identity with the name owner with a symmetric key. That key however, can be expired. If you do not have an owner identity with at least a expired symmetric key defined you get the following error when clicking on the Access Key link.