Authenticate a managed identity with Microsoft Entra ID to access Azure Service Bus resources

Managed identities for Azure resources provide Azure services with an automatically managed identity in Microsoft Entra ID. You can use this identity to authenticate to any service such as Azure Service Bus that supports Microsoft Entra authentication, without having credentials in your code. If you aren't familiar with managed identities, see Managed identities for Azure resources before proceeding to read through this article.

Here are the high-level steps to use a managed identity to access a Service Bus entity:

1. Enable managed identity for your client app or environment. For example, enable managed identity for your Azure App Service app, Azure Functions app, or a virtual machine in which your app is running. Here are the articles that help you with this step:

   • Configure managed identities for App Service and Azure Functions
   • Configure managed identities for Azure resources on a VM

2. Assign Azure Service Bus Data Owner, Azure Service Bus Data Sender, or Azure Service Bus Data Receiver role to the managed identity at the appropriate scope (Azure subscription, resource group, Service Bus namespace, or Service Bus queue or topic). For instructions to assign a role to a managed identity, see Assign Azure roles using the Azure portal.

3. In your application, use the managed identity and the endpoint to Service Bus namespace to connect to the namespace. For example, in .NET, you use the ServiceBusClient constructor that takes TokenCredential and fullyQualifiedNamespace (a string, for example: cotosons.servicebus.windows.net) parameters to connect to Service Bus using the managed identity. You pass in DefaultAzureCredential, which derives from TokenCredential and uses the managed identity.

   Important

   You can disable local or SAS key authentication for a Service Bus namespace and allow only Microsoft Entra authentication. For step-by-step instructions, see Disable local authentication.

Azure built-in roles for Azure Service Bus

Microsoft Entra authorizes access to secured resources through Azure role-based access control (Azure RBAC). Azure Service Bus defines a set of Azure built-in roles that encompass common sets of permissions used to access Service Bus entities. You can also define custom roles for accessing the data.

Azure provides the following Azure built-in roles for authorizing access to a Service Bus namespace:

• Azure Service Bus Data Owner: Use this role to allow full access to Service Bus namespace and its entities (queues, topics, subscriptions, and filters)
• Azure Service Bus Data Sender: Use this role to allow sending messages to Service Bus queues and topics.
• Azure Service Bus Data Receiver: Use this role to allow receiving messages from Service Bus queues and subscriptions.

To assign a role to a managed identity in the Azure portal, use the Access control (IAM) page. Navigate to this page by selecting Access control (IAM) on the Service Bus Namespace page or Service Bus queue page, or Service Bus topic page. For step-by-step instructions for assigning a role, see Assign Azure roles using the Azure portal.

Resource scope

Before you assign an Azure role to a managed identity, determine the scope of access that the managed identity should have. Best practices dictate that it's always best to grant only the narrowest possible scope.

The following list describes the levels at which you can scope access to Service Bus resources, starting with the narrowest scope:

• Queue, topic, or subscription: Role assignment applies to the specific Service Bus entity.

• Service Bus namespace: Role assignment spans the entire topology of Service Bus under the namespace and to the consumer group associated with it.

• Resource group: Role assignment applies to all the Service Bus resources under the resource group.

• Subscription: Role assignment applies to all the Service Bus resources in all of the resource groups in the subscription.

  Note

  Keep in mind that Azure role assignments may take up to five minutes to propagate.

Currently, the Azure portal doesn't support assigning users, groups, or managed identities to Service Bus Azure roles at the topic's subscription level. Here's an example of using the Azure CLI command: az-role-assignment-create to assign an identity to a Service Bus Azure role:

az role assignment create \
    --role $service_bus_role \
    --assignee $assignee_id \
    --scope /subscriptions/$subscription_id/resourceGroups/$resource_group/providers/Microsoft.ServiceBus/namespaces/$service_bus_namespace/topics/$service_bus_topic/subscriptions/$service_bus_subscription

For more information about how built-in roles are defined, see Understand role definitions. For information about creating Azure custom roles, see Azure custom roles.

Using SDKs

In .NET, the ServiceBusClient object is initialized by using a constructor that takes a fully qualified namespace and a TokenCredential. The DefaultAzureCredential derives from TokenCredential, which automatically uses the managed identity configured for the app. The flow of the managed identity context to Service Bus and the authorization handshake are automatically handled by the token credential. It's a simpler model than using SAS.

var client = new ServiceBusClient('cotosons.servicebus.windows.net', new DefaultAzureCredential());

You send and receive messages as usual using ServiceBusSender and ServiceBusReceiver or ServiceBusProcessor.

For complete step-by-step instructions to send and receive messages using a managed identity, see the following quickstarts. These quickstarts have the code to use a service principal to send and receive messages, but the code is the same for using a managed identity.

• .NET.
• Java.
• JavaScript
• Python

Next steps

See this .NET web application sample on GitHub, which uses a managed identity to connect to Service Bus to send and receive messages. Add the identity of the app service to the Azure Service Bus Data Owner role.