A Service Bus SAS policy is a named access rule that creates keys for connecting to Service Bus without Microsoft Entra authentication. The policy decides whether a client can send, listen, manage, or combine those rights at a namespace, queue, or topic scope. In plain terms, it is a key-based access path. It is useful for some legacy, cross-platform, or partner integrations, but it must be handled like a secret because anyone with the key can create tokens within that policy scope.
Azure Service Bus SAS policy, Service Bus shared access policy, Service Bus authorization rule
Difficulty
fundamentals
CLI mappings
4
Last verified
2026-05-24
Microsoft Learn
A Service Bus SAS policy is a shared access authorization rule on a namespace, queue, or topic. It defines rights such as Send, Listen, or Manage and provides keys used to create shared access signature tokens or connection strings. for controlled access.
Technically, SAS policies are authorization rules attached to Service Bus namespaces, queues, or topics. Each rule has rights and primary and secondary keys. Clients can use those keys directly through connection strings or generate time-bound SAS tokens. The control plane manages the rule, while the data plane accepts tokens signed from the policy key. In modern Azure designs, SAS policies often coexist with Azure RBAC and managed identities, so architects decide where key-based access remains necessary and where identity-based access should replace it.
Why it matters
SAS policies matter because they are powerful, portable, and easy to misuse. A namespace-level Manage policy can grant broad control over every queue and topic, while a scoped Send policy might safely support a single partner feed. The difference is huge during incidents, audits, and key rotation. Poor SAS governance leads to shared connection strings in code, unknown consumers, weak rotation habits, and excessive permissions. A good SAS policy design limits scope, separates send from listen, uses secondary keys for rotation, records ownership, and gradually moves trusted Azure workloads toward managed identity where possible. It also makes emergency revocation more precise when one integration is suspected.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the Azure portal Shared access policies page, each policy shows its name, rights, primary key, secondary key, and connection strings for the selected scope.
Signal 02
In Azure CLI output, authorization-rule list or show commands reveal whether a SAS policy belongs to a namespace, queue, or topic and which rights it grants.
Signal 03
In application settings, Key Vault secrets, or partner onboarding documents, SAS policies appear as Service Bus connection strings or generated shared access signature tokens. securely.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Give an external partner send-only access to one queue without granting namespace management rights.
Rotate compromised or aging Service Bus connection strings using primary and secondary keys safely.
Separate producer and consumer secrets so a receive credential cannot publish unauthorized messages.
Inventory broad RootManageSharedAccessKey usage before moving Azure workloads to managed identity.
Create a temporary scoped policy for a migration tool, then remove it after cutover evidence is captured.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A manufacturing company let suppliers submit shipment notices through a small gateway that used the namespace RootManageSharedAccessKey. A supplier-side breach forced the team to assume the broad key was exposed.
🎯Business/Technical Objectives
Limit supplier access to send-only on one inbound queue.
Rotate exposed credentials without stopping plant receiving operations.
Remove manage rights from non-operator integrations.
Create audit evidence for supplier security reviews.
✅Solution Using Service Bus SAS policy
Engineers created a Service Bus SAS policy scoped to the inbound shipment queue with Send rights only. They stored the new connection string in Key Vault, updated the supplier gateway, and monitored incoming messages before renewing the old namespace key. A CLI rotation script listed existing authorization rules, showed rights, generated the new key, and captured evidence without printing secrets into the shared report. After the gateway used the scoped policy for a week, operators renewed both RootManageSharedAccessKey values and restricted its use to break-glass administration. Supplier documentation was changed so future integrations request queue-scoped policies instead of namespace keys.
📈Results & Business Impact
Supplier traffic continued with less than five minutes of maintenance-window interruption.
Manage rights were removed from 14 partner-facing configuration paths.
Security review time for the supplier portal dropped from two weeks to three days.
No unrelated queue or topic had to rotate because the new policy was scoped narrowly.
💡Key Takeaway for Glossary Readers
A SAS policy is safest when its scope and rights match one integration instead of the whole namespace.
Case study 02
Film festival kiosks receive temporary ticket validation access
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A film festival deployed temporary lobby kiosks that validated tickets against a Service Bus request queue. The devices could not use managed identity because they ran outside the organizer tenant.
🎯Business/Technical Objectives
Issue time-boxed queue access for temporary devices.
Prevent kiosks from managing entities or reading unrelated messages.
Rotate credentials quickly after the festival closes.
Avoid exposing secrets in volunteer setup instructions.
✅Solution Using Service Bus SAS policy
The technology team created a queue-scoped SAS policy with Send rights for kiosk validation requests. A separate listen policy was used only by the validation service. Connection strings were stored in the device management platform, not printed in volunteer guides. Operators used Azure CLI to create the policies, list rights, and renew keys during dress rehearsal. The runbook included a post-event step to delete the temporary kiosk policy and confirm no messages arrived from the old credential. Metrics for incoming kiosk messages and authorization failures were reviewed daily during the festival.
📈Results & Business Impact
Kiosks processed 96,000 validation requests without receiving or managing Service Bus entities.
Post-event credential retirement finished in 18 minutes across all devices.
No volunteer documentation contained raw connection strings after the process changed.
Authorization failures identified three kiosks still using an old rehearsal credential before opening night.
💡Key Takeaway for Glossary Readers
Temporary integrations can use SAS safely only when rights, storage, rotation, and retirement are designed up front.
Case study 03
Legal discovery team controls third-party export access
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A legal discovery team used a third-party tool to send export-complete notifications into Service Bus. The original connection string was copied among contractors and remained active after the matter closed.
🎯Business/Technical Objectives
Create matter-specific credentials for each export engagement.
Stop contractors from reusing old notification access.
Preserve evidence of key rotation and policy deletion.
Reduce support effort when new matters start.
✅Solution Using Service Bus SAS policy
The platform team introduced a per-matter Service Bus SAS policy scoped to the export notification topic with Send rights only. Matter IDs were embedded in policy names and tags on the Key Vault secret. At closeout, a CLI workflow listed the policy, captured its rights and scope, renewed keys if a hold period was needed, then deleted the policy after final approval. The discovery application validated incoming message properties so old matter IDs were rejected. New matter onboarding reused the same script, which prevented contractors from sharing a long-lived namespace key across unrelated legal work.
📈Results & Business Impact
Old contractor credentials were eliminated for 27 closed matters.
New matter onboarding time fell from four hours to 35 minutes.
Audit packets included policy scope, rights, rotation date, and deletion evidence.
Unauthorized sends from an old tool configuration stopped immediately after policy deletion.
💡Key Takeaway for Glossary Readers
Matter-specific SAS policies make key-based access governable when legal or partner workflows cannot use identity-based authentication.
Why use Azure CLI for this?
I use Azure CLI for Service Bus SAS policies because secret-bearing access has to be inventoried and rotated with discipline. The portal can list an authorization rule, but CLI lets me find namespace, queue, and topic policies, show rights, create scoped rules, renew primary or secondary keys, and export evidence without clicking through every entity. With ten years of Azure operations behind me, I assume connection strings have spread farther than expected. CLI gives me the repeatable rotation workflow: identify scope, confirm rights, renew one key, update consumers, test, then renew the other key. It also reduces the chance that rotation depends on one engineer's memory.
CLI use cases
List authorization rules across namespaces, queues, or topics to find broad or stale SAS policies.
Show one policy and verify whether it grants Send, Listen, Manage, or an unsafe combination of rights.
Create a scoped send-only or listen-only policy for a specific queue or topic integration.
Renew the primary or secondary key during planned rotation while preserving application continuity.
Export policy evidence for an audit without exposing keys in shared reports.
Before you run CLI
Confirm whether the SAS policy is scoped to a namespace, queue, or topic before changing keys or rights.
Identify every application, partner, Key Vault secret, and app setting using the primary or secondary key.
Avoid printing connection strings in shared terminals, logs, screenshots, or command history during key work.
Plan rotation order carefully: update consumers to the alternate key, test message flow, then renew the old key.
What output tells you
Rights show whether the policy can Send, Listen, Manage, or combine privileges that may be broader than required.
Scope and resource ID show whether the authorization rule affects an entire namespace or one entity.
Key-list output exposes primary and secondary connection strings; handle it as secret material immediately.
Provisioning state and timestamps help distinguish newly created policies from stale migration leftovers.
Mapped Azure CLI commands
Term-specific Azure CLI operations
direct
az servicebus namespace authorization-rule list --resource-group <resource-group> --namespace-name <namespace> --output table
az servicebus namespace authorization-rulediscoverIntegration
az servicebus queue authorization-rule keyssecureIntegration
az servicebus topic authorization-rule show --resource-group <resource-group> --namespace-name <namespace> --topic-name <topic> --name <policy> --output json
az servicebus topic authorization-rulediscoverIntegration
Architecture context
Architecturally, a Service Bus SAS policy is an access boundary for key-based clients. I use it only when a workload cannot use managed identity or Microsoft Entra tokens cleanly, such as a partner gateway, legacy service, or non-Azure appliance. The scope should be as narrow as the integration allows: queue send, topic send, or subscription listen rather than namespace manage. Designs should include owner tags, expiration expectations for generated tokens, storage location for connection strings, rotation cadence, and an exit plan to identity-based access when the client platform supports it. That exception should be reviewed regularly, not allowed to become permanent sprawl.
Security
Security is the main concern for SAS policies. The key can be copied, stored in code, pasted into tickets, or leaked through logs. Anyone with it can generate tokens with the rights granted by the policy until keys are renewed or the rule is removed. Manage rights are especially risky because they can change entities, not just send or receive messages. Operators should prefer managed identities for Azure workloads, use scoped SAS rules when keys are unavoidable, rotate both primary and secondary keys, store secrets in Key Vault, and monitor unusual send or receive patterns. Compromised keys should trigger documented revocation and traffic review.
Cost
SAS policies do not create a direct line item, but they affect cost through operational labor, incident impact, and uncontrolled usage. A leaked send key can drive unexpected message volume, trigger consumer scaling, increase logging, and create cleanup work. Broad policies also make it harder to attribute traffic to one partner or application. Scoped policies support better chargeback because each integration can have its own rule and monitoring. Cost reviews should include stale policies, shared namespace keys, high-volume senders without ownership, and the labor required to rotate secrets across application settings and external partners. Scoped policies make that investigation faster and less expensive.
Reliability
SAS policy reliability is mostly about avoiding accidental outages during key rotation and scope changes. Renewing the wrong key before all clients have moved can stop senders or receivers immediately. Deleting a policy used by hidden consumers can break integrations with little diagnostic detail beyond authentication failures. Good runbooks use primary and secondary keys to stage rotation, test updated consumers, and verify message flow before completing the second renewal. Reliability also improves when policies are scoped clearly because revoking one partner feed should not disable unrelated queues, topics, or support tools. Rotation drills should be practiced before a real leak or expiry panic.
Performance
A SAS policy does not normally change broker throughput by itself, but authentication scope and secret hygiene affect operational performance. When many applications share one policy, diagnosing a traffic spike or bad client takes longer because all connections look related. Scoped policies let operators isolate senders, rotate one integration, and compare metrics more quickly. Token generation should happen safely without creating a fresh token for every message in high-volume clients. Performance reviews should focus on message flow, throttling, authorization failures, and whether policy design helps or slows incident isolation. That clarity speeds troubleshooting during authentication storms and traffic spikes under pressure.
Operations
Operators manage SAS policies by listing authorization rules, reviewing rights, checking where connection strings are stored, rotating keys, and cleaning up unused policies. They should record whether a rule is namespace, queue, or topic scoped and who owns every consumer using it. During incidents, they may renew a suspected leaked key, disable a partner feed, or compare authentication failures with recent rotation work. Day-to-day governance includes detecting RootManageSharedAccessKey usage, replacing broad policies with scoped ones, and ensuring Key Vault, pipelines, and application settings stay synchronized during rotation. Evidence should separate safe metadata from secret values before sharing with auditors securely.
Common mistakes
Using RootManageSharedAccessKey for application runtime when a scoped send or listen policy would be enough.
Renewing both keys at once and breaking every client that still uses the old connection string.
Pasting connection strings into tickets, logs, runbooks, or source files where they are hard to revoke cleanly.
Forgetting topic or queue-level policies during audits because only namespace policies were reviewed.