Azure-cli: Adding preAuthorizedApplications with az ad app update fails

[bradcavanagh-ffs]

Describe the bug

Command Name
When running az ad app update to add to the list in preAuthorizedApplications, I receive the following error:

Errors:

A value without a type name was found and no expected type is available. When the model is specified, each value in the payload must have a type which can be either specified in the payload, explicitly by the caller or implicitly inferred from the parent value.

I've tried varying combinations of quotes, escaping out []{}, or trying to pass the JSON through as @preAuthorizedApplications.json but all fail.

When run with --debug it looks like the PATCH request to https://graph.windows.net is going through, but the request body is incomplete (app1Guid and app2Guid are per the reproduction steps):

...
msrest.http_logger : Request URL: 'https://graph.windows.net/tenantGuid/applications/app1Guid?api-version=1.6'
msrest.http_logger : Request method: 'PATCH'
msrest.http_logger : Request headers:
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'accept-language': 'en-US'
msrest.http_logger :     'Accept': 'application/json'
msrest.http_logger :     'Content-Length': '82'
msrest.http_logger :     'User-Agent': 'python/3.7.3 (Darwin-18.6.0-x86_64-i386-64bit) msrest/0.6.6 msrest_azure/0.4.34 azure-graphrbac/0.60.0 Azure-SDK-For-Python AZURECLI/2.0.64'
msrest.http_logger : Request body:
msrest.http_logger : {"preAuthorizedApplications": [{"appId": "app2Guid"}]}
...

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

• Register app1 and app2 with Azure AD
• az ad app update --id app1Guid --add preAuthorizedApplications "{'appId':'app2Guid', 'permissionIds':['permissionsGuid']}"

Expected Behavior

app2 is listed as a pre-authorized application, allowing it to use app1.

Environment Summary

Darwin-18.6.0-x86_64-i386-64bit
Python 3.7.3
Shell: bash

azure-cli 2.0.64 *

Extensions:
storage-preview 0.2.5

Additional Context

[adewaleo]

cc: @yugangw-msft

[rbhadti94]

Hi @adewaleo @haroldrandom @jiasli ,

Is there an update or workaround for this at the moment? We're currently trying to add preAuthorizedApplications via azure CLI and are unable to do so.

[yonzhan]

add to S165.

[PhilippJust]

I tried to directly use the RestApi as a workaround.

Observation 1 - Rest Api V1.6 doesn't work

Using a PATCH request on https://graph.windows.net/myorganization/applications/{app-id}?api-version=1.6 I receive exactly the error message the original poster observed.
So it is only partially the CLI's fault....

Observation 2 - Rest Api V2.0 is accessible for users but not for Service Principals

Adding the clients is working in the azure portal.
When I monitor my browser's network calls, I see that the request however goes to https://graph.windows.net/myorganization/applications/{app-id}?api-version=2.0
When I log in as a user and pass my Bearer token to the request, it works as expected.
When I obtain a token using a service principal, I get following error message:

The specified api-version is invalid. The value must exactly match a supported version.

[adewaleo]

@rbhadti94, @bradcavanagh-ffs . Unfortunately, I am no longer on the CLI team. Although, it seems this has been added to the current team's backlog.

In the AD App Manifest reference docs preAuthorizedApplications have this in their description: "Requires an admin to have provided consent to the application".

This doc v2-permissions-and-consent#permission-types also mentions that: "Application permissions are used by apps that run without a signed-in user present; for example, apps that run as background services or daemons. Application permissions can only be consented by an administrator."

Unless, I am mistaken, this might explain why you could only update the preauthorizedapplications using a user bearer token and not an SP bearer token @PhilippJust. I doubt an SP can be given an Admin role. But I might be wrong

[rbhadti94]

Hi @adewaleo ,

This isn't a permissions issue. I can get this command working using:

az rest patch ...

and then patching the JSON payload to https://graph.windows.net

But when trying to directly run the azure cli command as mentioned by @bradcavanagh-ffs :

az ad app update --id app1Guid --add preAuthorizedApplications "{'appId':'app2Guid', 'permissionIds':['permissionsGuid']}"

it fails.

So why does the POST method work but not the CLI method?

[adewaleo]

@rbhadti94, my comment about permissions was in response to @PhilippJust's comment about the difference in API behavior depending on the kind of token.

I haven't investigated why the command isn't working properly (I'm no longer on the CLI team). But hopefully the person assigned can get to it soon.

[PhilippJust]

@rbhadti94
Are you logging in as a user or a service principal? I tried to reproduce your behaviour with az rest and it works exactly as the manual request to the REST-Api as described in my earlier comment.

[rbhadti94]

Hey @PhilippJust,

Yes I can get it working with az rest using a service principal.

But I would rather be able to use az ad app update --id app1Guid --add preAuthorizedApplications <ID> than a direct REST command to the API.

[arrownj]

Hi @rbhadti94 @PhilippJust,

Currently Azure CLI use graph api version 1.6 which do not support preAuthorizedApplications. We are considering upgrade to version 2.0. And will update here if we get the conclusion.

Thanks @adewaleo for the reply of different tokens problem. I agree with you, that might because the accounts used have different permissions.

[rbhadti94]

Hi @arrownj,

Thanks for the response.

We are currently POSTing/PATCHing to https://graph.microsoft.com/v1.0/applications/<appobjectID> in order to update the preAuthorizedApplications.

Assuming that this should be supported by Azure CLI then?

[jiasli]

AD Graph 1.6 does define preAuthorizedApplications but it is somehow not working with PATCH request.

Since AAD is deprecating AD Graph API, as @rbhadti94 pointed out, for now you may use az rest to call MS Graph API Update application directly and update the preAuthorizedApplications field of apiApplication resource type:

# bash
appObjectId=502912d6-eda3-4eb0-a3e1-5918dba268c3
az rest -m PATCH -u https://graph.microsoft.com/beta/applications/$appObjectId --headers Content-Type=application/json -b '{"api":{"preAuthorizedApplications":[{"appId":"93dde3da-9fca-47dd-aee2-409b402ffed3","permissionIds":["7fde0c1f-87a7-4b64-80a8-d2f97c66357c"]}]}}'

[jiasli]

We will track MS Graph issues at https://github.com/Azure/azure-cli/issues/12946