Microsoft.Identity.Web.Credentials provide support for certificates, symmetric keys and signed assertions

[jennyf19]

Why?

With certificateless coming only on Azure when MSI is available, we need a way to express a priority order to express confidential client application client credentials (and later the decrypt credentials). This can be achieved as ordered collection of CredentialDescription.

In current Id.Web and SAL configuration, we use the notion of ClientCertificate (and DecryptCertificate), and some other settings for certificateless.

What?

This can be split in several work items.,

• [x] Have CertificateDescription (Microsoft.Identity.Web.Certificate) inherit from CredentialDescription (Microsoft.Identity.Web.TokenAcquisition.Abstrations)
• [x] MicrosoftIdentityOptions should have a new property ClientCredentials.
• [x] MicrosoftIdentityOptions.ClientSecret should now be a calculated property looking for the first ClientCredentials of CredentialType.Secret, and returning its value. The setter would look if the ClientCredentials collection contains a secret, and if yes, it would replace it, otherwise it would appen a new CredentialDescription at the end of the ClientCredentials collection.
• [x] MicrosoftIdentityOptions.ClientCertificates should now be a calculated property looking for the ClientCredentials of CredentialType.Cerficicate, and returning them. The setter would insert the collection into ClientCredentials (and remove the previous values of CredentialType.Certificate).
• [x] MicrosoftIdentityOptions.ClientCredentialsUsingManagedIdentity would also be a computed property, getting the value from the collection ClientCredentials where CredentialSource == CredentialSource .SignedAssertionFromManagedIdentity. The setter would insert such a ClientCredentials before the certificates and the client secrets
• [x] In MergeOptions, add ClientCredentials, and Update the merge methods from MicrosoftIdentityOptions (new) and MicrosoftAuthenticationOptions (change the method to use the ClientCredentials directly)
• [ ] In TokenAcquisition use ClientCredentials - Try one credential. If ESTS refuses it, try the next one. This might require to have a property IsValid on CertificateCredential, and maybe WasEverValid, or an enum - When all are exhausted, try once to reload the certificates (client certificate rotation)
• [x] Do the same for TokenDecryptCertificates as for ClientCertificates (using TokenDecryptCredentials). There should not be any secrets there.
• [ ] Support symmetric keys (See CredentialsDescription in SAL)
• [ ] Support signed assertions from MSI Federation identity (certificateless)
• [ ] Remove from SAL the code that would no longer be needed.
• [ ] Support dSMS for Azure infrastructure RPs (1P only)

How it contributes to the DevEx of future features?

• Later when available support short lived credentials (SLC)
• Later when available support auto decrypt keys from ESTS directly.