In a recent statement, Microsoft has announced the general availability of Azure Active Directory (AD) based access control for Service Bus, enabling the option to use identities in combination with Role Based Access Control (RBAC) to authenticate against the service's data endpoints. Moreover, they have also introduced accompanying RBAC roles, providing granular control over granted permissions.
In the past, the preferred option of authentication for Azure Service Bus was to use shared access signatures, a symmetric key known to the token issuer and Service Bus, providing access to the queues, topics, and subscriptions. Consequently, developers would either implement these directly in their application, which often leads to tokens hardcoded in source code or configuration files. Another option was to have a Security Token Service (STS) issuing tokens, while their application authenticated against the STS using Active Directory authentication. However, this introduced a more complex application landscape, development, and maintenance of additional components.
With the introduction of Azure AD capabilities it is now possible to use an identity, which can be a user or a group in Active Directory, and also a service principal or even a Managed Service Identity (MSI). By implementing an MSI, AD creates an identity for an application or service, which it then uses to authenticate against supported services like Key Vault, Azure Storage, and now Service Bus as well. Notably, the addition of these capabilities means that implementation of authentication no longer requires any credentials or tokens, which Joonas Westlin, Azure MVP, explains to have several advantages.
Over the next year, we are sure to see more services enable these capabilities. And through that move closer to the possibilty of having exactly 0 credentials stored anywhere in the app. Zero credentials that you have to manage. Zero credentials that you have to protect.
Additionally, the incorporation of Active Directory capabilities provides clients to use specific features provided by the service, such as the use of conditional access, which enables added restrictions on identities like locations and devices used to initiate authentication. To authenticate, the client requests an access token against Azure AD, which it then passes in the request sent to a Service Bus entity. To clarify, depending on the RBAC role of the identity, this enables specific rights, like sending and receiving data. Given that, it is possible to grant these privileges on different scopes, ranging from an entire Azure subscription to a specific Service Bus entity, which the documentation explains in detail.
- Queue, topic, or subscription: Role assignment applies to the specific Service Bus entity. Currently, the Azure portal doesn't support assigning users/groups/managed identities to Service Bus RBAC roles at the subscription level.
- 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.
Assigning a role to a resource is possible either through the Azure PowerShell, Azure CLI, or Azure Resource Manager templates. Once attached, it can take up to five minutes for the settings to propagate, after which client applications can use their identity to authenticate against the resources.
Source: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-managed-service-identity
