Recently I was working on putting together a sample of how to use the service relay feature of the Windows Azure Service Bus. By using the Windows Azure Service Bus as a service relay, it is possible to expose on-premises services in a secure way, without the need to punch holes in your firewall or stand up a lot of new infrastructure. Part of the sample included accessing the service from Windows Phone 7. Easy enough, right?
Setting up the server side to register on the Service Bus is fairly straightforward. There are several good examples online, the Azure AppFabric SDK, and the Windows Azure Platform Training Kit. So, I’m not going to go into much detail here on that. However, I do want to be sure to point out that services can have one of two types of client authentication – none and an access token. Obviously, not requiring a token is a lot easier – just call the service like any other WCF REST service. Adding a security token ups the complexity a little. By requiring an access token a client would need to authenticate with Windows Azure Access Control Services first, and then provide the token as part of the service call. An area that can be confusing when dealing with authentication in this situation is the Service Bus still uses ACS v1 for authentication, not the newer, cooler, ACS v2. You will see in the Windows Azure Management Portal that the Service Bus is set to use ACS V1, but when youlook at Access Control in the portal, you’ll just see your ACS V2 namespace.
The client security requirement is configured in the server side .config file.
<bindings>
endpoint security eset endpoint security ciscoTAGS
CATEGORIES