TopicDescription topic = new TopicDescription(topicPath);
await _namespaceManager.CreateTopicAsync(topic);

SubscriptionDescription subscription = new SubscriptionDescription(topicPath, subscriptionName)
{
    ForwardTo = topic.Path,
};

await _namespaceManager.CreateSubscriptionAsync(subscription, ruleDescription);

In Part 1 we actually had a quick taste of some of the security protocols that Service Bus provides out-of-the-box in the form of a TokenProvider.  The TokenProvider is the governing piece that will allow us to implement the form of security controls that we want.  Whether that be in the form of Shared Access Signatures which we have talked about at length for other services, or backed by a Access Control Service such as Identity Providers (Windows Live ID, Google, Yahoo…etc.) or Federation services such as AD FS 2.0.

However, that being said, you can read Microsoft’s view on Service Bus security and how they have recently (Sept. 2014) changed it to heavily favor Shared Access Signatures (SAS) here.  Therefore, we will also scope this security discussion around Shared Access Signatures as well.  At the end of this portion, I’ll make some additional information available for those interested in other security controls.

If you have been following my previous topics on Azure Services such as Blob and Table Storage just to name a few, you will be somewhat familiar with the concept of Shared Access Signatures.  If you are not, read up on the MSDN version.  A Shared Access Signature (SAS) provides a granular level of access control to specific resources. They allow you to specify what access rights a consumer has for a specific resource for a given amount time.  As in other Azure services the Shared Access Signature is a string that is made up of the details of the access along with a hash that is used by the Azure service to authenticate the Shared Access Signature being passed to the service.

Instead of repetitiously defining exactly what rights a signature grants to a consumer of the Shared Access Signature, we can use predefined policies that are stored on Azure.  These policies act as templates for providing privileges to a specific Service Bus resource. as well as allow us to easily revoke access by removing individual stored policies.  The resources that we can provide access to constitute two levels within the Service Bus; the Namespace and Entities.

The Namespace resource is the same one we define in Part 1 while the entities constitute resources such as Topics and Queues.  However, since programmatically creating stored policies at the Service Bus Namespace requires working with uploaded Certificates through the Azure Portal, I am focus mainly on creating Shared Access Policies for entities.  However, if you are interesting in learning about uploading a certificate and creating Namespace Shared Access Policies you can check out this MSDN article and the related links on that site.

However, you can easily create a Namespace level Shared Access Policy through the portal by going to the Configure section under the Service Bus Namespace you created as shown below:

It is here in the portal that you can create Namespace level policies that can provide any combination of Manage, Send, or Listen privileges. external client.

Creating Stored Policies

Following the Principle of Least Privilege, let’s look at creating and saving stored Policies at the entity level.  Then we can look at consuming those policies to create a Shared Access Signature which can be used or provided to a consumer.  When it comes to creating a policy there isn’t much to it.

TopicDescription topicDescription = await _operations.CreateOrRetrieveTopicAsync(topicPath);
topicDescription.Authorization.Add(new SharedAccessAuthorizationRule(“SendSingerRequests”,
SharedAccessAuthorizationRule.GenerateRandomKey(), new[] { AccessRights.Send ));

await _namespaceManager.UpdateTopicAsync(topicDescription );

Again, CreateOrRetrieveTopicAsync is just a helper method to either pass back an existing TopicDescription or create it if it doesn’t exist.  From there we simply are adding a new AuthorizationRule as a SharedAccessAuthorizationRule to the Authorization property of the TopicDescription.  This SharedAccessAuthorizationRule is created by providing the name of the policy as well as an array of AccessRights enumerations.

In this case we are creating a Stored Policy with the name “SendSingerRequests” with the right to send on the topic which we can see if we navigate to the Topic under the Namespace for the Service Bus in the Azure portal:

Now that we have created a stored policy for a Topic, we can easily generate a Shared Access Signature which can be provided to a consumer for authenticity.

Generating Shared Access Signatures from Policies

Generating a Shared Access signature just requires the service knowing the endpoint URI, policy name and either the primary or secondary key along with a timespan of how long the Shared Access Signature is valid.

Uri serviceUri = ServiceBusEnvironment.CreateServiceUri("sb", "shopit", string.Empty);
string generatedSaS = SharedAccessSignatureTokenProvider.GetSharedAccessSignature(
        policyName,
        policyKey,
        serviceUri.ToString().Trim('/'),
        TimeSpan.FromHours(8));

A lot of this should already look very familiar to you back in Part 1 where we showed various ways to create the NamespaceManager.  From here we can provide the string Shared Access Signature to a consumer to use in creating their TokenProvider.

Consuming a Shared Access Signature

Having the generated Shared Access Signature in hand, we can provide it to a consumer that might want to send messages to our Topic which they can go about consuming it when they generate a TokenProvider:

TokenProvider tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(generatedSaS);

MessagingFactory factory = MessagingFactory.Create("sb://<yourNamespace>.servicebus.windows.net", tokenProvider);
MessageSender messageSender = factory.CreateMessageSender(_topicName);

From here they can send messages to the topic for as long as the Time-To-Live was set for the Shared Access Signature when it was generated above (example of 8 hrs.).

Additional Resources

As I mentioned, there is other Access Control Services available Identity Providers, Federation services to name a couple.  Below are some additional resources for more information on those extended areas of access control:

1.  http://blogs.msdn.com/b/jimoneil/archive/2012/04/24/fun-with-the-service-bus-part-1.aspx

2.  http://azure.microsoft.com/en-us/documentation/articles/active-directory-dotnet-how-to-use-access-control/

3.  http://blogs.msdn.com/b/servicebus/archive/2014/09/03/change-to-azure-service-bus-portal-default-authentication-mechanism-for-service-bus-namespaces-now-sas.aspx

4.  http://www.developerfusion.com/article/121561/integrating-active-directory-into-azure/

Best Practices

There are number of protocols that the Service Bus can operate under.  By default the SDK utilizes the Service Bus Messaging Protocol which provides the best performance and features.  Unless yours or your consumers operations are limited to HTTP/S, then utilize the SBMP.  Check out this article for more information on available protocols.

Factories, Clients and Abstractions

I haven’t mentioned this before, but there is a significant amount of overhead when creating factories such as MessagingFactory and clients such as QueueClient, TopicClient and SubscriptionClient as well as their MessageSender and MessageReceiver abstractions.  Therefore, when creating these resource, attempt to fully utilize them without needlessly recreating.  An example would be recreating a MessageSender for every message that you need to send.

Furthermore, understand that when you terminate a factory such as a MessagingFactory, it also closes all the entities it was responsible for creating.

Abstractions

When you absolutely don’t need to utilize the direct clients such as QueueClient, TopicClient and SubscriptionClient use their abstractions MessageSender and MessageReceiver.  Doing so, you don’t need to worry about whether you sending to a queue or to a topic, receiving from a queue or a subscription.

Operations

At the beginning of this series I mentioned it, but I thought it was worth repeating the importance of taking advantage and utilizing the asynchronous operations provided by the SDK when possible.  There is a significant performance improvement when using the provided asynchronous methods.

Message Size

Finally, the default of a message size is 256kb total which includes both the body and properties (system and custom) with a max property size of 64kb.  While conceivably you can increase this size, proceed with caution.  If there is any reason or possibility that a future requirement or current client that will need to utilize HTTP as their protocol, this can have a negative impact. Service Bus messages are designed for efficiency and Service Bus messages are designed to be compatible with  HTTP header size specifications

Batching

It’s not quite 1 or 0, true or false, black or white when it comes to batching and being efficient.  Batching is only available for send and completion operations But here are some performance considerations.

Low Throughput – Disable batching by setting the batch flush interval to 0.

High Throughput – Set the BatchFlushInterval to 50ms

Multiple Senders/Receivers – When using multiple senders/receivers, set the BatchFlushInterval to 100ms.

To adjust the flush interval for batch processing, you set the BatchFlushInternval property on the MessagingFactorySettings object that is then passed into the creation of a MessagingFactory (see Batching):

Conclusion

This has been one long series on a very large Azure Service that I wish I could say I have covered every corner regarding the service, but the truth is that there is just so much to talk about that it would take more than a 3 part series to do that.  However, be assured that you have been shown a vast majority of the features of Azure Service Bus.  Now, there are closely related topics that are services built on top of Azure Service Bus such as Event and Notification hub as well as service bus patterns that weren’t covered such as request-response patterns just to name a few.  But, hopefully the information you have garnished from the three part series will teach you more than just the basics of using Azure Service Bus.

If you liked this post, follow me @maxrmccarty

Everything You Need to Know About Azure Service Bus Part 3 first appeared on LockMeDown.com