[BUG] No way to set IsChainedCredential when constructing ChainedTokenCredential with token sources

[dggsax]

Library name and version

Azure.Identity 1.10.4

Describe the bug

When using credential sources like AzurePowerShellCredential with a ChainedTokenCredential we are unable to leverage the exception handling logic of the Chained credential that allows it to work through the available credential sources, such as inside the AzurePowerShellCredential which throws a CredentialUnavailableException instead of whatever exception was thrown.

azure-sdk-for-net/sdk/identity/Azure.Identity/src/Credentials/AzurePowerShellCredential.cs

Lines 131 to 139 in b8a7f8a

	catch (Exception e)
	{
	throw scope.FailWrapAndThrow(e, isCredentialUnavailable: _isChainedCredential);
	}
	}
	catch (Exception e)
	{
	throw scope.FailWrapAndThrow(e, isCredentialUnavailable: _isChainedCredential);
	}

This is because the IsChainedCredential property on TokenCredentialOptions (which classes like AzurePowerShellCredentialOptions extend from) is internal (this property gets translated into the _isChainedCredential field on the credential sources which feed into the chained throwing logic)

azure-sdk-for-net/sdk/identity/Azure.Identity/src/Credentials/TokenCredentialOptions.cs

Lines 43 to 46 in b8a7f8a

	/// <summary>
	/// Gets or sets whether this credential is part of a chained credential.
	/// </summary>
	internal bool IsChainedCredential { get; set; }

Expected behavior

As a consumer of the ChainedTokenCredential we should be able to set that our credential sources are for chaining so that if one fails the others can be tried

Actual behavior

We are unable to set this variable by hand (what I am doing instead in the meantime is to use System.Reflection to set the _isChainedCredential field on my Token Sources, if they have the field, before I provide them to my ChainedTokenCredential instance)

Reproduction Steps

n/a

Environment

Runtime Environment:
OS Name: Mac OS X
OS Version: 14.7
OS Platform: Darwin
RID: osx-arm64
Base Path: /usr/local/share/dotnet/sdk/8.0.300/

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[dggsax]

I'm now trying to run with the latest version of Azure.Identity at 1.13.1 and it looks like even with _isChainedCredential set to true on my AzurePowerShellCredential instance using System.Reflection the timeout is still getting thrown as a AuthenticationFailedException and not a CredentialUnavailableException as expected.

azure-sdk-for-net/sdk/identity/Azure.Identity/src/CredentialDiagnosticScope.cs

Lines 61 to 64 in 5ee0dee

	if (exception is OperationCanceledException || exception is AuthenticationFailedException)
	{
	return false;
	}

Is it expected that if the exception received by TryWrapException is already an AuthenticationFailedException that it shouldn't try to wrap it even with isCredentialUnavailable parameter set to true?

[christothes]

Is it expected that if the exception received by TryWrapException is already an AuthenticationFailedException that it shouldn't try to wrap it even with isCredentialUnavailable parameter set to true?

I'm surprised if you are seeing different behavior across versions in that this specific code path hasn't changed.

Looking at the code though, I'd agree that this should be treated as a bug.

I think the reason for the logic initially was to treat these exceptions differently because they may indicate that the credential was intended to succeed but failed due to timeout of permissions issues. So, the question is whether the chain should proceed no matter what until we successfully fetch a token or exhaust the chain. Looking back at the original intent of the feature, I believe this "proceed no matter what" should have been the behavior.

[dggsax]

I'm surprised if you are seeing different behavior across versions in that this specific code path hasn't changed.

Ah! Sorry, should clarify, manually setting _isChainedCredential with reflection was also not working with 1.10.4 which is the version I was originally using. I updated to double check that that wasn't the reason.

For our purposes, increasinging the timeout and telling our customers to prefer Azure PowerShell will work for us in the meantime.