Security

Clients access Service Bus resources by presenting an access token. The token specifies the URI to be accessed and an expiry time of the token.

Note

The Service Bus Namespace owner account (RootManageSharedAccessKey) should not be shared or embedded in code. This is a highly privileged account that gives rights to delete and create Azure artifacts and should only be used for administrative tasks.

There are two options available for clients to be authenticated to allow access to the Service Bus:

  • Shared Access Signature (SAS): This provides authentication using a shared key configured on the namespace or on a Service Bus entity (Queues, Topics, and Subscriptions) with specific rights for listening, sending, or managing. The key is then used to generate a SAS token, which the client uses to authenticate with the Service Bus.
  • Access Control Service (ACS): This provides identity federation with various providers. To access the Service Bus entities, the client requests a Simple Web Token (SWT) from the ACS. The token is then sent with every request to the Service Bus.

Note

The Azure Service Bus product team has recommended to use SAS tokens whenever possible as it provides more granular level of control to resources.

While creating a Service Bus Queue using the Azure portal, the only available authentication option is SAS. To use ACS, you will need to use the following Azure PowerShell command to create the namespace and associated ACS artifacts:

New-AzureSBNamespace <namespaceName> "<Region>" -CreateACSNamespace $true

More information on this can be found at: https://msdn.microsoft.com/en-us/library/azure/dn170478.aspx.

Service Bus provides the following three types of access rights that can be assigned to shared access policies:

  • Listen: This is receiving messages from the queue
  • Send: This is sending messages to the queue
  • Manage: This allows creating, changing, or deleting entities

Handling service bus subscription security

When setting up subscriptions (which will be explained in the upcoming sections), you cannot implement authorization policies on the subscription queue, only on the topic itself. To work around this scenario, you can provision a service bus queue for each subscription and then set authorization policies on these queues.

Using the auto-forwarding feature on a queue or subscription, you set the ForwardTo property to the other queue that has the authorization polices applied. When a message arrives in the subscription queue, it will be automatically forwarded to the queue defined in the ForwardTo property. Only consumers with the Listen policy will then be allowed to read the messages.

Note

Auto-forwarding a message from one queue to another will be billed as another billable operation.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset