Securing SharePoint and Teams Integration with 3rd Party Applications using Microsoft Graph's Sites.Selected Delegated Permission in Enterprise Environment

In today's ever-evolving digital landscape, the need for seamless integration between Microsoft SharePoint, Microsoft Teams, and 3rd party applications has become paramount. This integration plays a vital role in fostering efficient collaboration and enhancing overall productivity. However, we cannot overlook the challenges that arise when it comes to ensuring the security and compliance of these integrations.

As the Microsoft 365 landscape continues to evolve, with the introduction of developments like Copilot and other AI tool, it has become even more crucial to address concerns such as oversharing and data security. In this blog, I aim to shed light on these pressing topics and provide valuable insights based on my own experiences.

With the availability of multiple options for implementing integrations and collaboration between 3rd party applications and Microsoft 365, it is essential to choose the best method for your specific implementation. By carefully considering the security and compliance aspects, we can ensure that our solutions not only meet our business needs but also adhere to industry standards and regulations

In this article, we will explore one of the possible ways to integrate 3rd party applications with Microsoft 365 using Graph API. Microsoft Graph is a single endpoint that provides access to data and services in the Microsoft cloud. It exposes REST APIs to access data on Microsoft 365 services like OneDrive, Outlook, SharePoint, Team, etc.

Undersetting about Authentication and authorization

Authentication and authorization are critical when it comes to calling Microsoft Graph. Your application should first generate an access token from the Microsoft identity platform. Access tokens will contain information allowing to validate the caller and to ensure that the caller has proper permissions to perform the operation requested. There are different types of permissions, including application and delegated, and you should choose the most suitable approach for your needs.

There are three methods to integrate with SharePoint using Graph API.

For all other scenarios and details, you can visit Graph documentation. 

 

Comparison of delegated and application permissions

 

	Delegated permissions	Application permissions
Types of apps	Web app / Mobile / Single-page app (SPA)	Web / Daemon
Access context	Get access on behalf of a user	Get access without a user
Who can consent	Users can consent for their data Admins can consent for all users	Only admin can consent
Other names	Scopes OAuth2 permissions	App roles App-only permissions Direct access permissions
Result of consent	oAuth2PermissionGrant	appRoleAssignment
Supported signInAudience types Description Scenario Advantages	AzureADMyOrg  AzureADMultipleOrgs  AzureADandPersonalMicrosoftAccount  PersonalMicrosoftAccount The app acts on behalf of the signed-   in user and can access the same resources and perform the same operations as the user A web app that allows users to view and edit their own SharePoint documents The app can provide a personalized and interactive user experience. Data access only where user have permissions (ex, Delve or copiloit)	AzureADMyOrg AzureADMultipleOrgs AzureADandPersonalMicrosoftAccount The app acts on its own without a signed-in user and can access resources and perform operations based on the app roles A background service that performs automated tasks on SharePoint data he app can access data without user intervention and consent

 

Complete details https://learn.microsoft.com/en-us/graph/permissions-overview?tabs=http 

Implementation Methods 

Method 1:  Tenant Level site collection access with Sites.readAll or readWriteAll 

Sites.readAll or readWriteAll permissions. This method is not recommended as it grants highly privileged permissions to a service principal, meaning a service principal could literally read any site on your tenant. This approach poses a high risk of data leakage if the client ID and secret leak, as a hacker could read complete tenant data without knowing users and the organization.

 

Risk level: High

Method 2:  Site Collection Level 'granular' Permissions -with Application

Sites.Selected with Application Graph Permissions. This method allows you to assign different permissions to apps based on the site collection they need to access. This way, you can reduce the attack surface and the risk of data leakage for the complete tenant while still enabling secure and seamless integration with third-party apps. However, this approach has a medium risk level as the Graph API application access means the app can access resources and perform operations without a signed-in user (app can access resources and perform operations without a signed-in user ). Technically, for any 3rd party integration, the customer should provide a client ID, secret or certificate with the 3rd party. So, the 3rd party application has full control over the particular site content, including encryption and strictly confidential data.

Risk level: Low Medium

Technical Implementation.

Microsoft graph now provides option to have granular permissions level using Sites.Selected application permission for the AD application instead of granting permission for all the sites in the tenant. The permission Sites.Selected does not provide access to any SharePoint site collections for the application unless the AD application has been assigned with permission roles read or write by an Admin. On this post let us see how to grant a site permission (Read or Write) to an AD Application with Sites.Selected permission by using postman client.                                                                                                                                         For the full details  Controlling app access on a specific SharePoint site collections is now available in Microsoft Graph - Microsoft 365 Developer Blog

Method 3 : Site Collection Level 'granular' Permissions -with Delegated 

Sites.Selected with Delegated Graph Permissions (In Preview). This method works exactly the same as Method 2 but with delegated permissions. It means we can assign different permissions to apps based on the site collection they need to access with a delegated approach. This method provides enhanced security as it reduces the risk of data leakage and provides more control over data access.

Update : MS Document SharePoint now supports delegated Sites.Selected authentication (microsoft.com) 

Risk level: Low

Technical Implementation.

To activate token authentication, you need to have an app registration. This document provides a detailed guide on how to activate token authentication and grant permission to an AD app in Azure Active Directory. It covers the steps involved in app registration, platform configuration, and granting admin consent. The document also includes information on using PnP PowerShell cmdlets to grant access to a SharePoint site and register an AD app. Follow this guide to learn how to set up token authentication and enhance the security of your application.

Create an App in Microsoft Entra 

Within the app registration, you will find the topic "Authentication" in the Menu on the left side (under "Manage"):

At the very top you will find the platform configurations. Click on "Add a platform"

Choose the application platform (depends on the application. In my test I chose "Web"):

In the configuration tab, enter the respective infos (in my scenario the redirect URI for the authentication responses --> tokens) and also select, the types of tokens to allow (so access tokens, ID tokens or both). Hit Configure to submit.

Now you need to adopt the following link:

https://login.microsoftonline.com/{tenant id}/oauth2/v2.0/authorize?client_id={app-id}&response_type=token&scope=https%3A//graph.microsoft.com/Sites.Selected

Note : Change the {tenant id}  and the {app-id} with your tenant ID (can be found at the main page of Entra in the Azure portal) and your application ID (can be found on the main page of your app-registration).

Sample : https://login.microsoftonline.com/9d66ab4f-475c-4fd6-a9a0-2613da2f5833/oauth2/v2.0/authorize?client_id=f4b3d77b-8c0d-419b-ada0-ac97ffedc9d1&response_type=token&scope=https%3A//graph.microsoft.com/Sites.Selected

You will be prompted for the application permissions. Check if the application name is correct, then tick the box for "Consent on behalf opf your organization" and click "Accept".

We need to do the consent as global admin and activate the check box "Consent on behalf of your organization". The users will not see any consent prompt. while accessing application.

After providing admin consent, you can find your application in  Enterprise applications section. 

Quick test with Postman: 

Grant Write permisisons to single site collection, to grant permissions, we have multiple ways, for short I used PNP method like menthid 2.  

Grant the Role using PnP PowerShell:

There is a PnP PowerShell cmdlet to grant access to SharePoint site for the registered AD application with Sites.Selected permission. The command to grant permission can be executed by the Site Collection administrator after creating a connection to the site

Connect-PnPOnline https://Test.sharepoint.com/sites/test -Interactive

You will be prompted to enter credentials including the second factor. After the connection is created, enter the following command to grant Write permission to the AD App

Grant-PnPAzureADAppSitePermission -AppId 'AzureAppIdwithSitesdotselectedpermission' -DisplayName 'App Name here' -Site 'https://Test.sharepoint.com/sites/test ' -Permissions Write

for other methods, please refer  Mohamed Blog

Once we grant permissions to single site collection, 

Copy the access_token from the browser like below. if you want generate again new token, copy this command in your browser.

https://login.microsoftonline.com/9d66ab4f-475c-4fd6-a9a0-2613da2f5833/oauth2/v2.0/authorize?client_id=f4b3d77b-8c0d-419b-ada0-ac97ffedc9d1&response_type=token&scope=https%3A//graph.microsoft.com/Sites.Selected

Paste the access token on the token box as shown below with Authorization type selected as Bearer Token

Send the request for granting the role for APP 1. After the request is made the APP 1 with the Sites.Selected permission has access to the site with write role we have granted to. The same way you can assign app access to multiple SharePoint sites.

https://graph.microsoft.com/v1.0/sites/test.sharepoint.com:/sites/test

Reference : 

https://learn.microsoft.com/en-us/graph/api/site-post-permissions?view=graph-rest-1.0&tabs=csharp

https://learn.microsoft.com/en-us/graph/permissions-overview?tabs=http 

Conclusion:

In conclusion, integrating 3rd party applications with SharePoint using Graph API requires careful planning and consideration of security risks. By choosing the appropriate method and following the recommended steps, you can ensure that your sensitive data and resources remain secure and compliant.

SharePoint Server Subscription Edition Installation with minimize expenses

 

I created my farm using the guide found on this page: SharePoint Server 2016 dev/test environment in Azure - SharePoint Server | Microsoft Docs

 

However, I did a bit of adjustment of the VM creation scripts to accommodate the following:

1. Using new versions of Windows Server, SQL Server and SharePoint Server which are aligned with new system requirements for SharePoint Server Subscription Edition
1. Windows Server 2022
2. SQL Server 2019
3. SharePoint Server Subscription Edition
2. Adjusting VM size based on my other test farm (SP2016+19) to minimize expenses

 

I also configured auto-power-off for all VMs so that they will be shut down automatically at 7PM if they are on (that is done in the Azure portal).

 

All of the four changed PowerShell segments are attached in the compressed zip file. The rest of the process stays the same like described in the document above.

Download Scripts: Scripts

Issue with exporting PowerApps solution In default environment

 

Issue:

We are facing issue while exporting a power apps solution from default environment "ABC". Error attached below.

Solution "ABC" failed to export: Principal with id e96d176f-3487-eb11-a812-000d3ab52d2a does not have ReadAccess right(s) for record with id 21b01452-9f7d-ec11-8d21-000d3a66509a of entity workflow. Details: {"CallerPrincipal":{"PrincipalId":"e96d-a812-000d3ab52d2a","Type":8,"IsUserPrincipal":true},"OwnerPrincipal":{"PrincipalId":"3ee8fac0-3687-eb11-a812-0d2a","Type":8,"IsUserPrincipal":true},"ObjectId":"21b01452-9f7d-ec11-8d21-000d3a66509a","ObjectTypeCode":4703,"EntityName":"workflow","ObjectBusinessUnitId":"7581668f-6f11-e911-a99d-000d3ab78b73","RightsToCheck":"ReadAccess","RoleAccessRights":"None","PoaAccessRights":"None","HsmAccessRights":"None","GrantedAccessRights":"None","Messages":["PrincipalHasOwnerPrincipalWithAtLeastBasicPrivilegeDepth = False","EntityUserGroupRights = None","MinimumPrivilegeDepthRequired = Local","SecLib::AccessCheckEx2 failed. Owner Data: User principal 3ee8fac0-3687-eb11-a812-000d3ab52d2a is not loaded in UserDataCache yet; Principal Data: roleCount=6, privilegeCount=1538, accessMode=0"],"EntityOwnershipTypeMask":1,"CallerInfo":{"IsSystemUser":false,"IsSupportUser":false,"IsAdministrator":false,"IsCustomizer

Resolution:

Based on the below error ,  it seems that the solution contains a flow not owned by user https://ABC.crm4.dynamics.com/api/data/v9.1/systemusers(e961-a812-000d3ab52d2a).

 

So based on information provided here: Security roles and privileges - Power Platform | Microsoft Docs, Local would be the minimum security role access level required for allowing to successfully export the solution

To resolve this issue, please take the following steps:

An environment admin should browse to the Power Platform Admin center https://admin.powerplatform.microsoft.com 

1.       Select the environment(s) with this issue

2.       Click Security Roles > See all

 

 

Select environment maker role and select Edit

Click the Customization tab

 

 

 

In the grid of circles, enable Read permission on the Process row to Business unit level of permission .

SPFx Form Customizer Extension To Customize SharePoint New/Edit/Display Form Of List/Libraries

Microsoft has recently released SPFx 1.15.1 Preview version adding a few new features and updates for building SPFx-based solutions. We can find full release notes at the link. With this release we can customize complete SharePoint list form using. SPFx full blog with example.

https://www.c-sharpcorner.com/article/spfx-form-customizer-extension-to-customize-sharepoint-neweditdisplay-form-of/

Change the owner of cloud flow

https://docs.microsoft.com/en-us/power-automate/change-cloud-flow-owner

https://powerautomate.microsoft.com/sv-se/blog/team-flows/

ALM Accelerator for Power Platform - Pros & Cons

 Microsoft released another innovate tool to Manage Power Platform (Canvas & Model driven) Applications using Application Life cycle Management(ALM)

Ste by step guide : https://powerapps.microsoft.com/en-us/blog/introducing-the-alm-accelerator-for-power-platform/ 

My first Impression with ALM

ALM Accelerator is tightly coupled with Azure DevOps & git, but there no link between recent relese features like CO- Authoring features, So by end citizen developers should maintain 2 git repos for store same solution.

Setup & maintenance complexity is same like earlier version. this tool is good fit for small originations not for Enterprises.

Co-Authoring in Power Apps - Limitations

Microsoft released many new features in Power Platform in 2021, there are 2 main features are very useful for developers. 

Co-Authoring as an experimental feature to Power Apps.

Co-Authoring as an experimental feature to Co-Authoring in Microsoft Teams. 

Co-Authoring in teams lets you edit a document while another person is editing the same document.

With Power apps it is just the same. You can edit one app with multiple people at the same time.

Be aware though that enabling Co-authoring is more than just enabling a feature. When multiple people edit the same app, it is very important that you use the same standards and that you are aware of which parts each person is working on. like Standard development / release Life-cycle using Version controls (Gits or Devops)

Saving your work on a regular basis, and collecting other people’s changes regularly might be a good idea.

Based on documentation, I tested in both Azure DevOps & git repos. found few bugs in additions limitations. 

https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/git-version-control.

Steps Followed:

1. Created Github Repository
2. Generated a personal access token for my ID in github
3. Created a canvas app and connected it to Github repository
4. Provided github repo and canvas app access to another user
5. User needs to generate a personal access token for himself
6. Edit the app and other user must provide his github credentials

Now both users can edit and work on the app simultaneously

Known limitations

1. This feature isn't compatible with code components. Don't use this feature with apps that make of use of code components.
2. This feature doesn't work with public Git repository. Use a private repo instead.
3. This feature doesn't work with on-premises Git repositories. The Git repo must be hosted on the web and accessible with username and personal access token.
4. Edits to the same property on the same control aren't merged. The last edit made will win.

Additional findings :

Co-authoring feature is not working for Dataverse & SQl  tables, but SharePoint works fine without any issue.