Support Tenant Id Challenges / Hints

[christothes]

The focus of these changes are to add the tenant discovery capability to Azure.Identity.
It also implements a new auth policy in all Azure.Storage clients that implement this capability.

#19404

[schaabs]

passing null as opposed to a TokenCredentialOptions uses the singleton instance of CredentialPipeline this would change that behavior.

[christothes]

I may be missing something, but I believe this should have the same behavior as what is there currently:

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

Lines 88 to 89 in 658dbd4

	options ??= new TokenCredentialOptions();
	_pipeline = CredentialPipeline.GetInstance(options);

[ericsampson]

@christothes, I don't want to be a pain in the ass, and so I really didn't want to even mention this, but when you get a minute would you be able to comment on my questions here

For an example of the impact that I'm concerned about, the SqlClient library recently added support for enabling the use of DefaultAzureCredentials via the SQL connection string, but there's no way to customize the chosen providers or set these new EnableTenantDiscovery/AllowMultiTenantAuthentication options. Other than env vars, which is really not great at an enterprise scale.
The SqlClient library was planning on upgrading to this Az.Identity release in order to have the Multi-tenant issue resolved transparently for customers, but now it seems like that's not going to be the case given the default behavior.

Thanks for taking the time to help me understand the reason for the default choices :)
Cheers

[christothes]

@christothes, I don't want to be a pain in the ass, and so I really didn't want to even mention this, but when you get a minute would you be able to comment on my questions here

For an example of the impact that I'm concerned about, the SqlClient library recently added support for enabling the use of DefaultAzureCredentials via the SQL connection string, but there's no way to customize the chosen providers or set these new EnableTenantDiscovery/AllowMultiTenantAuthentication options. Other than env vars, which is really not great at an enterprise scale.
The SqlClient library was planning on upgrading to this Az.Identity release in order to have the Multi-tenant issue resolved transparently for customers, but now it seems like that's not going to be the case given the default behavior.

Thanks for taking the time to help me understand the reason for the default choices :)
Cheers

Hi @ericsampson - The default behavior is to avoid breaking changes or authorization requests for unexpected tenants. For example, sending an unauthenticated initial request where that didn't happen previously, or sending token requests to a tenant that you do not wish to share PII details with.

Setting environment or AppConfig setting can be configured in a variety of ways depending on how your service is deployed to Azure, but that seems outside the scope of this PR :).