[QUERY] Microsoft.Azure.ServiceBus Usage of ITokenProvider with SubscriptionClient

Query/Question

I am using Microsoft.Azure.ServiceBus.SubscriptionClient to connect to Azure Service Bus using shared access signatures.

Since the shared access signature token is short lived I need a way to update my SubscriptionClient connection so that it remains authorized over a long period. I figured that might be doable using ITokenProvider since there is a constructor for SubscriptionClient which takes ITokenProvider instead of a connection string or connection object. https://docs.azure.cn/zh-cn/dotnet/api/microsoft.azure.servicebus.subscriptionclient.-ctor?view=azure-dotnet#Microsoft_Azure_ServiceBus_SubscriptionClient__ctor_System_String_System_String_System_String_Microsoft_Azure_ServiceBus_Primitives_ITokenProvider_Microsoft_Azure_ServiceBus_TransportType_Microsoft_Azure_ServiceBus_ReceiveMode_Microsoft_Azure_ServiceBus_RetryPolicy

By implementing ITokenProvider and passing it to SubscriptionClient, I observed that for regular MessageHandler the token provider updates the connection with a new SAS when the SecurityToken has expired. This is great. However, the behaviour for SessionHandler is not the same. I’ve followed a similar implementation to https://github.com/Azure/azure-service-bus/blob/master/samples/DotNet/Microsoft.Azure.ServiceBus/Sessions/Program.cs and when I use the ITokenProvider constructor noted in the paragraph above, the SAS tokens are not refreshed based on the SecurityToken expiry. Instead, it appears that the session connection closes often based on operationTimeout (which is defaulted to 1 minute but could be included in the connection string). The timers in ITokenProvider are not actually utilized.

I think maybe this has something to do with how ActiveClientLinkManager https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/servicebus/Microsoft.Azure.ServiceBus/src/Amqp/ActiveClientLinkManager.cs is used by the session implementation vs regular message handlers.

Can you please help to clarify the usage of the ITokenProvider for SubscriptionClient, or how the token refresh process may differ between MessageHandler and SessionHandler? Or otherwise suggest an approach to keep a long running SubscriptionClient connection open with short lived SAS tokens used for the connection?

[yvgopal]

Sorry to have kept this question open for so long. No. SessionHandler also works fine with ITokenProvider. If a session is accepted, the SDK will keep renewing the token underneath. To create a connection, one doesn’t need any token. It is only to create links that tokens are needed. Once a link is created, the sdk keeps renewing the token when it is about to expire. In case of a message handler, a link is created right away. In case of a session handler, a link is created only if a session is available. If a session is not available, link creation will timeout after oepration timeout. That timeout is caused by non-availability of sessions, not because token expired. OperationTimeout has nothing to do with token renewal.

If token is really expired, the error message will clearly say that. It will never throw timeout.

[iamandymcinnes]

Hi

I just wondered if there is any input on this? The migration guide and documentation don’t detail the AzureSasCredential approach which doesn’t help when migrating from using the ITokenProvider in the previous SDK.

Many thanks

Andy