Problem Statement

How to provide the security to Service Bus Messaging without ACS?

If you create a service bus namespace via azure portal after August 2014 you might noticed that there is no ACS association with Service Bus. Any reasons?

Why Azure product team recommended to use SAS (Shared Access Signature) over ACS (Access Control Service) whenever there is a possibility?

ACS provides access control capabilities to many of the azure components without writing much complex logic but it is not been well integrated with Storage. There is no granular level access control while accessing the resources in storage. Clients are using ACS mainly for Federation Scenarios. The primary aim of ACS is transforming the claims to support Federated identity. Let me explain this in detail what I mean.

The problem of using ACS with Service Bus is most of the clients authenticate using the owner service identity which is equivalent of SA user in Database World. By default if you not specify any relying parties ACS will use owner Identity. This identity has full control over the Azure Service Bus namespace, so if it is compromised then there is a huge risk to your data. Moreover we cannot regenerate the Default Key using ACS. So if the key was compromised we need to recreate the ACS namespace again. ACS is not scalable like SAS because it has limited authentication support per seconds unless we cache the token then there is a performance impact.

What is SAS

Right now the trend is like either having the complete control over the resources (Queue/Topic/Subscription) or completely lockdown. There is no granular level access for consumers to access the data. Throughout this article assume data means storage.

Provide varying level of access to consumers that is where SAS comes into the picture.

Anatomy of SAS?

For Service Bus

https://sb://<namespace>.servicebus.windows.net/<topic>&se=2015-04-30T02%3A23%3A26Z&skn=<policyname>&sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D

SAS can be applicable to Azure Storage as well

For Azure Storage

https://myaccount.blob.core.windows.net/sascontainer/sasblob.txt?sv=2015-04-05&st=2015-04-29T22%3A18%3A26Z&se=2015-04-30T02%3A23%3A26Z&sr=b&sp=rw&sip=168.1.5.60-168.1.5.70&spr=https&sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D

It contains various parts

  • Blob Uri
  • Version of the Storage Service (SV)
  • Start time of the token validity(ST)
  • Expiration time of the token(SE)
  • Resource: Blob (SR)
  • Permissions: RW (Read/Write) (SP)
  • Range of IP addresses from which the request will be accepted (SIP)
  • Protocol
  • HMAC signature used to authenticate to grant the requested resource (Sig)

By default Service Bus comes with RootManageSharedAccessKey which has highest privilege in SB Namespace. Our thought process was do not share this key to the unintended parties and provide least privileges to clients to get the things done.

Consider an example like there is an order management system (Ecommerce Site) which receives so many orders (Head Office) in a day which needs Manage Identity because it needs to send and receive messages, for that reason created a Topic (OrderTopic) and there are so many number of subscriptions like HydSubscription, Chennai Subscription/Bangalore Subscription. How SAS will fit into this Scenario?

So we created 4 policies under the topic: OrderTopic

Shared Policy Permissions
Head Office Manage(Send and Receive)
HydSubscription Listen
ChennaiSubscription Listen
BangaloreSubscription Listen

Advantages of Using SAS in this scenario

So here we did not use the RootManangeSharedAccessKey which has highest level of privilege at the namespace level. The Headoffice is given Manage permission at the topic level, so limiting the control to that topic only and more over the subscriptions are able to listen the messages only but cannot send the messages.

If the key was compromised here then the loss will happen specific to that topic only and not at the entire service bus namespace level. So we can regenerate the key easily and circulate it which is not easy with ACS.

Design Consideration for SAS

While designing an application which dealt with securing resources on a storage, always try to create a service (Resource Server) which will provide us SAS tokens and this is the only service contains the account. Account key is required for generating SAS tokens. If you develop a service kind of this we can also control authorization like who is asking the SAS token and they are really the part of Organization or external etc.

Best Practices for SAS

  • Near Expiration Times
  • Use Https Protocol all the time
  • Be careful while providing Start Time
  • Use Principal of least privilege while creating policies

Conclusion

The feature roadmap of azure team is ACS is as part of Azure AD, that is reason ACS is coming as part of Active Directory in azure portal. For more information please refer: https://azure.microsoft.com/en-us/blog/acs-in-windows-azure-management-portal/

To authenticate Service Bus with ACS there is a 2 step process, get the token and pass this token to corresponding service bus namespace. ACS won’t scale well if the number of messages are growing unless the token was cached per some time, this is because it has limited authentications capability per second. Still if we want go with ACS there is a way by using PowerShell cmdlet J

New-AzureSBNamespace namespacename -Location “Southeast Asia” -CreateACSNamespace $true -NamespaceType Messaging

With this ACS information can be seen for Service Bus in portal.

So SAS provides better capabilities than ACS for securing resources in a storage. It helps us in providing more granular level control and reduces the risk of data loss and protection of resources.