Subject Name Issuer Authentication

Background of SNI: How does it work?

The following description is derived from Matt Bearup, a software developer from Microsoft.

1. User update AAD tenant to accept approved issuers.
   • 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.
   • 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. MSAL needs to help enable this.
   • 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.

PS: This is an internal wiki page that our service team always references to.

SNI Demo Video (Internal only)