Azure-sdk-for-net: [QUERY] Option for sending public certificate while generating the AD token for easy certificates roll-over ...

[subbartt]

Hi Team,
We are currently using nuget microsoft.azure.keyvault\2.3.2 to interact with keyvault. As microsoft recommends to move to azure.security.keyvault.secrets\4.0.3 we are using the keyvault.secrets/4.0.3 . However we are finding feature gap in the following scenario which is preventing us to move to the azure.security.keyvault.secrets\4.0.3.

1) Using microsoft.azure.keyvault\2.3.2 as part of initializing KeyVaultClient, clients can give tokencallback method to retrieve the token from the AD. As part of getting token using cert based authentication we are using "sendX5c" which helps for automatic cert roll overs. ( https://docs.microsoft.com/en-us/dotnet/api/microsoft.identitymodel.clients.activedirectory.authenticationcontext.acquiretokenasync?view=azure-dotnet). This option is also available for V2 end point with MSAL libraries.
This parameter enables application developers to achieve easy certificates roll-over in Azure AD:
setting this parameter to true will send the public certificate to Azure AD along with the token
request, so that Azure AD can use it to validate the subject name based on a trusted issuer
policy. This saves the application admin from the need to explicitly manage the certificate rollover
(either via portal or powershell/CLI operation)

2) Now using azure.security.keyvault.secrets\4.0.3 since token retrieval is taken care by SDK itself , we need the support to send the public key as part of getting the token as mentioned above. This is needed for automatic cert roll overs. Can you support the option for the clients to opt in for this as part of creating secret client?

Let me now if you need more details. I work in Microsoft only , let me know if there is any other channel for internal requests.

Regards,
Subba

[heaths]

Are you using the Azure.Identity package as well? There is a ClientCertificateCredential that allows you to pass a certificate for authentication. Does that solve your problem? Azure.Identity contains a lot of different credential types that should account for almost all scenarios from the older libraries (though, you do have to know your tenant ID up front).

/cc @schaabs

[subbartt]

Hi heaths,
1) Yes , we are using ClientCertificateCredential while initializing secretclient

case AuthenticationType.Certificate:
secretClient = new SecretClient(
new Uri(settings.KeyVaultUri),
new ClientCertificateCredential(
settings.AuthenticationSettings.TenantId,
settings.AuthenticationSettings.ClientId,
settings.AuthenticationSettings.Certificate));

2) In old style using our own callback for token retrieval,
case AzureKeyVaultAuthenticationType.Certificate:
result = await context.AcquireTokenAsync(
resource,
this.clientAssertionCertificate,
sendX5c: true);
Or with new MSAL AD library

app.AcquireTokenForClient(scopes).WithSendX5C(true)
.ExecuteAsync();
In both cases we can use send the public key of the certificate using sendx5c true.

How we can achieve the same ( sending sendx5c) using 1) above ClientCertificateCredential or other type of credential while initializing secret client.

[schaabs]

@subbartt thanks for the feedback. We do plan on supporting Subject Name / Issuer certificate authentication for service principals (which is what the WithSendX5C method is enabling in MSAL). We currently have an issue on our backlog to add support for this, https://github.com/Azure/azure-sdk-for-net/issues/11447. While this didn't make it into the previews we're currently flighting, we'll most likely work on it soon after, so something will probably be available in the early fall. I'm closing this issue as you can check progress with #11477, but if you have further questions please feel free to reopen this issue or file a new one.