[QUERY] How do we test for AMQP over TLS?

[arunprakashn]

Library name and version

Azure.Messaging.Servicebus 7.14.0

Query/Question

I have an application that uses Azure.Messaging.ServiceBus library to send/receive messages to/from service bus. This application is deployed to various clients.

I was using the previous Microsoft.Azure.ServiceBus nuget and this code is kind of used as a "connectivity check" to inform the users whether their network/firewall configurations are in place.

var serviceBusConnectionStringBuilder = new ServiceBusConnectionStringBuilder(endPoint, queueName, sasToken, Microsoft.Azure.ServiceBus.TransportType.Amqp); ManagementClient client = new ManagementClient(serviceBusConnectionStringBuilder); isExists = client.QueueExistsAsync(queueName).GetAwaiter().GetResult();
The mainstream code to send/receive was upgraded to use Azure.Messaging.ServiceBus and post-upgrade users complained that the connection is not happening. I realized that the AMQP over TLS was denied by the PaloAlto firewall.

Will the "healthcheck" code check for the AMQP over TLS or just the AMQP? If I upgrade the "healthcheck" code also to use the latest sdk, will that try to use AMQP over TLS and can I determine whether AMQPS is enabled in their firewall?

The health-check code just checks for the presence of a queue. Should I make it to "sending a dummy message" to acheive the AMQPS attempt?

Any thoughts?

Environment

No response

[jsquire]

Hi @arunprakashn. I'm sorry to say that the approach that you've been using will not validate that AMQP connectivity is possible; the ManagementClient in the legacy package works against an HTTP service - as does the ServiceBusAdministrationClient in the current package.

In order to validate AMQP connectivity, you'll need to trigger an AMQP-based operation. My suggestion would be to use the ServiceBusRuleManager, which you can create from the ServiceBusClient. This would allow you to query the rules for a subscription, which is non-destructive and won't interfere with operations running from other clients. The downside is that you'll need a topic and subscription to use it. Alternatively, you could, as you suggested, send a punctuation message to a "health check" queue with really short time-to-live.

[github-actions]

Hi @arunprakashn. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[arunprakashn]

Thanks @jsquire

I have some follow-up questions-

1. We are using transport type as amqp(see the code snippet that I have attached) while creating the connection builder. Isn't this misleading to the SDK users where we expect that the AMQP protocol will be used but the SDK ignores it and uses https?
2. Do you have a list of AMQPS operations other than ServiceBusRuleManager? The punctuation message can be used in some service buses but cannot do so in the client environment. Because sending a message to the customer SB queue will result in the consumption of that message by the consumers which is undesirable.

[jsquire]

We are using transport type as amqp(see the code snippet that I have attached) while creating the connection builder. Isn't this misleading to the SDK users where we expect that the AMQP protocol will be used but the SDK ignores it and uses https?

ServiceBusAdministrationClient is a stand-alone type that you create directly and does not accept any kind of transport argument. It is not spawned from ServiceBusClient and does not fall under the options that you pass to ServiceBusClient.

Do you have a list of AMQPS operations other than ServiceBusRuleManager? The punctuation message can be used in some service buses but cannot do so in the client environment. Because sending a message to the customer SB queue will result in the consumption of that message by the consumers which is undesirable.

Anything that is accessible from ServiceBusClient or one of the subclients spawned from it are AMQP-based. Only the operations from the admin client are not.

[arunprakashn]

@jsquire Thank you.

That means if I create a ServiceBusClient and try to send a message to a non-existent queue, it will be using AMQPS and I can catch the exception "MessagingEntityNotFound" and ensure that the AMQPS can happen. If due to network/firewall reasons, then I will be getting "MessagingCommunicationException"

Is my understanding correct?

I have another observation - In the below code, the error is "MessagingEntityNotFound" exception. Even if I use an incorrect key and keyname, it still correctly tells that the entity is not found. IMHO, if the credentials are incorrect, shouldn't the error be something "BadCredentials" instead of "EntityNotFound". This means, with a valid SB FQDN, I can make multiple calls to probe whether some entity exists or not without proper credentials. Right? I am getting "Unauthorized" only if I use correct queue name.

ServiceBusClient client = new ServiceBusClient("Endpoint=sb://sb-usw-test2.servicebus.windows.net/;SharedAccessKeyName=DummyKeyName;SharedAccessKey=DummyKey", clientOptions); var sender = client.CreateSender("queuedoesnotexist"); ServiceBusMessage serviceBusMessage = new ServiceBusMessage("Hey");

[jsquire]

That means if I create a ServiceBusClient and try to send a message to a non-existent queue, it will be using AMQPS and I can catch the exception "MessagingEntityNotFound" and ensure that the AMQPS can happen. If due to network/firewall reasons, then I will be getting "MessagingCommunicationException"

Conceptually, yes - but the details are incorrect. Those exceptions that you're linking are from one of the legacy generation packages, so that statement is not accurate. Please see this section of the Service Bus troubleshooting guide for error specifics.

I have another observation - In the below code, the error is "MessagingEntityNotFound" exception. Even if I use an incorrect key and keyname, it still correctly tells that the entity is not found. IMHO, if the credentials are incorrect, shouldn't the error be something "BadCredentials" instead of "EntityNotFound". This means, with a valid SB FQDN, I can make multiple calls to probe whether some entity exists or not without proper credentials. Right? I am getting "Unauthorized" only if I use correct queue name.

This is a service behavior and not something that the client can control or influence. When you request a service operation, the service will first attempt to locate the proper node for the entity that you'd like to work against. It does this before it authorizes you, so if you ask for a non-existent entity, then the "not found" will be triggered and authorization is not checked.