[GH-ISSUE #2955] [Feature Request]: Add permission classification

kerem commented

2026-03-02 13:44:27 +03:00

Owner

Originally created by @alexrsagen on GitHub (Oct 25, 2024).
Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/2955

Description of the new feature - must be an in-depth explanation of the feature you want, reasoning why, and the added benefits for MSPs as a whole.

The standard "Allow users to consent to applications with low security risk (Prevent OAuth phishing. Lower impact, less secure.)" was added in github.com/KelvinTegelaar/CIPP@3e58a79873, github.com/KelvinTegelaar/CIPP-API@86210c60c6 to fulfill feature request #1685.

Assigning the default role permission grant policies ["ManagePermissionGrantsForSelf.microsoft-user-default-low"], without classifying any permissions as low risk, is equivalent to not assigning any policies at all [] (which is what the "Do not allow user consent" setting in Entra ID does).

Adding to #1685, I'd like to request the option to specify which permissions to classify as "low risk" when enabling this standard in CIPP. This makes the entire standard easier to use, by automating the classification of permissions across tenants.

The following permissions are the most requested application permissions with low-risk access, according to Microsoft.

User.Read - sign in and read user profile
offline_access - maintain access to data that users have given it access to
openid - sign users in
profile - view user's basic profile
email - view user's email address

The list of permissions to classify as low risk could be specified in a similar matter as the "Allowed application IDs" for the standard "Require admin consent for applications (Prevent OAuth phishing)". It would be nice if the most requested permissions with low-risk access was a default (but modifyable) value.

I work for an MSP and we're trying to deploy this standard, but we're now realizing that no permissions get classified when deploying it. We're having to either roll back the standard or automate the permission classification with Microsoft Graph ourselves.

PowerShell commands you would normally use to achieve above request

PowerShell module Microsoft.Graph.Applications cmdlets:
Microsoft Graph API endpoints:
- List servicePrincipals
  - The undocumented OData filter attribute "hasPermissionClassifications" is useful: GET /servicePrincipals?$filter=hasPermissionClassifications%20eq%20true&$expand=delegatedPermissionClassification
- List delegatedPermissionClassifications collection of servicePrincipal
- Create delegatedPermissionClassification
- Delete delegatedPermissionClassification

Originally created by @alexrsagen on GitHub (Oct 25, 2024). Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/2955 ### Description of the new feature - must be an in-depth explanation of the feature you want, reasoning why, and the added benefits for MSPs as a whole. The [standard](https://docs.cipp.app/user-documentation/tenant/standards) "Allow users to consent to applications with low security risk (Prevent OAuth phishing. Lower impact, less secure.)" was added in https://github.com/KelvinTegelaar/CIPP/commit/3e58a798738c2aaa86ab8af49271838ae382e7d4, https://github.com/KelvinTegelaar/CIPP-API/commit/86210c60c6e7c413eb1348b78036b31f91e45e17 to fulfill feature request #1685. Assigning the default role permission grant policies `["ManagePermissionGrantsForSelf.microsoft-user-default-low"]`, without classifying any permissions as low risk, is equivalent to not assigning any policies at all `[]` (which is what the "Do not allow user consent" setting in Entra ID does). Adding to #1685, I'd like to request the option to specify which permissions to classify as "low risk" when enabling this standard in CIPP. This makes the entire standard easier to use, by automating the classification of permissions across tenants. The following permissions are the most requested application permissions with low-risk access, according to Microsoft. - `User.Read` - sign in and read user profile - `offline_access` - maintain access to data that users have given it access to - `openid` - sign users in - `profile` - view user's basic profile - `email` - view user's email address The list of permissions to classify as low risk could be specified in a similar matter as the "Allowed application IDs" for the standard "Require admin consent for applications (Prevent OAuth phishing)". It would be nice if the most requested permissions with low-risk access was a default (but modifyable) value. I work for an MSP and we're trying to deploy this standard, but we're now realizing that no permissions get classified when deploying it. We're having to either roll back the standard or automate the permission classification with Microsoft Graph ourselves. ### PowerShell commands you would normally use to achieve above request - PowerShell module [Microsoft.Graph.Applications](https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.applications/?view=graph-powershell-1.0) cmdlets: - [`Get-MgServicePrincipal`](https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.applications/get-mgserviceprincipal?view=graph-powershell-1.0) - [`Get-MgServicePrincipalDelegatedPermissionClassification`](https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.applications/get-mgserviceprincipaldelegatedpermissionclassification?view=graph-powershell-1.0) - [`New-MgServicePrincipalDelegatedPermissionClassification`](https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.applications/new-mgserviceprincipaldelegatedpermissionclassification?view=graph-powershell-1.0) - [`Update-MgServicePrincipalDelegatedPermissionClassification`](https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.applications/update-mgserviceprincipaldelegatedpermissionclassification?view=graph-powershell-1.0) - [`Remove-MgServicePrincipalDelegatedPermissionClassification`](https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.applications/remove-mgserviceprincipaldelegatedpermissionclassification?view=graph-powershell-1.0) - Microsoft Graph API endpoints: - [`List servicePrincipals`](https://learn.microsoft.com/en-us/graph/api/serviceprincipal-list?view=graph-rest-1.0&tabs=http) - The undocumented OData filter attribute "hasPermissionClassifications" is useful: `GET /servicePrincipals?$filter=hasPermissionClassifications%20eq%20true&$expand=delegatedPermissionClassification` - [`List delegatedPermissionClassifications collection of servicePrincipal`](https://learn.microsoft.com/en-us/graph/api/serviceprincipal-list-delegatedpermissionclassifications?view=graph-rest-1.0&tabs=http) - [`Create delegatedPermissionClassification`](https://learn.microsoft.com/en-us/graph/api/serviceprincipal-post-delegatedpermissionclassifications?view=graph-rest-1.0&tabs=http) - [`Delete delegatedPermissionClassification`](https://learn.microsoft.com/en-us/graph/api/serviceprincipal-delete-delegatedpermissionclassifications?view=graph-rest-1.0&tabs=http)

kerem

2026-03-02 13:44:27 +03:00

closed this issue
added the
enhancement

no-priority

no-activity
labels

kerem commented

2026-03-02 13:44:28 +03:00

Author

Owner

@KelvinTegelaar commented on GitHub (Oct 25, 2024):

Only sponsors can create feature requests

@KelvinTegelaar commented on GitHub (Oct 25, 2024): Only sponsors can create feature requests

kerem commented

2026-03-02 13:44:28 +03:00

Author

Owner

@OfficialEsco commented on GitHub (Oct 25, 2024):

Can it reopen if i request this? 👀

@OfficialEsco commented on GitHub (Oct 25, 2024): Can it reopen if i request this? 👀

kerem commented

2026-03-02 13:44:28 +03:00

Author

Owner

@KelvinTegelaar commented on GitHub (Oct 25, 2024):

Can it reopen if i request this? 👀

Appreciate you jumping in here, and we totally get where you’re coming from. But allowing sponsors to re-request closed ideas from non-sponsors kind of goes against the spirit of our system.

The goal behind limiting requests to paying users is to keep things fair, focused, and impactful for everyone supporting CIPP directly. When requests get re-submitted this way, it can open the door to a flood of indirect requests that might not have the same priority or backing, or financially impacts us to a point where we will be forced to make a choice to make CIPP a paid application only.

When a sponsor makes a request they directly pay for training our helpdesk, the actual development time we spend to develop a feature, the time we spend documenting the feature and for any security audits we'll have to perform. If sponsors would reopen requests for non-sponsors there would be no reason for anyone to pay, as they can just find another paying user. This would eventually on a longer term lead to situations where we'd just wont be able to operate anymore. Our system helps keep this sustainable :)

That being said; as you are also an active contributor you could implement this, or ask the submitter to try to implement it himself. We accept any PR that involves good code. :)

It’s not about turning down good ideas—just keeping the pipeline manageable so we can keep delivering meaningful updates and improvements for you and all our sponsors. Hope that makes sense, and thanks for understanding!

@KelvinTegelaar commented on GitHub (Oct 25, 2024): > Can it reopen if i request this? 👀 Appreciate you jumping in here, and we totally get where you’re coming from. But allowing sponsors to re-request closed ideas from non-sponsors kind of goes against the spirit of our system. The goal behind limiting requests to paying users is to keep things fair, focused, and impactful for everyone supporting CIPP directly. When requests get re-submitted this way, it can open the door to a flood of indirect requests that might not have the same priority or backing, or financially impacts us to a point where we will be forced to make a choice to make CIPP a paid application only. When a sponsor makes a request they directly pay for training our helpdesk, the actual development time we spend to develop a feature, the time we spend documenting the feature and for any security audits we'll have to perform. If sponsors would reopen requests for non-sponsors there would be no reason for anyone to pay, as they can just find another paying user. This would eventually on a longer term lead to situations where we'd just wont be able to operate anymore. Our system helps keep this sustainable :) That being said; as you are also an active contributor you could implement this, or ask the submitter to try to implement it himself. We accept any PR that involves good code. :) It’s not about turning down good ideas—just keeping the pipeline manageable so we can keep delivering meaningful updates and improvements for you and all our sponsors. Hope that makes sense, and thanks for understanding!

kerem commented

2026-03-02 13:44:28 +03:00

Author

Owner

@alexrsagen commented on GitHub (Oct 25, 2024):

Hi @KelvinTegelaar, thanks for the quick response.

We (@Konsept-IT) are now a sponsor, please re-open 😄

@alexrsagen commented on GitHub (Oct 25, 2024): Hi @KelvinTegelaar, thanks for the quick response. We (@Konsept-IT) are now a sponsor, please re-open 😄

kerem commented

2026-03-02 13:44:28 +03:00

Author

Owner

@KelvinTegelaar commented on GitHub (Oct 25, 2024):

Done!

@KelvinTegelaar commented on GitHub (Oct 25, 2024): Done!

kerem commented

2026-03-02 13:44:28 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Nov 4, 2024):

This issue is stale because it has been open 10 days with no activity. We will close this issue soon. If you want this feature implemented you can contribute it. See: https://docs.cipp.app/dev-documentation/contributing-to-the-code . Please notify the team if you are working on this yourself.

@github-actions[bot] commented on GitHub (Nov 4, 2024): This issue is stale because it has been open 10 days with no activity. We will close this issue soon. If you want this feature implemented you can contribute it. See: https://docs.cipp.app/dev-documentation/contributing-to-the-code . Please notify the team if you are working on this yourself.

kerem commented

2026-03-02 13:44:28 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Nov 18, 2024):

This issue was closed because it has been stalled for 14 days with no activity.

@github-actions[bot] commented on GitHub (Nov 18, 2024): This issue was closed because it has been stalled for 14 days with no activity.

Rows
Columns

[GH-ISSUE #2955] [Feature Request]: Add permission classification #1468

Description of the new feature - must be an in-depth explanation of the feature you want, reasoning why, and the added benefits for MSPs as a whole.

PowerShell commands you would normally use to achieve above request