tenant-hint.md

Azure.Identity Support Tenant Id Challenges

Summary

Currently, for services that return challenges which include context about the tenant that can service a failed service request, such as authorization_url, Azure.Identity does not utilize this information to request a new token with the correct tenantId.

This is a proposal to enhance Azure.Identity to make it possible for service clients to interpret challenges to request tokens for the correct tenant Id, where possible.

Value

The value of implementing this feature is:

• The ability to authenticate to Key Vaults across multiple tenants is a feature that has been requested by some customers. This would enable that scenario.
• Address the common issues encountered by our customers when using VSCode and Vs credentials with an MSA account signed in, or with multiple credentials signed in

Issues

To implement the capability to handle challenges that provide tenant Id hints, the following issues need to be addressed.

1. The TokenCredential abstraction needs the required tenant Id context
2. Services that include the tenant Id hint context in their challenge response do not parse the tenantId
3. Decisions need to be made about how the challenge context would be used for credentials that specify a TenantId in their options or as a required property at construction time

Design Ideas

Issue 1

A TenantId property could be added to the TokenRequestContext class.

Issue 2

Services that support tenantID challenges will implement a BearerTokenChallengeAuthenticationPolicy that understands how to parse the tenant Id from the challenge header.

Issue 3

This should be discussed as a feature crew. Some initial thoughts:

• For credentials that specify a tenantId at construction time or in options, an additional property could be added to its credential options to indicate if tenantId hints should be honored or ignored

Estimates

Rough estimate for this work is ~5 days per language.

• Not all credential will/can honor tenant Id.
• We should make every effort to only request a token for the tenant Id in the TRC.
• Managed Identity is the example here of where we cannot predict the tenant Id that will be used.
• try to parse token to get the tenant Id - if not matched, throw some error
• if we cannot parse it, cross fingers (log warning)
  • issuer will contain the tenant ID
• With federated client ID, we should be able to pass that along to the token request.

thanks for pointing me to this Chris, we're excited to see it get addressed :)
The summary page calls out KV explicitly, are there other services that need to get work done on their side (SQL, Storage, PG, Service Bus, etc) ? Or will it all be handled by the changes to Azure.Identity that you're talking about here.

Each service client needs some minimal work to adapt to the changes once they are merged with Core and Identity.

Sorry, I meant on the actual server side, like how KV returns the WWW-Authenticate header with the tenant to give hints that help the library in this scenario - if the other services should do that too (if they don’t all already). Thanks!

Sorry, I meant on the actual server side, like how KV returns the WWW-Authenticate header with the tenant to give hints that help the library in this scenario - if the other services should do that too (if they don’t all already). Thanks!

Yes, they would need to send the tenant ID in the challenge header.

Thanks. Can I help by filing tickets for the various services in order to give them enough time to implement this change to match the release of the library, or something?