0

Is there other ways of authorizing against the Azure Service Bus using AMQP than username and password such as tokens from the ACS?

In my scenario I want to be able to give resource level client access to the service bus without exposing my credentials.

macthestack
  • 55
  • 7

1 Answers1

1

Today, in the preview release of AMQP support in Service Bus, the SASL username/password scheme is the only authentication option.

It is still possible to provide resource-level client access with this model though as you're free to create multiple identities within ACS and associate a limited set of claims with those identities. In fact, this is recommended best practice. The alternative of using the default namespace 'owner' identity in a production set up is analogous to giving application components access to the root password.

So, my recommendation would be to create ACS identities for each "role" in your application and then grant only the claims required by that role. For example, if a Web tier component requires the ability to send to a queue, q1, then create an ACS identity for this Web tier role and grant the 'Send' claim to that identity.

Thanks,

Dave. Service Bus Team, Microsoft.

David Ingham
  • 361
  • 3
  • 4
  • Here's a relevant presentation from my colleague Clemens Vasters that covers the ACS concepts that I allude to above: http://channel9.msdn.com/posts/Securing-Service-Bus-with-ACS – David Ingham Feb 28 '13 at 14:16
  • So is it a recommended best practice to do as you suggest with EventHubs where the solution is expected to have hundreds or thousands of devices sending data? It doesn't seem feasible to create a role for each device. But perhaps it is. Perhaps it's just as feasible as creating SAS tokens for each device; but it seems like a logistical nightmare to manage hundreds/thousands of roles. – Michael Welch May 28 '15 at 16:13