[FEATURE REQ] Make ClientCertificateCredential disposable and dispose of the underlying X509Certificate2

Library or service name. Azure.Identity

Is your feature request related to a problem? Please describe. ClientCertificateCredential accepts a X509Certificate2 in its constructor and keeps it as an internal property: https://github.com/Azure/azure-sdk-for-net/blob/727ab08412e60394b6fea8b13cac47d83aca1f3b/sdk/identity/Azure.Identity/src/ClientCertificateCredential.cs#L33

However X509Certificate2 implements IDisposable and ClientCertificateCredential doesn’t, which burdens the developer with having to dispose of one object only when they’re done using another.

Making ClientCertificateCredential disposable, allowing the developer to dispose of the underlying X509Certificate2 would prevent the need to construct custom holder objects.

[schaabs]

@ohadschn Thanks for the feedback, and for creating this issue. We’ll investigate the impact making ClientCertificateCredential disposable, and update the issue once we have an idea of how and when we’ll address this.

[ohadschn]

Actually my initial feature request was for the case where the certificate was supplied directly in the ctor. We have code that looks like this, and I imagine many others do:

ClientCertificateCredential GetCredential()
{
   var cert = new X509Certificate2("MyCertPath");
   return new ClientCertificateCredential("myTenantId", "myClientId", cert);

   //or equivalently:
   return new ClientCertificateCredential("myTenantId", "myClientId", "MyCertPath");
}

The point is, I assume in the vast of the cases, the caller just wants the creds and they don’t care about the X509Certificate2 - only reason the latter exists is because ClientCertificateCredential needs it.

In such a case, as in the method above, we don’t want to manage two separate classes and make sure that whenever I dispose of one I remember to dispose of the other. To that end, we created a disposable wrapper class on top of ClientCertificateCredential, so it’s not the end of the world, just would have been nice to get it in the SDK.

As for allowing the case of the caller managing the X509Certificate2 lifetime, you could have a ctor flag that designates ownership (similar to disposeHandler in the HttpClient ctor), which can default to the current behavior (i.e. false). I concede that might add some complication, so in the end it’s up to you to consider the tradeoff.