ServiceBus

Another nugget of information that I picked up at TechEd North America is a new template that ships as part of the Azure SDK 1.7 called Worker Role with Service Bus Queue.

What got me interested in this feature is some of the work that I did last year with the AppFabric Applications (Composite Apps) CTP. I was a big fan of that CTP as it allowed you to wire-up different cloud services rather seamlessly. That CTP has been officially shut-down so I can only assume that this template was introduced to address some of the problems that the AppFabric Applications CTP sought to solve.

The Worker Role with Service Bus Queue feature works in both Visual Studio 2010 or Visual Studio 2012 RC. For this post I am going to be using 2012 RC.

I am going to use a similar scenario to the one that I used in the App Fabric Applications CTP. I will build a simple Web Page that will allow a “customer” to populate a power outage form. I will then submit this message to a Service Bus Queue and will then have a Worker role dequeue this message. For the purpose of this post I will simply write a trace event to prove that I am able to pull the message off of the queue.

Building the Application

Create a new project by clicking on File (or is it FILE) – New Project

Select Cloud template and then you will see a blank pane with no template able to be selected. The Azure SDK is currently built on top of .Net 4.0 not 4.5. With this in mind, we need to select .Net Framework 4

We now need to select the Cloud Services that will make up our solution. In my scenario I am going to include an ASP.Net Web Role and a Worker Role withService Bus Queue.

Note: we do have the opportunity to rename these artifacts by hovering over the label and then clicking on the pencil. This was a gap that existed in the old AppFabric Apps CTP. After renaming my artifacts my solution looks like this:

I want to send and receive a strongly typed message so I am going to create a Class Library and call it CustomerEntity.

In this project I will simply have one class called Customer with the following properties

Another new feature in this SDK that you may have noticed is the CreateFromConnectionString method that is available to the MessagingFactory and NamespaceManager classes. This allows us to retrieve our configuration settings from our project properties page. To access the project properties right mouse click on the particular role and then select Properties. Next, click on Settings where you will find Key/Value Pairings. The name of the key that we are interested in is: Microsoft.ServiceBus.ConnectionString and our value is

Since both our Web and Worker Roles will be accessing the Queue we will want to ensure that both configuration files have this entry included. This will allow our code to make a connection to our Service Bus Namespace where our Queue may be found. If we edit this property here in these locations, then we do not need to modify the Cloud.cscfg and Local.cscfg configuration files because Visual Studio will take care of this for us.

Next we want to shift focus to the Worker Role and edit the WorkerRole.cs file. Since we are going to be dequeuing our typed CustomerService message we want to include a reference to this namespace:

using CustomerEntity;

Something that you probably noticed when you opened up the WorkerRole.cs file is that there is already some code written for us. We can leverage most of it but can delete the code that is highlighted in red below:

In this code we are going to receive a typed Customer message and then simply write out the contents of this message using the Trace utility. If we wanted to save this information to a Database, this would a good place to write that code.

We also want to make sure that we update the name of Queue so that it matches the name that we specified in the Web Role:

We have a few options when it comes to creating our Queue that is required for this solution to work. The code in our ASP.NET Web page code-behind will take care of this for us. So for our solution to work, this method is sufficient but perhaps we want to use a design-time alternative to specify some more advanced features. In this case we do have a few options:

As part of the Azure 1.7 SDK release, a Visual Studio Service Bus Explorer is now included. It is accessible from the Server Explorer view from within Visual Studio. Using this tool we can perform some functions like:

Creating Queues/Topics

Set advanced properties: Queue Size, Time to Live, Lock Duration etc

Send and Receive Test Messages

Get the current Queue Depth

Get our Service Bus Connection string

Any of these methods will work. As I mentioned earlier, if we do nothing, the code will take care of it for us.

Testing

We are just going to test our code locally, with the exception of our ServiceBus Queue. That is going to be created in Azure. To test our example:

Hit the F5 and our website should be displayed

Since we have our Trace statements included in our Worker Role code, we need to launch our Compute Emulator. To do this right mouse click on the Azure icon that is located in your taskbar and select Show Compute Emulator UI.

A “Console” like window will appear. We will want to click on the ServiceBusWorker label

Switch back to our Web Application, provide some data and click the submit button. We should see that our results label is updated to indicate that our Message sent to queue.

If we switch back to our Compute Emulator we should discover that our message has been dequeued.

Conclusion

While the experience is a little different than that of the AppFabric Applications CTP, it is effective. Especially for developers who may not be all that familiar with “integration”. This template really provides a great starter point and allows them to wire up a Service Bus queue to their Web Application very quickly.

So I can’t take credit for the catchy tag line for this post. It was inspired by a recent session that Clemens Vasters and Abhishek Lal provided at TechEd North America 2012. You can watch the entire session here.

While watching the presentation, this particular segment, on not running as root, really resonated with me. I have built some proof of concept mobile applications that use REST APIs to send messages to Service Bus Queues. In these applications I use the default owner key to submit messages. I knew at the time that this could not be a good practice but since it was just a POC it was acceptable. I was curious about how I could solve this problem in a better manner and I think what Microsoft has done here is definitely a step in the right direction.

If you are familiar with the Azure Service Bus, and Azure in general, there are 3 fundamental ‘artifacts’ that are required whenever you try to provision or manipulate Azure Services. These artifacts include:

Namespace

Default Issuer (username)

Default Key (password)

The Problem

In 99.99% of the demos and blog posts that exist on the interwebs, people are embedding their Default Issuer and Default Key in their solution. This creates issues on a few different levels:

The account really is “root” when it comes to your namespace. Using your “account” allows you to create services like Queues, Topics, ACS Trust relationships, provision Cache etc. Do you see the problem with embedding these credentials in your app and then distributing it?

If your account does become compromised, it could be used to maliciously manipulate your solution. If you comprimised a solution that processed Customer Orders, wouldn’t it be nice to add your own subscriber to the Topic Subscription and receive a copy of each customer’s Credit Card number?

Like any other security principal, we want to ensure that people, or systems, have the minimum level of security rights that they need to perform a specific function. A parallel example to this scenario is giving end users Domain Admin. You wouldn’t give that to end users, much like you shouldn’t embed your “owner ‘s” credential in your application.

Enter SBAzTool

There is a tool that is part of the Windows Azure 1.7 SDK that can help us assign fine grained authorization to “Default Name(s)” (Usernames). You can download the source code for this tool here. In the rest of this post I will demonstrate how you can use this tool and then show an example that demonstrates why this tool is beneficial and that creating authorization rules is not so hard.

Create Namespace in Portal

Even though I have a functional namespace I am going to go ahead and create one from scratch so that we are all beginning at the same starting point. If you have an existing namespace that you want to use, you can. You don’t have to go through these next few steps where I create the namespace.

From http://www.windowsazure.com, log in and then select the previous(old) portal as Service Bus and ACS do not exist in the new portal…yet.

Next, click on the Service Bus label and then click on the {New} button

In this case I am selecting Access Control, Service Bus, a namespace and a Country/Region. Since United States (West) is closest to my locale, I will use it.

So I now have a Namespace called DontRunAsRoot. It may take a couple minutes to create. You will also notice that we have a tree like structure where our Queues and Topics will be displayed.

For the purpose of this demo we are going to create a Queue called MyQueue by clicking on the New Queue button.

We will need to populate the Name text box and then can accept the defaults.

Voila, we have our newly created Namespace and Queue

We are going to need our “owner” key so we might as well get it while we are in the portal. Click on the View button and then click the Copy to Clipboard button.

Compiling SBAzTool

Once you have downloaded the SBAzTool you can compile the solution and then open a command prompt and launch the tool by specifying sbaztool.exe. You can now see all of the command line arguments. However you can also access this documentation from the download page as well.

StoreOptions

In order to set permissions for other users/issuers we need to be authenticated ourselves using the Key that we previously retrieved from the portal. By using the storeoptions argument we can continue to execute commands without having to re-issue our key/password. To do this we will want to execute the following command:

sbaztool.exe storeoptions –n <namespace> –k <key>

MakeId

So lets now create a new “user” by specifying the makeid command. In this case we can actually specify a “username” instead of the regular “owner” that we are so use to.

sbaztool.exe makeid <username>

As you can see, a Key has been provided for this user(which I have whited out). We also have the ability to specify a password but including our own <key> provided it is a 32 byte, base64 encoded value.

Grant

Now that we have a Issuer/User created, we can actually assign this user permissions. The command to do so is:

grant <operation> <path> <name>

The available operations that we have access to are:

Send

Listen

Manage

Send and Listen are pretty self explanatory but Manage deserves further elaboration. We can actually delegate the authority to manage resources to a particular user based upon the path. So lets imagine we have a path that looks like this:

/organization/department/engineering

If we wanted to allow someone to administrate the/engineering services we could do so using this command.

For the purpose of this blog post, lets keep things simple and assign Send and Listen privileges toour QueueUser for our queue which is called myqueue.

Send

Listen

Show

To verify that our permissions have been set correctly we can execute the Show command by providing the following:

show <path>

As you can see below the QueueUser now has Send and Listen permissions on the queue called myqueue. This is a much better solution than giving entire rights to a namespace when you only need to specify rights on a particular queue.

Test permissions

So in order to validate that this stuff actually works and this is not smoke and mirrors I am going to create a very simple console application that will use these credentials to send and receive a message. Once we have validated that this works we will pull the Send permission and see what happens.

The following code will create a QueueClient, send a message to the queue and then receive the message.

When we run the application we will discover that it is executing correctly:

Revoke

Let’s now make this a little interesting. Let’s remove the QueueUser’s ability to send messages to the Queue and see what happens. To do this we will use the following command:

revoke <operation> <path> <user>

To validate that the permission revoke was successful lets run the show command again. As you can see our revoke command was successful.

Let’s now try to send a message and see what happens.

As expected we get an authentication exception as we should.

Conclusion

With the introduction of the SBAzTool tool there is no excuse for using your “owner” credentials when building applications. The SBAzTool has a wide variety of commands that facilitate managing and even delegating permissions. Since this is a command line tool you can even script these permissions as you provision your Service Bus artifacts.