Azure Event Hubs: Role Based Access Control (RBAC) in action

DZone 's Guide to

Azure Event Hubs: Role Based Access Control (RBAC) in action

Use Service Principal to control access to your Event Hubs resources

· Cloud Zone ·
Free Resource

Azure Event Hubs is a streaming platform and event ingestion service that can receive and process millions of events per second. In this blog, we are going to cover one of the security aspects related to Azure Event Hubs.

Shared Access Signature (SAS) is a commonly used authentication mechanism for Azure Event Hubs which can be used to enforce granular control over the type of access you want to grant - it works by configuring rules on Event Hubs resources (namespace or topic). However, it is recommended that you use Azure AD credentials (over SAS) whenever possible since it provides similar capabilities without the need to manage SAS tokens or worry about revoking a compromised SAS.

There a couple of ways in which you can do this:

We will explore the second option i.e. how to use Azure Active Directory based authentication in your Azure Event Hubs client applications. With a practical example, you will learn:

  • Overview of Azure Event Hubs roles
  • How to use Azure CLI to configure Service Principal and RBAC policies for Event Hubs
  • Event Hubs supports multiple programming languages with specific SDKs, and we'll see how to use RBAC with Java and Go clients.

The code is available in this GitHub repo - https://github.com/abhirockzz/azure-eventhubs-rbac-example


This section provides a high level overview for you to get an understand the key terminologies: Roles, Security principals and Role based access control (RBAC).

Roles: Azure Event Hubs defines specific roles each of which allows you to take specific action on its resources - Data Owner, Data Sender, Data Receiver. They are quite self explanatory - Sender and Receiver roles only allow send and receive respectively, while the Owner role is like an admin privilege which allows you to complete access.

For details on these roles, please refer to their documentation links - Azure Event Hubs Data Owner, Azure Event Hubs Data Sender, Azure Event Hubs Data Receiver

RBAC, Service Principals: Service Principals are entities to who, these roles are granted - this is "Role Based Access Control" since the role you grant to the Service Principal defines which actions they can perform - in this case, the actions are: send, receive or everything!

The Scenario

Here is the example we will use to learn this. There are two Event Hubs client apps - a Java producer and a Go consumer. We will configure fine grained rules (i.e. enforce RBAC) such that:

  • Java app can only send messages to an Event Hubs topic, and,
  • Go app can only receive messages from an Event Hubs topic

Here are relevant code snippets:

In the Java producer client, the DefaultAzureCredentialBuilder is used.


By convention (default), the Java SDK tries to read pre-defined environment variables for Service Principal info and authenticate based on that. If this does not work, it falls back to try the SAS auth mechanism and looks for another set of environment variables

Similarly, in the Go consumer client, the Event Hubs client creation process is greatly simplified as well


The developer experience is uniform across SDKs and NewHubWithNamespaceNameAndEnvironment does the same thing as the DefaultAzureCredentialBuilder in terms of following a fixed convention attempting to authenticate using Azure Active Directory (AAD) backed Service Principal first, followed by SAS mechanism

With that said, you do need a few things to get through this tutorial:


You will need a Microsoft Azure account. Go ahead and sign up for a free one!

Azure CLI or Azure Cloud Shell — you can either choose to install the Azure CLI if you don't have it already (should be quick!) or just use the Azure Cloud Shell from your browser.

Let's get going.. start off by setting up Azure Event Hubs

Setup Azure Event Hubs

This is all done via Azure CLI, but you can also use the Azure Portal if you like. The end goal is to have an Azure Event Hubs namespace along with an Event Hub (aka topic)

Create an Azure resource group if you don't have one already:


Use az eventhubs namespace create to create an Event Hubs namespace


And then create an Event Hub using az eventhubs eventhub create


Now for the the key parts...

Security Configuration

We will use Azure CLI to create Service Principals using az ad sp create-for-rbac

For the sender application (we name it eh-sender-sp)


You will get a JSON response as such - please note down the appId, password and tenant


For the receiver application (we name it eh-receiver-sp)


You will get a JSON response - please note down the appId, password and tenant

Enforce RBAC

Going through this process using CLI involves a few steps, but it's beneficial in the long term e.g. for automation. It can also be carried out using the Azure Portal

Get the IDs for both the roles using az role definition list



EH_SENDER_ROLE_ID=$(az role definition list -n "Azure Event Hubs Data Sender" -o tsv --query '[0].id')
EH_RECEIVER_ROLE_ID=$(az role definition list -n "Azure Event Hubs Data Receiver" -o tsv --query '[0].id')

Azure Event Hubs Data Sender and Azure Event Hubs Data Receiver are the role names

Get the subscription ID for Azure Event Hubs namespace using az eventhubs namespace show


Assign roles using az role assignment create


Alright, you're all set!

Let's Try It Out

Clone the sample apps from GitHub


Start the Go consumer application:


The program will block, waiting for events....

In another terminal, start producer application - this will just send 10 events end exit (re-run if you want to send more events)


You should see the received events in the consumer app terminal!

As an exercise, to simulate an error scenario, you exchange can the client details for sender and consumer apps to see how they behave.


Hopefully this was useful in demonstrating how to use RBAC for Event Hubs applications using Azure Active Directory. In a future blog post, I will try to cover Managed Identity as well. Until then, stay tuned!

azure, cloud, go, java, messaging, security, tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}