[Core] Add CAE flag to auth policies

[pvaneck]

The get_token protocol is updated to allow an optional enable_cae keyword argument. The overall signature doesn't change as we just document that enable_cae can be passed in as a part of kwargs.

With the flag, we can enable users and client SDKs to speciify that get_token requests should be requesting CAE-enabled tokens.

If the underlying credential's get_token implementation supports this flag, then a CAE-enabled token should be requested. Otherwise, a non-CAE token should be requested.

In this PR BearerTokenCredentialPolicy and AsyncBearerTokenCredentialPolicy are updated to also allow an enable_cae keyword argument in the constructors. This will be used in determining if enable_cae should be used in their respective get_token requests.

Since, ARM supports CAE and has logic for handling these CAE claims challenges, ARMChallengeAuthenticationPolicy and AsyncARMChallengeAuthenticationPolicy were updated to ensure that enable_cae is set to True. Edit: This will be split out into a separate PR

More info here: #30777

Notes

• From what I can tell, all current (non-test) get_token implementations across our SDKs take in **kwargs, so enable_cae being passed in shouldn't cause any breakage. If needed, we can always catch TypeErrors for unexpected keyword arguments.

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

azure-core

[david-becher]

When using az keyvault secret show we get an ERROR: Session.request() got an unexpected keyword argument 'enable_cae' error. Do not know, whether this is a problem of this library or of azure-cli, but only downgrading azure-core to 1.28.0 fixed the issue in the azure cli. @pvaneck @kashifkhan

[xiangyan99]

Thank you for reporting the issue.

Could you share the version of azure-cli you are using?

And if possible, the version of azure-keyvault package?

[david-becher]

@xiangyan99

The azure-cli was freshly installed via pipx in version 2.51.0. This installed dependency azure-core was in version 1.29.0 and azure-keyvault in version 1.1.0. As I said, manually downgrading azure-core to version 1.28.0 mitigated the problem.

[jiasli]

From what I can tell, all current (non-test) get_token implementations across our SDKs take in **kwargs, so enable_cae being passed in shouldn't cause any breakage.

This assumption is unfortunately not true for Azure CLI and caused breakage in Azure CLI as shown in the above comment #31012 (comment) and Azure/azure-cli#27131.

Azure CLI also implements get_token protocol and passes **kwargs to MSAL almost untouched:

https://github.com/Azure/azure-cli/blob/21266e02457263420b62fba1c529f69e28852414/src/azure-cli-core/azure/cli/core/auth/msal_authentication.py#L69

    def get_token(self, *scopes, claims=None, **kwargs):
        ...
        result = self.acquire_token_silent_with_error(list(scopes), self._account, claims_challenge=claims, **kwargs)

The only exception is tenant_id which is popped from **kwargs.

https://github.com/Azure/azure-cli/blob/0fb75afa1e75f8a2419514c5fcf19533138f7185/src/azure-cli-core/azure/cli/core/auth/credential_adaptor.py#L62

    def get_token(self, *scopes, **kwargs):
        ...
        # SDK azure-keyvault-keys 4.5.0b5 passes tenant_id as kwargs, but we don't support tenant_id for now,
        # so discard it.
        kwargs.pop('tenant_id', None)

The popping tenant_id logic was added by Azure/azure-cli#21244 because of the breakage caused by passing tenant_id to get_token. See Azure/azure-cli#20880 for details.