SubjectName/Issuer (SNI) authentication

[rayluo]

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.

How does it need to be implemented in MSAL?

• What the “x5c” JWT header value would be? It appears only public certificate is sufficient. MSAL do NOT need to, and MUST NOT send private cerficate.
  Sagar: Correct, the x5c is the public cert.

• With “x5c” available, why “x5t” is still required, since it can be generated from “x5c” through sha1 hash easily?
  Sagar: This is due to the way JWT header is validated in eSTS for an incoming client assertion. eSTS parses the JWT header and extracts the x5t, does not generate it.

• The "x5c" parameter means "X.509 Certificate Chain", which is represented as a JSON array of certificate value strings. See this example too. Historically AAD would also accept a single cert as a string. MSAL Python would NOT rely on such behavior, and would follow the specs and send it as an array. During the implementation, please test it on the wire, and then also come up with a test case to ensure such behavior.
  As a reference, this was the same feature we added in ADAL Python, but it was sending public cert as a string (rather than an array).
  UPDATE: ADAL Python 1.2.2+ will also send public cert as a list of string now.

• We would also like to include the usability enhancement mentioned in this ADAL Python issue, and then also back port such enhancement to ADAL Python.

[jiasli]

Hi @rayluo, are there some more comprehensive public documents about how SubjectName/Issuer (SNI) authentication works with

• Some concrete examples about how to generate the certificate
• How to enable SubjectName/Issuer (SNI) authentication in Azure Portal (if possible now)
• What the payload in REST request for token retrieval looks like. x5c is not mentioned in Microsoft identity platform application authentication certificate credentials

The description provided in this issue still seems to be very vague to developers and users, and the internal Wiki page is not visible to external users.

Thanks for the information in advance.

[rayluo]

@jiasli

are there some more comprehensive public documents about how SubjectName/Issuer (SNI) authentication

We started with that same internal wiki page that you've found. In case you haven't noticed, its first paragraph also links to this yet another internal wiki page on "Subject Name and Issuer Authentication - Advanced Administrator Guidance".
I am not aware of a public doc.
My teammate @abhidnya13 who once setup her test tenant with this feature, kindly offers to ping you in email (Thanks Abhi!).

• What the payload in REST request for token retrieval looks like. x5c is not mentioned in Microsoft identity platform application authentication certificate credentials

As long as your app utilizes MSAL, you shouldn't need to care about all those on-the-wire details. For example, this is the MSAL Python API surface for SNI feature, which is part of the public MSAL Python API reference. Please ping us if you have further question!

[jiasli]

Thanks @rayluo for the great explanation.

I am not aware of a public doc.

Azure CLI has received customers' complaint that the document for --use-cert-sn-issuer in az login is too simple, which leads to the ask for public documentation.

As long as your app utilizes MSAL, you shouldn't need to care about all those on-the-wire details.

It will nice if we can have public doc about the on-the-wire details so that customer can also use tools like Postman, Fiddler to troubleshoot and develop their own client-side tool which utilize SubjectName/Issuer (SNI) authentication.

[asjddd]

The internal wiki link has fallen over and can't get up :)

Any chance of a new link?

[rayluo]

The internal wiki link has fallen over and can't get up :)

Any chance of a new link?

That link still brings me to a wiki page, even though it might not be the same page as before, but you can always use its Search feature with the "sni" keyword.