SharedTokenCacheCredential/Azure.Identity: Support enforcing a tenant

I am currently evaluating the Azure.Identity library for a project developed for azure. Use-cases are accessing blob storage, sql, key vault etc. and it looks like Azure.Identity is the way forward.

When starting from the documented samples, we faced the issue that the SharedTokenCacheCredential does not support providing a desired tenant id. In situations where azure resources are managed/developed by external/guest/invited AAD users, the token cache contains tokens issued by the “home/native tenant” of the user. If the blob storage resource is attached to another AAD tenant this will cause 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. while accessing the blob store.

Furthermore the default factory created instance of InteractiveBrowserCredential cannot be configured to pass the tenant through to AAD which results in the default behavior of logging into the user’s home tenant.

A general/consistent way of providing the desired tenant (e.g. via DefaultAzureCredentialOptions) would allow users to stick close to the default and avoid having to setup own credential chains or redevelop a custom token cache lookup.

Are there any plans to support this scenario? Thank you in advance for looking into this.

[joshfree]

Closing this issue as we’re planning to release an update in December. Please feel free to reactivate if the 1.1.0 package doesn’t fix your issue.

[schaabs]

@sopelt I’ve split this issue into two issues, #8689 and #8691, so they can be tracked separately. Currently, both of these are tracking to be fixed as part of our December milestone.