Azure Service Bus Operations Raising TimeoutException instead of UnauthorizedAccessException using ACS
Asked Answered
S

2

13

I am using Access Control Service to authorize access to specific Service Bus Subscriptions for specific Service Identities.

When receiving sessions or messages from the subscription, the Service Identity is authorized and can receive and complete or abandon messages as required.

However, I am not seeing an UnauthorizedAccessException when attempting to access a subscription the Service Identity does not have access to, nor am I seeing this exception when attempting to perform an operation that the Rule Group does not issue a claim to for that Service Identity and Relying Party (such as Send a message or create a topic).

Instead, I eventually see a TimeoutException - "The timeout elapsed upon attempting to obtain a token while accessing 'https://namespace-sb.accesscontrol.windows.net/WRAPv0.9/'". The Inner Exception is a SecurityTokenException - "The token provider was unable to provide a security token while accessing 'https://namespace-sb.accesscontrol.windows.net/WRAPv0.9/'. Token provider returned message: 'The operation has timed out'". This causes a problem for the RetryPolicy, since a Timeout Exception is considered transient.

Strangely, though, I am receiving an UnauthorizedAccessException when attempting to receive the Subscription Description. Something which, according to Rights Required for Service Bus Operations, should be available to Service Identities with the Listen Claim within the ...myTopic/Subscriptions/mySubscription scope.

I have the following set up:

I am seeing the following issues:

var manager = NamespaceManager.CreateFromConnectionString("Endpoint=sb://namespace.servicebus.windows.net/;SharedSecretIssuer=testidentity;SharedSecretValue=SSdtIE5vdCBUZWxsaW5n=");
var description = manager.GetSubscription("myTopic","mySubscription");

Results in an UnauthoriszedAccessException - "The remote server returned an error: (401) Unauthorized." I would expect to be able to retrieve the description, rather than receive this exception. What is interesting is that this is the only realm the identity has access to, and is the only time I see an UnauthorizedAccessException.

var subscriptions = manager.GetSubscriptions("myTopic");

Results in a TimeoutException, with an inner exception of type SecurityTokenException. I would expect an UnauthorizedAccessException here.

var client = SubscriptionClient.CreateFromConnectionString("Endpoint=sb://namespace.servicebus.windows.net/;SharedSecretIssuer=testidentity;SharedSecretValue=SSdtIE5vdCBUZWxsaW5n=", "myTopic", "otherSubscription");
var message = client.Receive()

Results in message being null, but again I would expect an UnauthorizedAccessException. Examining the output, I see exceptions occurring in the output window but being swallowed by the client:

A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.Net.WebException' occurred in System.dll
A first chance exception of type 'Microsoft.ServiceBus.TokenProviderHelper.InternalSecurityTokenException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.TimeoutException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.TimeoutException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.TimeoutException' occurred in Microsoft.ServiceBus.dll
A first chance exception of type 'System.TimeoutException' occurred in Microsoft.ServiceBus.dll

Similarly, attempting to create topics, send messages, etc. also result in a TimeoutException.

Is this the correct behaviour when attempting to access realms that the service identity does not have any access to, rather than my expectation of receiving an UnauthorizedAccessException?

I guess the set up does have the desired result - identities cannot listen to subscriptions other than the one(s) identified by the subscription realm against which the identity has a Listen rule associated, but I am concerned that the error feedback is not clear, and will result in continuous retries.

Any advice would be most appreciated.

Stalker answered 9/9, 2014 at 12:2 Comment(0)
C
1

New SB namespaces created after 8/22 via the Azure portal do NOT generate the companion ACS namespaces any longer. So its entirely possible that the timeout you are receiving is the correct behavior.

To generate the ACS namespace, try creating the SB namespace by using the new-azuresbnamespace PowerShell cmdlet.

Chilt answered 18/9, 2014 at 15:24 Comment(1)
Whilst this is useful information, the companion ACS namespace(s) do exist. Otherwise I wouldn't have been able to set up the service identities, relying parties or rule groups. I have confirmed using the web UI and set up access using the API programmatically. Had they not existed, I wouldn't have been able to do this. Thanks all the same, though.Stalker
G
0

Some of these tokens have a limited lifetime / expire. So if you are using a token to that has passed it's expiration that could result in an authorization error like you are experiencing.

Glennisglennon answered 1/7, 2015 at 20:34 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.