[Feature] SubjectName/Issuer (SNI) authentication. WithSendx5c()

[henrik-me]

Supported in:
Python
.NET

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.

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 still follow this 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).

• 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.

[EldarZ]

hi @henrik-me, @sangonzal, any idea if we have an ETA for this?

[beneshed]

I may try and take a stab at this

[henrik-me]

We don't have a fixed date for this yet, however will work with @thebenwaters on his PR. We already have a top level design for the work already, however a brief look at the PR provided indicates that you may be looking for something else/more. In our planning session today we will explore when we can pick up this work as well as how we can help you the best.
CC: @EldarZ

[Avery-Dunn]

Implemented by #285, and part of the 1.7.1 release