[Key Vault] Support CAE in challenge auth policy

[mccoyp]

Description

Resolves https://github.com/Azure/azure-sdk-for-python-pr/issues/919. Based on Azure/azure-sdk-for-java#41814. The HttpChallenge model now has a claims attribute, which contains the decoded claims from an authentication challenge if one is present. Parsing logic is largely pulled from the _parse_claims_challenge utility in azure-mgmt-core.

In order to support the unique challenge flow that KV+CAE enables -- where we handle two consecutive challenges -- we need to implement the send method on the KV challenge auth policy. Doing so on the async side requires some awaiting logic that's been lifted from azure-core utilities.

All SDK Contribution checklist:

• The pull request does not introduce [breaking changes]
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

[azure-sdk]

API change check

API changes are not detected in this pull request.

[xiangyan99]

Can we reuse the code we added into core? #37652

[mccoyp]

Can we reuse the code we added into core? #37652

@xiangyan99 unfortunately I don't know if we could effectively borrow the Core implementation. Our on_challenge method needs to be aware of both KV and CAE challenges, and while handling the latter we have to use content from past challenges to obtain the tenant ID and scopes. The main thing we could possibly borrow would be _get_token, so we could get the automatic enable_cae=True passing, but that's a minor benefit and private attribute so I don't know if we'd want to.

[xiangyan99]

Can we reuse the code we added into core? #37652

@xiangyan99 unfortunately I don't know if we could effectively borrow the Core implementation. Our on_challenge method needs to be aware of both KV and CAE challenges, and while handling the latter we have to use content from past challenges to obtain the tenant ID and scopes. The main thing we could possibly borrow would be _get_token, so we could get the automatic enable_cae=True passing, but that's a minor benefit and private attribute so I don't know if we'd want to.

In fact, I was wondering if we could reuse the code to parse claims, challenges, etc.

[mccoyp]

Can we reuse the code we added into core? #37652

@xiangyan99 unfortunately I don't know if we could effectively borrow the Core implementation. Our on_challenge method needs to be aware of both KV and CAE challenges, and while handling the latter we have to use content from past challenges to obtain the tenant ID and scopes. The main thing we could possibly borrow would be _get_token, so we could get the automatic enable_cae=True passing, but that's a minor benefit and private attribute so I don't know if we'd want to.

In fact, I was wondering if we could reuse the code to parse claims, challenges, etc.

Okay, understood! Yeah, we can align some of the parsing logic. I had borrowed the claims parsing logic largely from azure-mgmt-core, but that was written a while ago and it makes sense to align with azure-core. Since we're preparing this for an immediate GA, I think I'll minimize the amount of refactoring for challenge parsing and focus on the claims-related bits for now. We could use a clean-up of our challenge parsing generally, but I'd prefer to save that for a future preview release.

[xiangyan99]

Can we reuse the code we added into core? #37652

@xiangyan99 unfortunately I don't know if we could effectively borrow the Core implementation. Our on_challenge method needs to be aware of both KV and CAE challenges, and while handling the latter we have to use content from past challenges to obtain the tenant ID and scopes. The main thing we could possibly borrow would be _get_token, so we could get the automatic enable_cae=True passing, but that's a minor benefit and private attribute so I don't know if we'd want to.

In fact, I was wondering if we could reuse the code to parse claims, challenges, etc.

Okay, understood! Yeah, we can align some of the parsing logic. I had borrowed the claims parsing logic largely from azure-mgmt-core, but that was written a while ago and it makes sense to align with azure-core. Since we're preparing this for an immediate GA, I think I'll minimize the amount of refactoring for challenge parsing and focus on the claims-related bits for now. We could use a clean-up of our challenge parsing generally, but I'd prefer to save that for a future preview release.

We can revisit it in MQ. :)

[xiangyan99]

Given you implement your own auth policy, you may need something like #36565 to support the new protocol.

[mccoyp]

Given you implement your own auth policy, you may need something like #36565 to support the new protocol.

@xiangyan99 This support is now implemented (and tested by all of our policy tests) in 93c7eaa 🙂