[Feature Request]: Add permission classification

[alexrsagen]

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 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 cmdlets:
  • Get-MgServicePrincipal
  • Get-MgServicePrincipalDelegatedPermissionClassification
  • New-MgServicePrincipalDelegatedPermissionClassification
  • Update-MgServicePrincipalDelegatedPermissionClassification
  • Remove-MgServicePrincipalDelegatedPermissionClassification
• 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

[KelvinTegelaar]

Only sponsors can create feature requests

[OfficialEsco]

Can it reopen if i request this? 👀

[KelvinTegelaar]

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!

[alexrsagen]

Hi @KelvinTegelaar, thanks for the quick response.

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

[KelvinTegelaar]

Done!