Conversation
With recent changes to Identity and Core, requests for CAE tokens are now disabled by default. Since ARM supports CAE and ARM SDKs have logic for handling these CAE claims challenges, ARMChallengeAuthenticationPolicy and AsyncARMChallengeAuthenticationPolicy were updated to ensure that enable_cae is set to True Signed-off-by: Paul Van Eck <paulvaneck@microsoft.com>
|
@msyyc Would be great to have your review on this :) |
|
|
||
| def __init__(self, credential: "TokenCredential", *scopes: str, **kwargs: Any) -> None: | ||
| # ARM supports Continuous Access Evaluation (CAE). This policy will enable it by default. | ||
| kwargs.setdefault("enable_cae", True) |
There was a problem hiding this comment.
@pvaneck Shall we wait for azure-core==1.28.1 release then update setup.py of azure-mgmt-core. After that, merge the PR and release a new version for azure-mgmt-core ?
There was a problem hiding this comment.
Hey, I wouldn't be opposed to it, @xiangyan99, what do you think? You think this would warrant a minimum core version bump for azure-mgmt-core? I suppose we are technically setting a keyword arg that will only be handled in the latest core. Although behavior changes with CAE being enabled/disabled mainly depends on if the latest identity version is used or not.
There was a problem hiding this comment.
Waiting for azure-core 1.29.0 is a good idea because we added some protection code in 1.29.0 to pop enable_cae before calling into transport.
My question is do we want to make enable_cae default to True?
Are you sure if all mgmt libraries handle challenge correctly?
Client libraries decided to set enable_cae back to False by default because if a library does not handle challenge correctly, it crashes. Hence we decided to make CAE an opt-in functionality and needed each library to enable explicitly.
There was a problem hiding this comment.
Yea, makes sense regarding core versioning.
I think defaulting to true here should be fine as anything that uses the ARMChallengeAuthenticationPolicy would be able to handle challenges because of the on_challenge implementation. Not sure if we'd want to update each mgmt library to call something like:
authentication_policy=ARMChallengeAuthenticationPolicy( ... , enable_cae=True)when we already know that the ARM endpoint supports CAE, so an update in this policy would opt-in all mgmt packages.
@msyyc WDYT?
|
Hi @pvaneck. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days. |
github-actions
bot
added
the
no-recent-activity
|
Hi @pvaneck. Thank you for your contribution. Since there hasn't been recent engagement, we're going to close this out. Feel free to respond with a comment containing |
3 participants
With recent changes to Identity and Core, requests for CAE tokens are now disabled by default. Since the ARM API endpoint and ARM SDK both support CAE (with the ARM policy containing logic for handling these CAE claims challenges),
ARMChallengeAuthenticationPolicyandAsyncARMChallengeAuthenticationPolicywere updated to ensure thatenable_caeis set to True.Since the paradigm is now shifting towards enabling CAE per-request with CAE disabled by default, this change allows credentials to still get CAE-enabled tokens when interacting with ARM SDKs.