[Core] Use MSAL for managed identity authentication #25959
Conversation
️✔️AzureCLI-FullTest
|
|
Hi @jiasli, |
ghost
added
ghost
requested a review
from 
There was a problem hiding this comment.
We are now calling the new API on App Service: https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity?tabs=portal%2Chttp#connect-to-azure-services-in-app-code
So I assume expires_on is now an epoch int, but more test is still required to verify if this logic is still needed.
There was a problem hiding this comment.
Should we keep such error handler?
There was a problem hiding this comment.
I think not. They give no meaningful error message.
There was a problem hiding this comment.
Better to rename these attributes.
There was a problem hiding this comment.
Why we don't use managed identity for Cloud Shell authentication
Comment from MSAL team:
The old implementation groups Cloud Shell and other managed identity in similar API only because their wire protocol happened to be similar. But that should be an implementation detail.
The meanings of them are actually quite different. Other managed identity are fundamentally confidential clients such as service principal. The Cloud Shell identity is a user account. Cloud Shell merely acts as a "broker" to obtain token for the user account. For what it's worth, the windows broker (WAM) in MSAL Python supports the same acquire_token_interactive(..., prompt="none") usage to obtain a token for the already-signed-in user without prompt.
The new MSAL API is designed this way so that existing apps building on top of acquire_token_interactive(...) could smoothly utilize Cloud Shell or WAM, with no/few source code change. Just as Azure CLI needed minimal change to pick up WAM.
It is just unfortunate that Azure CLI had that az login --identity usage pattern and now stuck with it, so you can't fully reap the benefit, but that is not enough a reason for MSAL Python to revert to the old API.
There was a problem hiding this comment.
We need to test if xms_mirid exists in all types of managed identities' access tokens. (#13188)
There was a problem hiding this comment.
Out of curiosity, why would you need to know whether the token acquired is for a system-assigned managed identity or a user-assigned one?
From MSAL's perspective, it just use the input parameters (which would indeed contain a client_id/resource_id/etc when and only when using a user-assigned identity). Once a token is returned, the job is done. Why would a caller need to care whether it is a system-assigned or user-assigned based on the token outcome?
There was a problem hiding this comment.
Azure CLI has been showing system-assigned managed identity or user-assigned one since managed identity was initially supported. I don't tend to change its behavior. However, the logic for determining system-assigned or user-assigned is incorrect.
See
|
MSAL adoption |
There was a problem hiding this comment.
In versions <= 2.0.50 (November 6, 2018), _SUBSCRIPTION_NAME is used to denote the managed identity ID type. This is super confusing, so _ASSIGNED_IDENTITY_INFO was added in #7744 and these lines are added as an adaptor. However, such logic is still difficult to maintain and can easily leads to unwanted code path. Even its creator admits:
the code is a bit messy here to support both old and new styles.
#7744 (comment)
There was a problem hiding this comment.
If we remove this adaptor, we can add such history notes:
[BREAKING CHANGE] No long be compatible with login profile created by az login --identity of Azure CLI versions <= 2.0.50. If you are updating from those versions, please run az login --identity again to refresh the login profile.
There was a problem hiding this comment.
I have replaced the adaptor with a more general not-None check.
jiasli
changed the title
jiasli
modified the milestones:
Backlog,
Build 2025 (2025-05-19)❗ Breaking change release ❗
jiasli
force-pushed
the
mi
branch
2 times, most recently
from
aeec784 to
e58c0a7
Compare
| use_msal_managed_identity = cli_ctx.config.getboolean('core', 'use_msal_managed_identity', fallback=True) | ||
| set_use_msal_managed_identity(use_msal_managed_identity) | ||
| return use_msal_managed_identity or get_managed_identity_source() == AZURE_ARC | ||
| return use_msal_managed_identity |
There was a problem hiding this comment.
No longer necessary to detect Azure Arc, as MSAL managed identity is now the default.
There was a problem hiding this comment.
I'm a little confused.
Previously, this function always returns True in AZURE_ARC. Now it can return False with use_msal_managed_identity=false. Is this expected?
There was a problem hiding this comment.
Agree with Hang. AZURE_ARC could fail if customer accidently set use_msal_managed_identity=false because it's not supported with msrestazure
There was a problem hiding this comment.
Detecting Azure Arc will slow down CLI in other environments.
use_msal_managed_identity=false will be a hidden interface to revert to the old msrestazure implementation only when there are issues reported. Azure Arc users will not / need not to set it at all.
jiasli
requested review from
bebound,
calvinhzy,
evelyn-ys,
jsntcy,
kairu-ms,
necusjz and
zhoxing-ms
as code owners
|
Is there any plan to totally drop |
In the Ignite release. |
5 participants
Related command
az loginDescription
Close #25860, #22677
#31092 added support for MSAL managed identity. It can be opted in by setting
core.use_msal_managed_identity=trueconfig option.This PR makes
core.use_msal_managed_identity=truethe default, butcore.use_msal_managed_identityis kept so that it is possible to revert to the oldmsrestazureimplementation by runningaz config set core.use_msal_managed_identity=falseor setting environment variableAZURE_CORE_USE_MSAL_MANAGED_IDENTITY=false.Testing Guide
History Notes
[Core] Use MSAL for managed identity authentication.