SDK inconsistency across langs: support AZURE_CLIENT_SEND_CERTIFICATE_CHAIN from DAC #40013
Labels
Azure.Identity
customer-reported
Issues that are reported by GitHub users external to the Azure organization.
feature-request
This issue requires a new behavior in the product in order be resolved.
Milestone
Is your feature request related to a problem? Please describe.
In order to implement SNI cert-based auth one has to leverage ClientCertificateCredential instead of DefaultAzureCredential. This happens because the latter does not support the AZURE_CLIENT_SEND_CERTIFICATE_CHAIN env var so that appropriate x5c header is sent. If a codebase has to support both SNI and MSI auth it follows it must have different code paths for each. This makes the auth logic convoluted and can lead to code obscurity.
Describe the solution you'd like
Add support for AZURE_CLIENT_SEND_CERTIFICATE_CHAIN when using DefaultAzureCredential() so that it can pick up said env var and send the appropriate x5c header.
Additional context
Other azure SDKs already have support for that (golang and .NET). It makes sense to make this behaviour uniform acroos all SDKs.
The text was updated successfully, but these errors were encountered: