App roles update is broken after Azure CLI upgrade

[floushee]

This is autogenerated. Please review and update as needed.

Describe the bug

Command Name
az ad app update

Errors:

Expected property 'lang' is not present on resource of type 'AppRole'

To Reproduce:

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

• Put any pre-requisite steps here...
• az ad app update --id {} --app-roles {}

Expected Behavior

Environment Summary

Windows-10-10.0.22000-SP0
Python 3.10.4
Installer: MSI

azure-cli 2.37.0

Extensions:
kusto 0.5.0
resource-graph 2.1.0

Dependencies:
msal 1.18.0b1
azure-mgmt-resource 21.1.0b1

Additional Context

Today Azure DevOps rolled out the Azure CLI version 2.37, which forced me to migrate some of our Azure CLI steps as explained in this migration guide: https://docs.microsoft.com/en-gb/cli/azure/microsoft-graph-migration

The only thing that is still not working is the update of our app registration's roles. We are currently using the following json file for the roles deployment:

[ { "allowedMemberTypes": [ "User" ], "description": "Grafana read only Users", "displayName": "Grafana Viewer", "id": "....", "isEnabled": true, "lang": null, "origin": "Application", "value": "Viewer" }, { "allowedMemberTypes": [ "User" ], "description": "Grafana Editor Users", "displayName": "Grafana Editor", "id": "...", "isEnabled": true, "lang": null, "origin": "Application", "value": "Editor" } ]

It looks like this was already fixed in a different cli: pnp/cli-microsoft365#3131

[yonzhan]

Jiashuo Li (@jiasli) for awareness

[floushee]

It is working when I remove the "lang" property. Until now it did not matter. The "lang"=null is also visible in manifest json in the portal and I have seen it in some blog posts etc like this. So I might not be the only one who gets confused by this new behaviour and it would make sense to fix it, or at least provide some error message.

[jiasli]

I saw the PR pnp/cli-microsoft365#3137 just deletes lang property:

https://github.com/pnp/cli-microsoft365/pull/3137/files#diff-4bffc2f0d69d60fce428e83ed0b46c80a224eea3de200b3197330bdfb59a7fd0R381-R385

    if (graphManifest.appRoles) {
      graphManifest.appRoles.forEach((role: any) => {
        delete role.lang;
      });
    }

Actually, Azure CLI's az ad app update --id {} --app-roles {} doesn't make any special processing for appRole property. It sends the JSON to Update application API as-is:

azure-cli/src/azure-cli/azure/cli/command_modules/role/custom.py

Line 715 in 710c821

app_roles=app_roles, optional_claims=optional_claims, required_resource_accesses=required_resource_accesses

The appRole resource type doesn't have lang property, so the Microsoft Graph service returned that error.

Indeed, we can add some special logic on the client side (Azure CLI) to remove the lang property here:

azure-cli/src/azure-cli/azure/cli/command_modules/role/custom.py

Lines 1570 to 1579 in 710c821

	def _build_app_roles(app_roles):
	# https://docs.microsoft.com/en-us/graph/api/resources/approle
	if isinstance(app_roles, dict):
	logger.info('Getting "appRoles" from a full manifest')
	app_roles = app_roles.get('appRoles', [])
	for x in app_roles:
	# Make sure 'id' is specified as a GUID if not provided.
	if not x.get(ID):
	x[ID] = str(_gen_guid())
	return app_roles

but I think it would be more reasonable for the manifest to be consistent with Microsoft Graph API. I will work internally with Microsoft Graph team on this.

[MaddyMicrosoft]

The failure comes from the exported app-roles manifest including a lang property, which the Microsoft Graph appRole resource does not accept, and the CLI forwards the manifest as-is, so Graph rejects it.
Removing the lang entries from your appRoles JSON (as you found) is the supported path. Stripping unknown manifest properties automatically isn't on the roadmap right now given the limited demand, so closing on that basis.
If a cleaner error for rejected manifest properties would help your workflow, please open a focused issue with the exact JSON and --debug output and we can consider it.