Azure / azure-cli

Azure Command-Line Interface
MIT License
3.96k stars 2.94k forks source link

[Feature Request] Support custom client ID #22775

Open jiasli opened 2 years ago

jiasli commented 2 years ago

Related command az login

Is your feature request related to a problem? Please describe. Currently Azure CLI uses a fixed client ID to authenticate into AAD

https://github.com/Azure/azure-cli/blob/1d973cceb38980181eeaa45934497d2148a3e7b2/src/azure-cli-core/azure/cli/core/auth/identity.py#L22

This client ID 04b07795-8ddb-461a-bbee-02f9e1bf7b46 is a First Party Application, registered in First Party Portal.

This application is only pre-authorized for a limited set of Microsoft Graph permissions. Using Azure CLI command az rest to call trustFrameworkKeySet API which requires TrustFrameworkKeySet.Read.All, TrustFrameworkKeySet.ReadWrite.All will fail (https://github.com/Azure/azure-cli/issues/22755).

Describe the solution you'd like Support custom client ID, so that users can create their own app in their tenant, consent to that app and let Azure CLI use that app’s client ID:

az login --client-id

Describe alternatives you've considered Apply for those permissions in First Party Portal to support these APIs.

yonzhan commented 2 years ago

Support custom client ID

navba-MSFT commented 2 years ago

Removing CXP Attention label from this issue since this was created internally by SDK team

jiasli commented 1 year ago

We received a similar issue today that the user wants to use Azure CLI's client ID to call b2cIdentityUserFlows API which requires delegated permission IdentityUserFlow.Read.All, IdentityUserFlow.ReadWrite.All:

https://docs.microsoft.com/en-us/graph/api/identitycontainer-list-b2cuserflows?view=graph-rest-beta&tabs=csharp

image

but Azure CLI's Directory.AccessAsUser.All delegated permission is not sufficient. This causes failure:

AADSTS65002: Consent between first party application '04b07795-8ddb-461a-bbee-02f9e1bf7b46' and first party resource '00000003-0000-0000-c000-000000000000' must be configured via preauthorization - applications owned and operated by Microsoft must get approval from the API owner before requesting tokens for that API.

jiasli commented 1 year ago

Workaround: Use service principal instead of user login

  1. Create your own application and service principal
  2. Give the application Application Permission IdentityUserFlow.Read.All, IdentityUserFlow.ReadWrite.All
  3. Log in to Azure CLI with that service principal: https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli#sign-in-with-a-service-principal
kthejoker commented 1 year ago

What if a user doesn't have permission to create a service principal?

This exact same flow worked fine in October of 2022. A user could use a DeviceCodeCredential and then access the Databricks scope with their own tokens.

Now I have to create an SP?

jiasli commented 7 months ago

Azure CLI's first party application 04b07795-8ddb-461a-bbee-02f9e1bf7b46 is currently registered with below Microsoft Graph delegated permissions:

This can be observed in the access token retrieved from

az account get-access-token --scope https://graph.microsoft.com/.default

The access token contains the below scp claim:

  "scp": "AuditLog.Read.All Directory.AccessAsUser.All email Group.ReadWrite.All openid profile User.ReadWrite.All",
jiasli commented 7 months ago

This exact same flow worked fine in October of 2022. A user could use a DeviceCodeCredential and then access the Databricks scope with their own tokens.

@kthejoker, There is no DeviceCodeCredential concept in Azure CLI. Are you referring to az login --use-device-code? If so and you are seeing failure, that indicates your tenant may now have a Conditional Access policy that blocks accessing Databricks scope with Azure CLI's client ID and device code flow.

Now I have to create an SP?

Yes.

What if a user doesn't have permission to create a service principal?

You need to work with your tenant admin to either

cveld commented 2 months ago

Today I started a project to configure PIM using terraform using the azuread provider's resource azuread_group_role_management_policy. This requires RoleManagementPolicy.ReadWrite.AzureADGroup. I am not a great fan of your suggested workaround to introduce a service principal as we work with secret-free service principals. It seems either the required permission scopes are to be added to the first party app registration, or the custom client id should be introduced.

cveld commented 2 months ago

@jiasli is there any plan to extend the permission scopes on the first party app registration 04b07795-8ddb-461a-bbee-02f9e1bf7b46? Any reason why you are keeping this a limited range? In the meanwhile the msgraph cli app registration did get the additional scopes. Although that is what I am assuming as the msgraph cli is capable of user delegated access to PIM related operations.