[FEATURE REQ] Control the set of TokenCredentials used when using fullyQualifiedNamespace

[slaneyrw]

Library name

Microsoft.Extensions.Azure, Microsoft.Azure.WebJobs.Extensions.ServiceBus

Please describe the feature.

Hi Team.

When using the ServiceBus Trigger in combination with the fullyQualifiedNamespace setting, the way the DI system is configured gives us no way to control how the TokenCredential is evaluated.

This is painfully obvious when our developers are running the function app locally. It can a while before a valid credential is returned from the (hardcoded) credential chain, given some of the credentialToken sources also retry a number of times. This needs to complete before the function app is able to respond to any triggers.

With the use-case of configuring ServiceBus queues/topics with the appropriate roles for the developer's identity, we need to authenticate as the service bus transport is opened. The usual situation is that the VisualStudio or AzureCLI credential token finally gives back a token. The simple answer is to switch back to using a connection string with a SharedAccessKey but we want to remove ALL secrets from configuration, even local dev configuration.

I've looked through all of the options that the library gives me, but I keep coming back to the fact that the ServiceBusClient all appears to be created via the AzureComponentFactoryImpl object.. This ( and it's dependencies ) are internal and there are no obvious injection points.

AzureClientsGlobalOptions, which has an CredentialFactory cannot be modified, and the DefaultAzureCredential used is hardcoded.

Can you either resolve DefaultAzureCredential, or use an IOptions\<DefaultAzureCredentialOptions> somewhere. Then we can configure the choices that are used and optimise the dev inner-loop.

At the moment, we are seriously considering dropping the Function App host in favour of a normal WebHost, where we can control the runtime. HTTP Bindings are simply replaced with MVC Routes and ServiceBus Triggers replaced with MassTransit consumers. We also get the benefit of having an OpenAPI spec without resorting to 3rd party libraries.

On a related topic, you appear to be using a side-by-side dependency model to create your ServiceBus client than the one used by the Azure.Messaging.ServiceBus and it's extension methods. This means we have to configure ServiceBus twice when we also publish from a function app. I know this is probably historical, but consolidation of your DI would be nice.

[JoshLove-msft]

As mentioned in https://github.com/Azure/azure-sdk-for-net/issues/34845#issuecomment-1504576060, the token credentials can be configured using the UseCredential method. You can get access to the AddAzureClients method (which provides you access to the UseCredential method) using dependency injection, see more here. This will be used as long as there is no other credential config specified in your settings.

[github-actions[bot]]

Hi @slaneyrw. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[slaneyrw]

As mentioned in #34845 (comment), the token credentials can be configured using the UseCredential method. This will be used as long as there is no other credential config specified in your settings.

@JoshLove-msft We can't use that extension method for servicebus triggers, it completely controls the DI

[JoshLove-msft]

As mentioned in #34845 (comment), the token credentials can be configured using the UseCredential method. This will be used as long as there is no other credential config specified in your settings.

@JoshLove-msft We can't use that extension method for servicebus triggers, it completely controls the DI

I've edited my initial comment to include more details about how to use DI with Azure Functions.

[github-actions[bot]]

Hi @slaneyrw. 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.