Share via

Change to Azure Service Bus Portal: Default Authentication Mechanism for Service Bus Namespaces now SAS

  • Article

What are we changing

A change has been made to the user experience in the Azure portal for Service Bus namespace creation.  When creating a Service Bus namespace in the Azure portal only SAS authentication will be enabled by default.  The accompanying ACS namespace will no longer be created and paired to the Service Bus namespace. 

 

Why did we change it

The vast majority of our customers only use ACS for the access key functionality, not for identity federation. SAS provides better capabilities and higher scale for these use cases so we have decided to make it our default in the portal experience. This simplifies our customer experience for the majority of use cases.

 

How does this impact customers and how can you use ACS

Current namespaces will not be affected in any way. Customers who were dependent on ACS features such as claims and federation will also not be affected if they use automation to create their namespaces; namely PowerShell, the Azure CLI and the REST API. 

 

In order to create a new namespace in PowerShell use the cmdlet New-AzureSBNamespace

 

New-AzureSBNamespace -Name 'MyNamespace' -Location 'Central US'

 

This will create the Service Bus namespace and a paired ACS namespace.  The ACS connection string will appear in the Azure portal. 

 

In the future there will be a new optional parameter to this cmdlet which will allow you to control ACS namespace creation.  At first this cmdlet will default to creating ACS namespaces, but further in the future this default will be reversed and ACS namespaces will not be created by default. 

 

In Azure CLI, you will run:

sb namespace create ‘MyNamespace’ ‘Central US’

 

For the REST API: 

By default the ACS companion namespace will be created, unless you specified a x-ms-version header bigger than '2014-05'

 

As we continue to expand and improve our Azure messaging platform the Service Bus team will continually examine customer usage, dependencies, and impact.  Creating namespaces without a paired ACS namespace is faster and creates one less dependency for our customers.  This change streamlines the user experience for the majority of our customers today. 

 

Are we moving away from ACS?

No! ACS is still fully supported in Service Bus and will be for the foreseeable future.  As Azure Active Directory (AAD) expands to support more service federation identity scenarios we will increasingly align with the AAD service offering.

Comments

  • Anonymous
    September 29, 2014
    I think this is a very bad practise to change the behaviour of the system. When I did the set up of service bus for the first time, everything was fine. But when I try to do it again I had troubles because of this changes. And you know, it wasn't easy to fine this post to solve issues

  • Anonymous
    October 04, 2014
    how does this change affect the relays ?

  • Anonymous
    October 07, 2014
    The comment has been removed

  • Anonymous
    October 08, 2014
    Sorry to hear about your experience here.  Relay requires ACS, so you will need to create namespaces via PowerShell or the REST API in order to use Relay in them.  We'll work on getting those documents updated.

  • Anonymous
    October 22, 2014
    I too found this change the hard way. I tried to create a namespace on the portal and noticed the ACS bits were missing. I tried PowerShell and got it working, but it was days later before I discovered the SAS info online. Now I'm trying to work my way through switching over to SAS (it looks like we are being ACS throttled), but we use multiple namespaces that should share keys. This was easy to accommodate under ACS, but it looks like the portal will only generate new keys, not allow you to give it a key. I believe I can do so programmatically, but the documentation is a bit thin. I have gotten SAS working with 1 namespace and the speed difference is apparent. We spin up a bunch of subscriptions to queues on start up and the time in the debug instance goes from 2-4 seconds down to about 1 second.

  • Anonymous
    October 31, 2014
    I'm trying to create new namespace by using the powershell commend in this article, but after typing in the command, it is asking  parameter value for NamespaceType. I've tried every possible NamespaceType I can think of, but can't get through this. I'm also not able to find any documentation regarding this online. Any suggestion or reference?

  • Anonymous
    November 02, 2014
    Same issue as Aki, looks like commands updated with extra parameters but the documentation hasn't been.

  • Anonymous
    November 04, 2014
    I'm running into the same issue. The New-AzureSBNamespace is asking for a new parameter, NamespaceType, which isn't documented (yet?). Have you guys found what to use for this already?

  • Anonymous
    November 04, 2014
    I found out this is indeed a new thingy in the API. The post over here describes it and how to solve it: azure.microsoft.com/.../azure-service-bus-namespacetype-default-value-change

  • Anonymous
    November 12, 2014
    wow we just found this out the hard way also after we had to re-create a service bus namespace due to it failing for no known reason.  This stuff is becoming very undependable for our up-time needs, and we are beginning to regret depending on it.

  • Anonymous
    November 18, 2014
    We downloaded the Azure Powershell and attempted to set this up – we get this error message: "New-AzureSBNamespace : Cannot convert 'System.String' to the type 'System.Nullable 1 [System.Boolean]' required by parameter 'CreateACSNamespace'. " Documentation from MS Azure tends to be pretty light on this topic were wondering if you had any experience with this issue or any suggestions?

  • Anonymous
    November 25, 2014
    If Relay requires ACS and Relay is an important part of the Azure Service Bus, how can you just change the default behavior to use SAS instead of ACS, without also implementing SAS in Relays? Morten

  • Anonymous
    December 01, 2014
    I have found a simple solution. Instead of using : var sharedSecretServiceBusCredential = new TransportClientEndpointBehavior(); sharedSecretServiceBusCredential.TokenProvider = TokenProvider.CreateSharedSecretTokenProvider(issuerName, issuerSecret); Use: var sharedSecretServiceBusCredential = new TransportClientEndpointBehavior(); sharedSecretServiceBusCredential.TokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(policyName, policyKey); You can find policyName & policyKey values in "Configuration" tab -> "Shared access key generator"

  • Anonymous
    December 10, 2014
    Thanks a ton Shirshank Deepankar, your suggestion made my day.Was trying to get it working since morning.

  • Anonymous
    January 01, 2015
    Its sad the way Microsoft is going. you are turning off developers that want to develop on your platform because you are becoming consistently inconsistent. Every time I need to do something simple I go Azure website then come to realize things have change, now I have to figure out how to work with the new thing. I have been a Microsoft Developer since the Window days. with all the goings am thinking of switching to open source and javascript.

  • Anonymous
    January 05, 2015
    Hi, I am also facing same issue, my old ACS is not working and trying to create new one, not able to see the option for create ACS and Relay. My App is faling due to this reason.

  • Anonymous
    January 07, 2015
    Just use the steps as provided by the "Shirshank Deepankar " to get resolve the Issue.

  • Anonymous
    February 22, 2015
    But you can only create up to 12 Shared Access Policies... Does anyone know if you can enable ACS on an existing namespace?

  • Anonymous
    March 10, 2015
    Hi, Will old SB created prior to this change  using ACS still work?

  • Anonymous
    March 15, 2015
    The comment has been removed

  • Anonymous
    June 07, 2015
    The comment has been removed

  • Anonymous
    June 11, 2015
    The comment has been removed

  • Anonymous
    June 29, 2015
    Hi Team, I am trying to connect Azure Service Bus to my iPaaS Platform which is Dell Boomi. I am using a JMS Server Type as 'Generic JNDI'. I wanted to understand how to get the details which I need to connect: Details I need to find from the Azure side are - Connection Factory JNDI Lookup Initial Context Factory Provider URL JMS Properties: Name/Value if any My research is based on the below link which says JMS connector should work with similar config as Apache. Link Below: qpid.apache.org/.../QpidJNDI.html

  • Anonymous
    November 17, 2015
    Maybe we should be consistent then in applications like BizTalk where the builtin port type configuration for SB-Messaging REQUIRES ACS! This is still the case in the latest version.

  • Anonymous
    November 29, 2015
    Dhawal Thaker   (8 Jun 2015)  is telling us that the New-AzureSBNamespace cmdlet does not have a  -CreateACSNamespace any more. Does it mean that the work around to use ACS for the Service Bus is not an option today (30 Nov 2015) ? I know that SAS has the best practice for quite some time, but I would like to get an authoritative answer possibly from the Azure support team that it is now the only option. Thanks.

  • Anonymous
    February 15, 2016
    The comment has been removed