Description of the new feature
Description
New-AzADServicePrincipalAppRoleAssignment only lets you name a service principal as the principal receiving the role. Every parameter set takes -ServicePrincipalId or -ServicePrincipalDisplayName, so there is no way to assign an app role to a group or a user.
In Graph terms, appRoleAssignedTo accepts a principalId that can be a user, a group or a service principal. Az only exposes the service principal case.
Split out from #17813 at the request of Alex Wang (@Alex-AZPS), who confirmed this as a gap in this comment.
Why it matters
Assigning an app role to a security group is the normal way to control who can use an application. It's what most tenants actually do, rather than assigning to individual principals. Right now that step can't be scripted with Az, so an otherwise pure Az deployment has to drop out to the Graph SDK for one call.
Suggestion
Add a -PrincipalId parameter (or equivalent) that accepts a user, group or service principal object id, matching what the underlying Graph API already supports.
Environment
Az.Resources, current version. Same behaviour on Windows PowerShell and PowerShell 7.
Proposed implementation details (optional)
No response
Description of the new feature
Description
New-AzADServicePrincipalAppRoleAssignmentonly lets you name a service principal as the principal receiving the role. Every parameter set takes-ServicePrincipalIdor-ServicePrincipalDisplayName, so there is no way to assign an app role to a group or a user.In Graph terms,
appRoleAssignedToaccepts aprincipalIdthat can be a user, a group or a service principal. Az only exposes the service principal case.Split out from #17813 at the request of Alex Wang (@Alex-AZPS), who confirmed this as a gap in this comment.
Why it matters
Assigning an app role to a security group is the normal way to control who can use an application. It's what most tenants actually do, rather than assigning to individual principals. Right now that step can't be scripted with Az, so an otherwise pure Az deployment has to drop out to the Graph SDK for one call.
Suggestion
Add a
-PrincipalIdparameter (or equivalent) that accepts a user, group or service principal object id, matching what the underlying Graph API already supports.Environment
Az.Resources, current version. Same behaviour on Windows PowerShell and PowerShell 7.
Proposed implementation details (optional)
No response