Thumbnail Running applications with limited SharePoint permissions

Running applications with limited SharePoint permissions

Securing application access to SharePoint through Entra ID is easy. But often enough, these applications have far too much permissions. Do you really want to give an application access to your entire SharePoint tenant if it’s not necessary? This post is about how to let applications access SharePoint using the principle of least privilege.

Many companies employ them: solutions with standalone applications that execute a certain task. For example, automating the creation of SharePoint sites or enriching files with certain metadata. Many of these applications are configured to have permissions that are broader than what they actually need, for example Sites.FullControl.All.

sites-fullcontrol-all

This setup is reached through a few clicks of a mouse. After adding a certificate, this application can access the entire SharePoint tenant, which is convenient, but dangerous as well. It essentially has what I would call: ‘God mode’ on SharePoint. It’s just slightly short of being a ‘SharePoint Administrator’. This means that the keys to the kingdom are effectively handed over to the Developers who created the application. If they make a mistake, the entire SharePoint tenant might be impacted.

As long as you’re not provisioning entire sites, you don’t actually need this level of permissions. In those cases there is another way: tone down on the permissions using Resource Specific Consent (RSC). Resource Specific Consent means just what it sounds like: instead of assigning permissions to the entire tenant, you can assign permissions to specific resources. In the case of SharePoint these resources are sites. RSC is a step in the direction of more granular permission controls.

Configuring RSC starts with creating/updating an Entra application registration with the permission scope Sites.Selected.

sites-selected

As you can see RSC for SharePoint comes in two flavors: Microsoft Graph and SharePoint. The level of permissions that are granted is the same, the difference lies in what API the programmers are intending to use: The Microsoft Graph API or the SharePoint REST API.

RSC for Microsoft Teams: There's also RSC for Microsoft Teams, enabling access to resources like specific teams, channels or chats, but that's currently not configurable from Entra ID.

Important to note is that we’ve only registered the necessary scope for RSC in step 1. This was easy. However, there’s currently no place in the UI of Entra ID or SharePoint to configure what sites you want the application to have access to. This can be done by issuing requests against the Microsoft Graph API. For this post we’ll take another route though: assign the permissions using scripting.

Using the CLI for Microsoft 365 we can grant permissions in the following manner:

m365 login

m365 spo site apppermission add --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --permission fullcontrol --siteUrl "https://contoso.sharepoint.com/sites/project-x"

The above script needs to be run with appropriate administrative permissions. You need to be a site collection admin on the site you are executing the script on.

Update 14-10-2022: I claimed that you could do this using the SharePoint admin role as well. A reader verified this and corrected me: you do need to be 'site collection admin' in all scenario's, thanks Gerben!

You can also:

# List the existing app permissions that are assigned to the SharePoint site:
m365 spo site apppermission list --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --siteUrl "https://contoso.sharepoint.com/sites/project-x"

# Update existing permissions to another permission type:
m365 spo site apppermission add --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --permission read --siteUrl "https://contoso.sharepoint.com/sites/project-x"

# Remove the assigned app permissions from the SharePoint site:
m365 spo site apppermission remove --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --siteUrl "https://contoso.sharepoint.com/sites/project-x"

There’s currently four types of permissions that can be granted. They match the available app-only scopes in Entra ID:

  1. read - Read items in a site collection
  2. write - Read and write items in a site collection
  3. manage - Read and write items and lists in a site collection
  4. fullcontrol - Have full control of a site collection
Note: When reading the documentation for the Graph API it seems like there should be an 'owner' role instead of 'manage' and 'fullcontrol'. However, the owner role does not work. I've created an issue on GitHub to request changes in the documentation.

If you are more into using PnP.PowerShell , you can achieve the same. But you need to execute two commandlets. First grant Read or Write permissions. Then update it to Manage or FullControl:

Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/project-x" -Interactive

$permission = Grant-PnPAzureADAppSitePermission -AppId "ce6bb9a7-c909-4538-b9dd-930724d7259d" -DisplayName "TestApp" -Permissions Write 

Set-PnPAzureADAppSitePermission -PermissionId $permission.Id -Permissions FullControl

What I explained above is all about a user adding permissions for an application. But what if you want to automate that? It could be necessary in certain scenario’s to do so. You can in fact do this, but you would need another Entra application registration with the Sites.FullControl.All app-only permission scope to be able to configure it. This kind of seems to defeat the purpose, but there are cases where it is a good setup. For example: the application that assigns app permissions for other applications may run on a different system where extra care has been taken to avoid security pitfalls.

Having set this all up, the only thing that’s left is to let your application connect to SharePoint. You can do this through Managed Identity (when running an Azure Function, Automation Runbook or App Service), or through a Client Certificate. There are a lot of roads to get connected, using various programming or scripting languages, I won’t go into that here today. But I have blogged about running the CLI for Microsoft 365 on an Azure Function earlier, that is a nice example where RSC would be useful!

Assigning ‘God mode’ to an application on SharePoint should be avoided whenever possible. Fortunately we can restrict permissions to specific SharePoint sites, using Resource Specific Consent. The CLI for Microsoft 365 and PnP.PowerShell offer easy to use tools to get this set-up.

If you have any questions, please drop me a post!


sharepoint entraid cli-microsoft365 pnp-powershell security
Support me by sharing this

More

More blogs

Resource Specific Consent - Using delegated Sites.Selected
Resource Specific Consent - Using delegated Sites.Selected

Sites.Selected has been made available in delegated mode! What does it mean and how does it work?

Read more
Running .NET Function Apps or App Services accessing Microsoft 365
Running .NET Function Apps or App Services accessing Microsoft 365

A guide on how to create a .NET application that can access SharePoint and the Microsoft Graph through Entra ID.

Read more
Getting notified of changes in guests accessing SharePoint
Getting notified of changes in guests accessing SharePoint

Part 3 on how to use the CLI for Microsoft 365 and Azure Functions: How to get notified of updates in guests accessing SharePoint.

Read more

Thanks

Thanks for reading

Thanks for reading my blog, I hope you got what you came for. Blogs of others have been super important during my work. This site is me returning the favor. If you read anything you do not understand because I failed to clarify it enough, please drop me a post using my socials or the contact form.


Warm regards,
Martin

Microsoft MVP | Microsoft 365 Architect

Microsoft MVP horizontal