You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue has an informative and human-readable title.
💡 Summary
Delegated permissions operate different than application permissions in that they are scoped to the access of the user who granted consent to the delegated permission. Therefore, the level of risk associated with delegated permissions depends on the user who granted consent.
The purpose of this issue is to check if privileged roles are assigned to the user who granted consent to a delegated permission. There's also a few other considerations we need to investigate, such as if a delegated permission as consented to all users (consentType set to AllPrincipal) or a single user (consentType set to Principal). See the example below for the type of object returned from the "/servicePrincipals/$ServicePrincipalId/oauth2PermissionGrants":
If a delegated permission was granted consent from a single user we can check which roles the user is assigned, if they are assigned any privileged roles, and then incorporate this into the severity score for an risky application/service principal.
Motivation and context
The risk level for a delegated permission depends on if its been admin consented for all users, or if user consent has been granted for the permission. This issue will more accurately assess the severity level for applications/service principals.
For each delegated permission, check if it's admin consented by checking if consentType equals AllPrincipal. If not, it's not admin consented.
For each delegated permission, check if it's assigned to a specific principalId. If true, compare the principalId against the privileged_users property that's created from the ExportAADProvider.psm1 to check if the user is assigned any privileged roles.
Acceptance criteria
The privileged roles assigned to a user who's granted consent to a delegated permission are included as criteria in the application/service principal's severity score.
Prerequisites
💡 Summary
Delegated permissions operate different than application permissions in that they are scoped to the access of the user who granted consent to the delegated permission. Therefore, the level of risk associated with delegated permissions depends on the user who granted consent.
The purpose of this issue is to check if privileged roles are assigned to the user who granted consent to a delegated permission. There's also a few other considerations we need to investigate, such as if a delegated permission as consented to all users (
consentTypeset toAllPrincipal) or a single user (consentTypeset toPrincipal). See the example below for the type of object returned from the"/servicePrincipals/$ServicePrincipalId/oauth2PermissionGrants":If a delegated permission was granted consent from a single user we can check which roles the user is assigned, if they are assigned any privileged roles, and then incorporate this into the severity score for an risky application/service principal.
Motivation and context
The risk level for a delegated permission depends on if its been admin consented for all users, or if user consent has been granted for the permission. This issue will more accurately assess the severity level for applications/service principals.
Implementation notes
"/servicePrincipals/$ServicePrincipalId/oauth2PermissionGrants"endpoint to get delegated permissions for service principals.consentTypeequalsAllPrincipal. If not, it's not admin consented.principalId. If true, compare theprincipalIdagainst theprivileged_usersproperty that's created from the ExportAADProvider.psm1 to check if the user is assigned any privileged roles.Acceptance criteria