Hi,
we are following the least privilege principle when using NServiceBus in combination with the Azure Service Bus transport. Endpoints, queues, topics, and subscriptions are created upfront in a separate pipeline using NServiceBus’ operational scripting mechanisms and the actual applications run with ‘send’ and ‘listen’ rights only.
However, after upgrading to NServiceBus 8.0.0, including NServiceBus.Transport.AzureServiceBus 3.0.0, our test application fails during endpoint creation:
Unhandled exception. System.UnauthorizedAccessException: Service request failed.
Status: 401 (SubCode=40100: Unauthorized : Unauthorized access for 'CreateOrUpdateSubscription' operation on endpoint 'sb://<service-bus-instance>'.
Headers:
<...>
---> Azure.RequestFailedException: Service request failed.
Status: 401 (SubCode=40100: Unauthorized : Unauthorized access for 'CreateOrUpdateSubscription' operation on endpoint 'sb://<service-bus-instance>'.
Headers:
<...>
--- End of inner exception stack trace ---
at Azure.Messaging.ServiceBus.Administration.HttpRequestAndResponse.ThrowIfRequestFailedAsync(Request request, Response response)
at Azure.Messaging.ServiceBus.Administration.HttpRequestAndResponse.SendHttpRequestAsync(Request request, CancellationToken cancellationToken)
at Azure.Messaging.ServiceBus.Administration.HttpRequestAndResponse.PutEntityAsync(String entityPath, String requestBody, Boolean isUpdate, String forwardTo, String fwdDeadLetterTo, CancellationToken cancellationToken)
at Azure.Messaging.ServiceBus.Administration.ServiceBusAdministrationClient.CreateSubscriptionAsync(CreateSubscriptionOptions options, CreateRuleOptions rule, CancellationToken cancellationToken)
at NServiceBus.Transport.AzureServiceBus.SubscriptionManager.CreateSubscription(CancellationToken cancellationToken) in /_/src/Transport/Administration/SubscriptionManager.cs:line 106
at NServiceBus.Transport.AzureServiceBus.MessagePump.Initialize(PushRuntimeSettings limitations, OnMessage onMessage, OnError onError, CancellationToken cancellationToken) in /_/src/Transport/Receiving/MessagePump.cs:line 71
at NServiceBus.ReceiveComponent.Initialize(IServiceProvider builder, RecoverabilityComponent recoverabilityComponent, MessageOperations messageOperations, PipelineComponent pipelineComponent, IPipelineCache pipelineCache, TransportInfrastructure transportInfrastructure, ConsecutiveFailuresConfiguration consecutiveFailuresConfiguration, CancellationToke
n cancellationToken) in /_/src/NServiceBus.Core/Receiving/ReceiveComponent.cs:line 167
at NServiceBus.StartableEndpoint.Start(CancellationToken cancellationToken) in /_/src/NServiceBus.Core/StartableEndpoint.cs:line 46
at NServiceBus.HostingComponent.Start(IStartableEndpoint startableEndpoint, CancellationToken cancellationToken) in /_/src/NServiceBus.Core/Hosting/HostingComponent.cs:line 87
at NServiceBus.Endpoint.Start(EndpointConfiguration configuration, CancellationToken cancellationToken) in /_/src/NServiceBus.Core/Endpoint.cs:line 34
...
We are wondering, whether this change was by design or is there a bug involved? We do explicitly disable the AutoSubscribe feature, so why is the CreateOrUpdateSubscription call even executed?
To reproduce, I created a simple demo which runs without any issue on NServiceBus 7.8.0 with version 2.0.3 of the AzureServiceBus transport. The only necessary change is to switch to the new way of registering the transport.
var endpointConfiguration = new EndpointConfiguration("demo");
var transport = new AzureServiceBusTransport("Endpoint=sb://<service-bus-instance>/;SharedAccessKeyName=<KeyWithSendAndListenOnly;SharedAccessKey=<Key>");
endpointConfiguration.UseTransport(transport);
endpointConfiguration.DisableFeature<AutoSubscribe>();
endpointConfiguration.DisableFeature<Sagas>();
var endpointInstance = await Endpoint.Start(endpointConfiguration)
.ConfigureAwait(false);
The endpoint demo, its input queue and associated subscriptions do exist.
