Implement ApiKeyCredential/AzureKeyCredential + corresponding auth policy in Core/Identity

[antkmsft]

AppConfig lists ApiKey as one of the authentication types for its clients.

Currently, we consider https://github.com/Azure/autorest.cpp/issues/398 as blocking the release of AppConfig?

Our CodeGen warns when it sees "apiKey" as one of the authentication types, and emits an assertion fail message saying that it does not know how to generate code for it. It does not fail the code generation, it only prints the warning message and does not generate a corresponding constructor overload.

We can implement it for CodeGen, but we need to implement the corresponding credential and pipeline policy in the SDK first.

cc @ahsonkhan

[LarryOsterman]

I'm not sure how adding ApiKey credential support to the C++ SDK aligns with the SFI initiative.

OTOH, ApiKeys aren't PII, but that's because they are effectively anonymous tokens - anyone who possesses the API Key can call into the service, but there's no user account to be compromised.

[antkmsft]

I am not familiar enough with the latest things in SFI/auth/identity, so don't take logging this bug as a request to implement it as if I knew all the nuances. It is more to get the answer, and if we find out that we don't want the ApiKey auth it is also fine - just WontFix this bug, and I will WontFix the corresponding bug in the CodeGen. So, it is first of all fo us to give an answer if we want this type of auth, and then if the answer is Yes, then second, implement it in SDK, so the third would be to implement it in CodeGen.

[LarryOsterman]

IMHO, this one lands squarely on Ahson's plate: He owns AppConfig and identity, and he's been pushing extremely hard to remove insecure credential types in the C++ repo.

I was mostly wondering out loud about whether or not ApiKey credentials are considered acceptable in an SFI world. I could see an argument either way.

[RickWinter]

Should we have this credential type? Is it secure?