Role assigned to scope not returned unless scope is specified

[jongio]

Describe the bug

When I assign a role to an SP at a given scope that role is not returned with the az role assignment list command.

Doesn't work in both CLI and Portal, works in REST API

Both

az role assignment list --assignee [objectId]
az role assignment list --assignee [appId]

Do not return roles that are assigned.

The portal does not show roles

But, if I add a scope, roles are returned:

The REST API does not require scope. Roles are returned without scope.

https://management.azure.com/subscriptions/{{subscriptionId}}/providers/Microsoft.Authorization/roleAssignments?api-version=2020-04-01-preview&$filter=assignedTo('aae06f9f-3c90-442b-bdc4-f688818132c6')

If I create a new SP and assign it the Tag Contributor role, then that roles is returned when using the CLI without scope.

To Reproduce

1. Create a new SP
   az ad sp create-for-rbac --skip-assignment
2. Assign a role with scope
   az role assignment create --assignee 32c6eeab-6338-4bdb-b21f-69836b2d99c4 --role "Tag Contributor" --scope /subscriptions/25fd0362-aa79-488b-b37b-d6e892009fdf/resourceGroups/aztagsync1
3. Query for roles
   az role assignment list --assignee 32c6eeab-6338-4bdb-b21f-69836b2d99c4

Zero results are returned.

Expected behavior

Roles are returned without specifying a scope.

This is also true for the Azure portal, but I'm not sure where to report that bug. If you know, Please let me know.

Environment summary

azure-cli 2.8.0
WSL2

Additional context

I'm Microsoft, so ping me on Teams to diagnose further.

azsdke2e

[jiasli]

Possibly related to #13762. @qianwens, could you help take a look as well?

[qianwens]

@jongio @jiasli , this behavior is by design that CLI will build a subscription level scope if there is no scope specified https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/azure/cli/command_modules/role/custom.py#L181
You need to specify --all to list all the assignments under the current subscription.
I agree that this behavior is not intuitive for the customer, but fix this issue may cause a breaking change.

[jongio]

I have confirmed that using the --all switch returns the role:

Do we have tests in place to see if this will cause a breaking change to make --all the default?

I personally, an avid CLI user and my customer, a novice CLI user, could not figure this out. I strongly suggest that we make --all the default to avoid these types of situations. In fact, I had to engage multiple on-call support teams, which involved many hours of their time, plus my time, plus the customer uncertainty of not knowing why the Tag update was working without (what we thought) was no roles assigned.

If we have tests in place, then we can try to make --all the default and see what breaks and then determine if it is worth it to make the change.

Thanks,
Jon