I was working with a customer that wanted to use AppFabric Topics to push notifications to clients. as We all know anyone who wants to listen or send messages using service bus has to authenticate first. Traditionally authentication to the service bus was done by presenting a secret key before a connection was established.It is reasonable to put the secret key in a software package deployed on a server (Some can argue with that and say it is a security violation) but providing the key to numerous clients? This is a true security breach.
So How can we make clients listen on the service bus without having to provide them with our secret key?
Access Control Service is the solution.
The new version of Service bus which was released few weeks ago uses ACS to federate its authentication. We can use ACS to create new identities or federate with other identity providers so the actual user can use its own credentials to get a token that can be used against service bus. We can assign different permissions to the service bus users. It is possible to give listen, send, and manage permissions so we can make sure that users can execute only the actions we allow them to.
How do we set this?
Well for each service bus namespace (such as "manublog") a twin namespace (e.g. "manublog-sb") is created in ACS.
Let us open the management portal for service bus and select out namespace. By pressing on the Access Control Service button the portal of ACS for the twin namespace will be opened.
here we can register other identity providers that we want to federate with (such as a custom STS or ADFS 2.0)
In the relying party section we register the uri of the service bus resource we want to expose to our user. For example a queue a topic or a relay service (e.g. http://manublog.servicebus.windows.net/mytopic/subscriptions/manu)
In the rule group section we add rules that will be used to create a claim of type "net.windows.servicebus.action" with the value "Listen or Send or Manage".
In the portal we will find a definition of a relying party referencing the root of our service bus namespace. we can reference that as an example for defining new relying parties.
In the namespace there are existing rules for the super user "owner" that have full access to the entire namespace. we can reference these rules as examples for creating new ones.
In the portal we will find the definition of the super user "owner"
We can reference this as an example for our new identities definition.
Clemens Vasters recorded a great video describing all these capabilities in details. I strongly recommend to watch it.
ACS is now integrated with AppFabric Service bus. This allows us to have full control who will use our communication channels implemented in service bus without exposing our secrets.