Integration Service Bus

Service Bus authorization rule

Service Bus authorization rule is a shared access policy on a namespace, queue, or topic. It names a key pair and grants Listen, Send, or Manage rights, letting applications create SAS tokens or connection strings scoped to the messaging entity they are allowed to use.

Source: Microsoft Learn - Authenticate access to Azure Service Bus with shared access signatures Reviewed 2026-05-24

Exam trap: Putting RootManageSharedAccessKey into application settings because it works quickly, then discovering every client has Manage rights.
Production check: List authorization rules at namespace and entity scope and confirm no unexpected Manage rights exist outside operations-owned policies.

Practice this topic Microsoft Learn

Article details and learning context

Aliases: Service Bus SAS policy, Service Bus shared access policy, Service Bus authorization policy, SAS authorization rule
Difficulty: fundamentals
CLI mappings: 6
Last verified: 2026-05-24
Review level: template-specs-five-use-cases
Article depth: template-specs-five-use-cases-three-case-studies

Related context No curated learning path mapped yet; use the category trail.

Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

A Service Bus authorization rule is a named access policy for Service Bus when an application uses shared access signatures instead of Microsoft Entra ID. The rule controls whether a client can send messages, listen for messages, or manage the entity. Rules can live at the namespace level or on a queue or topic. The practical idea is simple: give each producer, consumer, or automation job only the permission it needs, then rotate its keys without redesigning the messaging topology.

Why it matters

Authorization rules matter because messaging credentials are often copied into application settings, integration tools, and partner systems. A broad Manage rule can create, delete, send, and listen across an entity, so a leaked connection string can turn into message theft or operational damage. A scoped Send rule for a producer and a scoped Listen rule for a worker reduce blast radius. Good rules also make rotations survivable: regenerate the secondary key, update consumers, switch, then regenerate the primary key. For audits, authorization rules provide a concrete inventory of who can access which broker boundary and whether least privilege is being honored.

Technical context

In Azure architecture, authorization rules sit on the Service Bus control-plane resource model and create data-plane credentials for messaging clients. A namespace-level rule applies broadly across all queues and topics, while entity-level rules scope access more tightly. The rule exposes primary and secondary keys used to sign SAS tokens and connection strings. Operators commonly combine these rules with Key Vault, Azure Policy, managed identities, private endpoints, and deployment automation, especially when legacy clients cannot yet use Microsoft Entra authentication.

Exam context

What to know

operator-ready Azure glossary term with practical use cases, CLI context, and structured case studies

Compare with

Managed identity Service Bus SAS policy Service Bus queue

Where it is used

Where you see it

In the Service Bus namespace, queue, or topic Authorization rules blade, each rule shows Listen, Send, and Manage rights plus key-management options for scoped SAS access reviews.
In Azure CLI output, authorization-rule list and show commands expose rule names, rights, resource IDs, and scope without displaying keys unless a keys command is explicitly used.
In application settings, Key Vault secrets, Function bindings, and integration runbooks, connection strings often reference a specific rule name, revealing which clients still depend on SAS credentials.

Common situations

Give an external producer Send-only access to one queue without exposing Listen or Manage rights.
Rotate a legacy application's Service Bus connection string through primary and secondary keys with minimal downtime.
Replace a namespace-wide root key with entity-level rules before a security audit or partner onboarding.
Separate producer, consumer, and operations permissions so one leaked credential cannot drain or delete messages.
Inventory and retire stale SAS rules after moving first-party workloads to managed identity.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Port logistics platform separates partner send access Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A port logistics operator accepted container status updates from shipping partners through a shared Service Bus queue. Several partners used the same namespace-level connection string, making it impossible to revoke one sender without disrupting everyone.

Goals

Replace shared namespace credentials with partner-specific Send-only rules.
Rotate existing keys without stopping gate automation messages.
Prove no partner could listen to or manage queue data.
Reduce credential-revocation time during partner offboarding.

Approach using Service Bus authorization rule

The integration team created one Service Bus authorization rule per partner on the inbound container-update queue. Each rule granted Send only, and connection strings were stored in partner-specific Key Vault secrets. Internal consumers moved to managed identity and no longer used SAS credentials. Azure CLI runbooks listed rule names and rights, renewed secondary keys first, and exported evidence without displaying secrets. Network rules kept the namespace reachable only from approved partner integration ranges, while Azure Monitor tracked unauthorized requests and queue depth during the migration.

Potential outcomes

Partner offboarding dropped from a four-hour shared-key rotation to a 12-minute rule removal.
Security review found zero external credentials with Listen or Manage rights.
No gate automation messages were lost during two staged key-rotation windows.
Audit evidence collection changed from screenshots to repeatable CLI exports.

What to learn

Service Bus authorization rules are most valuable when they turn one risky shared broker key into scoped, revocable access for each producer or consumer.

Scenario 02 Learning platform recovers from exposed messaging secret Scenario, objectives, solution, measured impact, and takeaway.

Scenario

An online education platform discovered that a Service Bus connection string had been committed to a contractor repository. The key had Manage rights at namespace scope and was used by quiz, grading, and notification services.

Goals

Contain the exposed credential without interrupting active classes.
Split senders and listeners into separate least-privilege rules.
Move secrets into Key Vault-backed application settings.
Create a repeatable two-key rotation process for future incidents.

Approach using Service Bus authorization rule

Engineers first used Azure CLI to inventory namespace, queue, and topic authorization rules and map which applications referenced each secret. They created Send-only rules for quiz producers, Listen-only rules for grading workers, and an operations-only Manage rule protected by privileged access. Secondary keys were distributed through Key Vault, applications were restarted in waves, and the old primary key was regenerated only after connection telemetry looked clean. The team also added a policy check that blocked RootManageSharedAccessKey in new app settings.

Potential outcomes

Credential containment completed in 78 minutes without canceling live exam sessions.
Namespace-level application credentials were reduced from six to one operations-only policy.
Future rotation runbooks were shortened from 19 manual steps to 7 scripted checks.
Unauthorized connection attempts fell to zero after the exposed key was regenerated.

What to learn

A clean authorization-rule model gives teams room to rotate compromised Service Bus secrets without turning a security incident into an outage.

Scenario 03 Insurance marketplace limits carrier integration access Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A specialty insurance marketplace exchanged quote requests with multiple carriers through Service Bus topics. Carriers needed to publish responses, but auditors objected to broad credentials that could read competitor messages.

Goals

Scope every carrier credential to its assigned response topic.
Prevent carriers from listening to brokered quote traffic.
Document rights for annual SOC 2 evidence packages.
Keep onboarding time below one business day.

Approach using Service Bus authorization rule

The platform team created topic-level Service Bus authorization rules that granted Send only for each carrier response path. Internal subscriptions used managed identities and were isolated from external SAS policies. Onboarding automation created the rule, stored the connection string in a carrier-specific secure handoff process, and tagged the topic with owner and contract metadata. Azure CLI generated an evidence file listing rule names, rights, scopes, and resource IDs without exposing keys. The operations team scheduled quarterly secondary-key rotations and monitored failed authorization attempts by namespace.

Potential outcomes

Carrier onboarding time stayed under six hours while adding least-privilege evidence.
No external rule granted Listen or Manage rights after the redesign.
SOC 2 access-review preparation dropped from three days to half a day.
A terminated carrier credential was revoked in 9 minutes without affecting other carriers.

What to learn

Entity-level authorization rules let Service Bus support partner integrations without making every partner a trusted broker administrator.

Azure CLI

I use Azure CLI for authorization-rule work because access reviews are faster and safer when every rule, right, and key-rotation step is scriptable. The portal is fine for a single namespace, but real estates have many queues, topics, subscriptions, and stale application settings. CLI lets me list namespace, queue, and topic rules, compare rights across environments, export evidence for security reviews, and rotate keys in a controlled order. After ten years of Azure incidents, I do not trust memory during credential cleanup. I want exact output showing rule names, rights, resource IDs, and timestamps before touching production secrets or disabling listeners during audits.

Useful for

List namespace, queue, and topic authorization rules before an access review or security exception renewal.
Show a specific rule to confirm whether it grants Send, Listen, Manage, or an overbroad combination.
Create entity-level Send or Listen rules for legacy clients that cannot use Microsoft Entra authentication yet.
Renew a primary or secondary key in a planned rotation while keeping the other key available for rollback.
Export rule names and rights without exposing connection strings for audit evidence and drift comparison.

Before you run a command

Confirm tenant, subscription, resource group, namespace, entity scope, and whether the rule is namespace-wide or tied to one queue or topic.
Check your RBAC permissions, because listing keys, renewing keys, creating rules, or deleting rules can expose secrets or break clients.
Identify applications, Key Vault secrets, Functions settings, partners, and pipelines that currently depend on the rule before changing rights or keys.
Use safe output formats, avoid writing keys to logs, and capture current rule settings before any destructive or rotation command.

What the output tells you

Rule list output tells you which named SAS policies exist at the inspected scope and whether access is concentrated in too few shared rules.
Rule show output highlights the rights array, so you can separate Send-only producers from Listen consumers and dangerous Manage policies.
Keys output returns primary and secondary connection strings, which means the terminal, shell history, and pipeline logs become sensitive immediately.
Resource IDs reveal whether the rule belongs to the namespace, a queue, or a topic, which changes blast radius during rotation.

Mapped commands

Term-specific Azure CLI operations

direct

az servicebus namespace authorization-rule list --namespace-name <namespace> --resource-group <resource-group> --output table

az servicebus namespace authorization-rulediscoverIntegration

az servicebus namespace authorization-rule show --namespace-name <namespace> --resource-group <resource-group> --name <rule-name> --output json

az servicebus namespace authorization-rulediscoverIntegration

az servicebus queue authorization-rule list --namespace-name <namespace> --resource-group <resource-group> --queue-name <queue> --output table

az servicebus queue authorization-rulediscoverIntegration

az servicebus topic authorization-rule list --namespace-name <namespace> --resource-group <resource-group> --topic-name <topic> --output table

az servicebus topic authorization-rulediscoverIntegration

az servicebus queue authorization-rule create --namespace-name <namespace> --resource-group <resource-group> --queue-name <queue> --name <rule-name> --rights Send

az servicebus queue authorization-rulesecureIntegration

az servicebus queue authorization-rule keys renew --namespace-name <namespace> --resource-group <resource-group> --queue-name <queue> --name <rule-name> --key PrimaryKey

az servicebus queue authorization-rule keyssecureIntegration

Architecture context

At architecture level, a Service Bus authorization rule is an access boundary, not just a setting. The safest design uses Microsoft Entra ID and managed identity for first-party workloads, then keeps SAS rules for legacy systems, external partners, or tools that cannot use Entra yet. Namespace-level rules belong in a small operations-only lane because they can cover every entity. Entity-level Send and Listen rules fit producers and consumers better. Architects should model where connection strings are stored, how primary and secondary keys rotate, which rules are allowed by policy, and how private network access interacts with credentials. A good design avoids one shared root key becoming the unofficial integration contract for every app.

Security: Security impact is direct because authorization rules create credentials that can send, receive, or manage messages. The RootManageSharedAccessKey should not be placed in application configuration, pipelines, or partner handoffs. Use entity-level rules for producers and consumers, store connection strings in Key Vault, and prefer Microsoft Entra authentication where clients support it. Treat key listing as sensitive because it exposes primary and secondary connection strings. Rotate keys with a planned two-key process and verify dependent apps have moved before regenerating the old key. Network controls and private endpoints reduce exposure, but they do not fix an overprivileged SAS rule during reviews.
Cost: Cost impact is indirect because authorization rules do not have their own meter, but they strongly influence operational cost. An overbroad rule can let unused or abandoned clients keep sending messages that create transactions, backlog, dead-letter volume, logging, and investigation work. Weak rotation practices increase incident response costs when secrets leak. Entity-level rules can reduce the scope of cleanup and shorten audits, while namespace-level sprawl makes every investigation slower. There is also a people-cost dimension: teams lose time when connection strings are undocumented or shared across environments. Good rule hygiene prevents unnecessary broker activity and expensive emergency rotations and audits.
Reliability: Reliability impact is direct because bad rule changes can immediately stop producers, consumers, Functions triggers, Logic Apps, and container workers from connecting. Rotating both keys at once, deleting a rule still used by an app, or switching rights from Listen to Send can create message backlog and retry storms. Reliable operations keep separate credentials for senders and receivers, stage rotations through secondary keys, and monitor active messages and dead-letter growth during the change. Keep rollback connection strings available until validation passes. For critical workflows, test failover and disaster-recovery namespaces with the same permission model so a recovery event does not expose missing credentials.
Performance: Runtime performance is usually indirect because the rule itself does not change broker throughput after a client is authenticated. Performance problems appear when bad permissions cause retries, reconnect loops, failed Functions triggers, or consumers that cannot listen while messages accumulate. Key rotation can also create temporary connection churn if clients refresh secrets at different times. From an operational performance angle, CLI inventories make diagnosis faster because engineers can quickly distinguish credential failure from network, lock, or consumer-code failure. Least-privilege rules also reduce noisy misuse, such as a producer accidentally reading from queues during load tests during live incident calls and deployments.
Operations: Operators inspect authorization rules during access reviews, incident response, key rotation, and environment drift checks. Typical work includes listing rules at namespace, queue, and topic scope; checking rights; exporting rule names without exposing keys; and confirming application settings reference the intended credential. Changes should be tracked like any other production secret change, with an owner, reason, affected apps, rollback path, and post-change connectivity test. Monitoring should watch failed requests, unauthorized connection attempts, and growing queue depth after rotations. Documentation matters because a forgotten rule can outlive the application that originally required it. I also record owner, expiry expectations, and next rotation date.

Common mistakes

Putting RootManageSharedAccessKey into application settings because it works quickly, then discovering every client has Manage rights.
Rotating primary and secondary keys during the same window without proving each dependent client has switched to the new credential.
Creating namespace-level rules for partner systems when a queue-level Send-only rule would meet the integration requirement.
Logging connection strings from CLI or deployment output and accidentally turning an access review into a credential exposure incident.

On this page