@rayluo, test coverage is added. Feel free to merge when this gets approved
//CC @mbearup

Also documenting the backgroud of this SubjectName/Issuer Authentication feature. The workflow would look like:

1. Update AAD tenant to accept approved issuers – this is outside the scope of this PR.

   • The AAD Tenant only accepts certain issuers (AME) which have strict association of subject name and requestor

2. User associates an issuer/subject name with their service principal – also outside the scope of this PR.

   • Once I as the requestor register contoso.com with AME CA, no one else can get it.
   • This is the foundation of SN/Issuer trust. Rather than trusting the thumbprint, you’re trusting that the CA vouches for me as the only one who can generate certs for that subject name.

3. User configures app to use SNIssuer auth instead of thumbprint-based.

   • We don’t need to deprecate thumbprint auth or switch back and forth. The client would simply use a different login option going forward, e.g. az login --newoption /path/tocert
   • As the requester/user it’s still my responsibility to get the latest pfx from keyvault/dsms/etc. An expired cert would still be rejected by AAD.
   • What this saves us is the trouble of registering a new thumbprint with AAD, which would create a more complex autorotation scenario (use old cert to register new cert, then use new cert to deregister old cert).
   • Without SN/Issuer auth there is also a gap in authentication when key material is rotated. When KeyVault issues a new cert, its thumbprint is not in AAD. My app would have to recognize this, rotate thumbprints in AAD, and try again.
   • Note that the key material does get rotated, but that’s not what is being trusted. Instead we’re trusting that an approved CA issued a cert with an approved subject name and that we have the matching private key for that cert.
   • With SN/Issuer auth the only thing I have to worry about is getting the latest pfx for my app.

Looks Good.