Storage clients should use tenant ID from authentication challenge

[williamw-m]

Bug Report

We used Python SDK for multi tenant authentication. Our tenant is A and we want to access the blob storage in tenant B. We have set up the cross tenant authentication. In our python SDK. Our code is as follows. We can successfully access the blob storage.

credential = ClientSecretCredential(tenant_id=A_tenant_id,
                                    client_id=A_client_id,
                                    client_secret=A_client_secret,
                                    additionally_allowed_tenants=["*"])

blob_service_client = BlobServiceClient(account_url=blob_service_url,
                                          credential=credential)
container_client = blob_service_client.get_container_client(
      container=container_name)
blob_list = container_client.list_blobs()

But when we use Go SDK we had the authentication issue.

cred, err := azidentity.NewClientSecretCredential(A_tenantID, A_clientID, A_clientSecret,
    &azidentity.ClientSecretCredentialOptions{AdditionallyAllowedTenants: additionalTenants})
serviceClient, err := azblob.NewClient(serviceURL, cred, nil)
pager := serviceClient.NewListBlobsFlatPager(containerName, nil)

We had this authentication error.

<?xml version="1.0" encoding="utf-8"?><Error><Code>InvalidAuthenticationInfo</Code><Message>Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
</Message><AuthenticationErrorDetail>Issuer validation failed. Issuer did not match.</AuthenticationErrorDetail></Error>

But if we changed the tenant ID in the NewClientSecretCredential. Then we can access the blob storage in B.

cred, err := azidentity.NewClientSecretCredential(B_tenantID, A_clientID, A_clientSecret,
    &azidentity.ClientSecretCredentialOptions{AdditionallyAllowedTenants: additionalTenants})

I think there is some bug in the Go SDK. Could you check and fix the issues?

[github-actions]

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

[chlowell]

This happens because the client doesn't specify the tenant when authenticating after receiving a challenge:

azure-sdk-for-go/sdk/storage/azblob/internal/shared/challenge_policy.go

Lines 45 to 46 in 4e3e7d4

	// TODO: Set tenantID when policy.TokenRequestOptions supports it. https://github.com/Azure/azure-sdk-for-go/issues/19841
	return authNZ(policy.TokenRequestOptions{Scopes: s.scopes})

We'll have to ship a new version to make azblob behave like the Python SDK in this scenario. As you've discovered, you can work around this in the meantime by passing the correct tenant to the credential constructor.

[MKrkkl]

I can confirm that passing additional tenant id helps accessing key vault as well.

Another option seems to be downgrading this package

replace github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/internal => github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/internal v1.0.1

but just using

azidentity.NewAzureCLICredential( &azidentity.AzureCLICredentialOptions{ AdditionallyAllowedTenants: []string{"tenant-id1", "tenant-id2","or-go-with-*"}, }, )

is enough in my case.

[chlowell]

Just to clarify, the latest Key Vault modules use tenant IDs from authentication challenges. They do this automatically, however you usually need to set corresponding AdditionallyAllowedTenants on credential options as well.

This issue tracks adding the same behavior to Storage modules.

[MKrkkl]

Hmm, Previously I didn't have additional allowed tenants set at all but once I updated package to the latest one I had to add it. While behaviour was the same that described here I thought it is related.

…

On Fri, 8 Nov 2024, 16:02 Charles Lowell, ***@***.***> wrote: Just to clarify, the latest Key Vault modules use tenant IDs from authentication challenges. They do this automatically, however you usually need to set corresponding AdditionallyAllowedTenants on credential options as well. This issue tracks adding the same behavior to Storage modules. — Reply to this email directly, view it on GitHub <#23678 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APDJYBKBRZA3ZARD76HCNLLZ7S76NAVCNFSM6AAAAABQ6UCBHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRUHA2DCNRQHA> . You are receiving this because you commented.Message ID: ***@***.***>

[tanyasethi-msft]

Hi @MKrkkl , thanks for reporting this. We are reviewing this issue, and will have a fix in our next GA release scheduled in January 2025.