Restrict permissions to app-only Azure AD applications consuming Office 365 services on resource level
Large organization start leveraging the Graph API to provide integrations between their third party applications and Office 365. In such companies it is common to delegate the development of integrations from the central IT organization to other business units.
The current app-only permission priviledges are not appropriate for such types of setups since there is currently no way to limit the permissions for that app to a specific resource in Office 365. This makes such use cases impossible to implement.
As an example we could consider SharePoint Online. Whever a business unit has to develop a daemon tool that exchanges data between their third party system and a SharePoint Online resource (a subset of site collections, an individual site, even a list), this cannot be done without granting them access to all SharePoint resources of that organization. This is because app-only permissions for an application are considered as an "all or nothing" type of permission for that application.
You could take a similar example with Exchange Online resources. Also in that specific case there is no way to limit the permissions to individual mailboxes.
These are the ways to implement such type of scenarios:
- Fallback to the "classic" api and authentication model (in SharePoint addin development). This has the drawback of not leveraging the Graph API. Furthermore, this type of application is unaware of conditional access mechanisms, making it a possible security thread for such organizations.
- Create a cloud identity and an application with delegated permissions. Grant to this cloud identity the necessary rights to the desired resource and then authenticate against the environment with username, password + app. This has the disadvantage of higher complexity and the need to use cloud identities, since federated identities are not working in such a scenario. The usage of a service account is also not ideal
Would be awesome to obtain a way to limit such types of applications on resource level. In theory, you could also only request an "admin consent" in case an application really requires access to all SharePoint Online resources. For such types of scenario an admin consent is not necessary required as long we are ensuring the application has access to specific resources only.
Work has started. This feature is currently in preview for certain Teams resources with the name “resource-specific consent” (RSC).
Admin documentation: https://docs.microsoft.com/en-us/MicrosoftTeams/resource-specific-consent
Developer documentation: https://docs.microsoft.com/en-us/microsoftteams/platform/graph-api/rsc/resource-specific-consent
We intend to continue adding support for additional resource types in the future (e.g. SharePoint content), but we have no ETA to share at this time.
It appears SharePoint Site Collection level permissions "Sites.selected" for applications is now in preview.
I note some kinks at the time of writing, e.g. driveitem resumable upload links created under this permission always respond with http error 403, Access denied.
Philippe Fontan commented
From what I understand, this has been implemented for Mailboxes through the use of the *New-ApplicationAccessPolicy* PowerShell cmdlet. It allows an app to have full Application Permissions (which IT admins don't like) and restrict those permissions to a specific set of mailboxes (which IT admins love!) by setting up a policy. Granted, there is a limit of 100 policies per tenant, which could become problematic at some point, but it's a step in the right direction.
I'd like to see the same kind of cmdlet made available for OneDrive and SharePoint.
This would allow our internal daemon to automatically pick-up/deposit files in each of our users' OneDrive, without the daemon having access to all files in all folders.
Use case #1
All of our employees may submit expense reports. For reasons that are too long to explain, they must fill out a standardized Excel sheet which they then send to our Accounting department (some via email, some through Teams, some via a shared folder on the network... it's a mess!)
I want to be able to tell all our users: save the Excel file to your OneDrive under a folder named Expenses. Our daemon will automatically pick it up and forward it to the accounting Department.
Use case #2:
Similarly, I want our Sales reps to get the new price list for our products (each price list varies from one country/region/individual to the next). When we send it via email it often gets "lost" in the Rep's inbox (meaning they deleted it without thinking! :P ).
If our daemon could automatically deposit it in each rep's OneDrive, it would make things so much easier.
Mark Rullo commented
This appears to be on the roadmap for January, but it's Feb. now.
Can you please provide an update on how this is going for SharePoint?
I cannot vote since the JS errors (in FF) so I'll just leave a comment.
A Ismaili commented
Yes, and NOT ONLY FOR APP-ONLY, but also for delegated permissions!
We have e.g. many developer teams and we don't want to give them control over the whole tenant.
Currently, we can control in a way that a site owner can only grant them access to only her/his site by custom app authentication in SPO.
Before e.g. disabling this Custom App Authentication (see https://www.koskila.net/literally-breaking-changes-to-app-authentication-on-sharepoint-%F0%9F%98%B5/) in the future and expecting that MS Graph is the replacement, MS Graph MUST provide a similar way to restrict App permissions on single sites or M365-groups only.
Please, another point for this. Need for sharepoint and files to upload.
I second the previous comment regarding the ability to give an appID restricted access to the GroupMember.Readwrite.All scope. Do we know if this is in scope in any of the pending roadmap items?
I have a requirement to develop a web/daemon app that manipulates the member ship of specific AD groups.
Currently it seems to only be possible to give an app access to write the membership of all AD groups. (Or none at all)
Strangely this is not a popular idea with our AD admins.
Users can be given this access to specific AD groups by making them the owner.
You can even make an App’s managed identity the owner of an AD groups, but there seems to be no way to join the dots to give the app restricted access to the GroupMember.Readwrite.All scope.
So I may have to resort to a service account and username/password credentials to work around this.
We have a problem with the Sharepoint Framework project permission. Now SPFX Web part needs Tenant (AllSites) Permission only.
when will be ETA for Sharepoint Online?
I have recently hit this problem with MS Graph permissions and would love to hear about any updates that the Microsoft team have in this area of development.
This would be very helpful. Any update on when we can expect this feature?
It's been more than a year, please provide a status update.
Just for the sake of argument, wouldn't it be a far nicer experience if App-Only principles could fall under the regime of Conditional Access policies, just like regular users and groups? This has been suggested here as well: https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/37867180-restricting-access-of-azure-service-principals-u
This would mean that if a SharePoint site has the BlockAccess policy setting enabled and the App Principle falls under the scope of a CA policy that the access will be blocked.
Mark Davidson commented
+1 on feedback for this once again. It'd be good to at least know whether this is still the direction of travel or if there has been a change of plan.
Any update on this feature @Jackson.woods?
Bhavya Vootla commented
+1 on feedback for this request please. Clearly an important feature.
James Corbishley commented
Hi Jackson, is this something that has been integrated into the Graph API yet?
Many thanks for your time, James
Chukiat B commented
Any progress? Need site collection admin consent instead of tenant admin consent for specific site collection permission.
Anthony White commented
What's the roadmap for this? Very much needed...