Support App Service managed identity 2019-08-01

[chlowell]

This adds a new internal credential, AppServiceCredential, handling both versions of App Service managed identity (closes #11346). I did this as a new credential because I think it will be easier to manage the growing list of supported platforms if each has its own credential class. I also added a class for mixing proactive refreshing into credentials. This is only used by the new AppServiceCredential here; refactoring other credentials to use it, or the new ManagedIdentityClient, is work for future PRs.

[schaabs]

nit: This classname seems a bit misleading since it will not proactively refresh anything unless a request is made. Proactive makes it seem like it will refresh regardless of whether a token was requested.

[chlowell]

Suggestions welcome 😉

[xiangyan99]

In the case that multiple credential share AuthnClient, should _last_request_time information be saved in the AuthnClient?

[chlowell]

I would think not, because refreshing is scoped to credential instances. But it's a thought experiment today because credential instances don't share clients. Also re AuthnClient, it's now being used for managed identity only, and I want to replace it with the ManagedIdentityClient I'm adding here.

[xiangyan99]

We also have a _parse_app_service_expires_on in authn_client? Do you want to deprecate that?

[chlowell]

Yes, my plan is to delete AuthnClient once everything is using ManagedIdentityClient instead.

[xiangyan99]

"client_id" works in "2019-08-01" while "clientid" works in "2017-09-01"?

[xiangyan99]

And why here we overwrite identity_config but not updating it?

[chlowell]

Yep, this is correct, 2017's "clientid" is now "client_id". I overwrite identity_config here to prefer client_id when someone passes client_id and identity_config, which is at best redundant. I'll change it to update identity_config instead. If we make identity_config part of the public API, I think it should be mutually exclusive with client_id, but we can handle that once it's decided.

[xiangyan99]

Is it possible that IDENTITY_ENDPOINT, IDENTITY_HEADER, MSI_ENDPOINT, MSI_SECRET all exist?

And what's the behavior for this case?

[chlowell]

Yes, in fact that's to be expected because App Service instances which support the new version still support the old one for compatibility's sake. Behavior is what you see here: prefer the more recent version, fall back to the prior one if necessary. The fallback behavior is required because the new API isn't supported for all apps, for example Linux Functions apps on a consumption plan don't support it.

[xiangyan99]

If all of them exist, will we try "2017-09-01" APIs if "2019-08-01" does not work?

[chlowell]

Not sure I understand your question but if you're asking whether we will follow a failed request to version 2019-08-01 with a request to 2017-09-01, no, we won't.

[xiangyan99]

Yes. You understand my question correctly. My question was do we want to make it behave like chained credential. if "2019-08-01" cannot get a valid token, we will try "2017-09-01". Thanks for the answer.