Open fredysierra opened 11 months ago
@yiliuTo could you please assist?
Hi @fredysierra , thanks for reaching out. We have received your submission and will take it into consideration. We appreciate your input and will review this matter as soon as possible. Please feel free to provide any additional information or context that you think may be helpful. We'll keep you updated on the progress of our review. Thank you for your contribution to improving our project.
Hi @fredysierra , I have reproduced your scenario. Only ServiceBusChannelResourceManagerProvisioner
will create entities, ServiceBusChannelProvisioner
will not, which will only work without creating entities. The root cause is that the we use Azure ARM client to get the connection string, and it still can respond to the connection string even if the Service Bus has disabled the local authentication, the priority of connection-string will be higher than the service principal, the subsequent ServiceBusProcessorClientBuilder will use this invalid connecting-string, and then encounter this error.
A quick fix is to override this bean and return null when it gets the connection-string using the ARM client, add the below bean definition in your configuration:
@Bean
ServiceBusArmConnectionStringProvider serviceBusArmConnectionStringProvider(AzureResourceManager azureResourceManager, ServiceBusResourceMetadata resourceMetadata) {
return new MyServiceBusArmConnectionStringProvider(azureResourceManager, resourceMetadata, resourceMetadata.getName());
}
class MyServiceBusArmConnectionStringProvider extends ServiceBusArmConnectionStringProvider {
public MyServiceBusArmConnectionStringProvider(AzureResourceManager azureResourceManager, AzureResourceMetadata azureResourceMetadata, String namespace) {
super(azureResourceManager, azureResourceMetadata, namespace);
}
@Override
public String getConnectionString() {
return null;
}
}
Thank you for your quick fix @moarychan. I can see it is working for me now. Are there any plans to include this as part of a patch or new version?
@fredysierra this approach is just a workaround, and we won't include this into the code. In my understanding, the possible solution for this is to redesign the authentication for sdk client in Spring, for users to be able to specify which kind of auth they want to use for the sdk. Now we are using an opinionated way to configure the auth order, which is connection string, and token credential. But this change will take some time to discuss and design, so there's no target date for a release.
Query/Question We have a simple spring app that uses Azure Service Bus with Spring Cloud Stream and
spring-cloud-azure-stream-binder-servicebus
using credentials as service principal as described here. Our main goal is to disable SAS key authentication for a Service Bus namespace and allow only Azure Active Directory authentication.I added the following configuration:
With this configuration, it is possible to see that the topic
topic0
and subscriptionsub0
have been automatically created when the application starts.I can see the topic
topic0
subscriptionsub0
created in portal.azure.com. However, I can also see that the app has issues when wants to use the topic and subscription.Why is it allowing us to create the topic and at the same time complain about using it with an
Authorization failed because SAS authentication has been disabled for the namespace
?I continued exploring alternatives and I ended up trying the same configuration above but using
spring.cloud.azure.servicebus
instead ofspring.cloud.azure
.With that configuration works fine accessing the topics and allowing us to send a receive messages. ONLY if the topic
topic0
and subscriptionsub0
are created manually using the portal.azure.com. With this configuration, the automatic creation of topics and subscriptions is not happening.In
spring-cloud-azure-stream-binder-servicebus
, I can see in ServiceBusBinderConfiguration twoProvisioningProvider
:ServiceBusChannelResourceManagerProvisioner
andServiceBusChannelProvisioner
. The logic for creating topics and subscriptions seems to be only present inServiceBusChannelResourceManagerProvisioner
. When our configuration uses the prefixspring.cloud.azure.servicebus
the beanServiceBusChannelProvisioner
is used and it does not have any topic creation logic.Setup:
Can someone help me with the correct configuration for spring apps with credentials as service principal and auto-creation of topics at application startup?
Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report