Graph API Scope 'Sites.Selected' should include read/write to selected site's lists

Graph API Scope 'Sites.Selected' should include read/write to selected site's lists
4

Upvotes

Upvote

 Jul 12 2021
11 Comments (11 New)
New

Scenario and Result

My app has been given read/write permissions to a customer's Site. My app can read and write items in the selected site's default document library, which is as expected.

But it excludes the ability to read and create lists for the selected site; reading and creating lists should be included.

 

Technology

- Graph Explorer

- msgraph-sdk-dotnet (Microsoft.Graph.Core version: 1.24.0.0)

 

Reproducible steps

 

  1. Register an app in Azure AD with "Sites.Selected" Graph API applications, not delegated, permissions. Ensure the UX app, which is integrated with msgraph-sdk-dotnet, successfully gets access token to this AD app.
  2. Use UX app to get customer's tenant ID to accept this AD app and its permissions (which is the required User.Read, and added Sites.Selected).
  3. Sign in on Graph Explorer under customer's tenant to grant read/write permissions to this AD app. e.g. POST https://graph.microsoft.com/v1.0/sites/<site-id>/permissions

 

{
    "roles": [
        "write"
    ],
    "grantedToIdentities": [
        {
            "application": {
                "id": "<AD app id>",
                "displayName": "Jenny limited permissions"
            }
        }
    ]
}

 

 

4. Use the UX app to confirm it has access to the selected site, e.g. Site object returned successfully from

 

await graphServiceClient.Sites[siteId].Request().GetAsync()​

 

 

5. Use the UX app to confirm it can write items to selected site's default document library by ensuring the operation can be run with no exceptions, example code

 

var newFolder = new Folder
{
   Name = "Test folder",
   Folder = new Folder()
}
await graphServiceClient.Sites[siteId].Drive.Items.Request().AddAsync(newFolder)​

 

 

6. Use the UX app to try to create lists, example code

 

var newList = new List
{
   DisplayName = "new document library",
   ListInfo = new Info
   {
       Template = "documentLibrary"
   }
};

await graphServiceClient.Sites[siteId].Lists.Request().AddAsync(newList);​

 

 

Expected behaviour
A document library called "new document library" for the selected site gets created.

Screenshots
Actual behaviour: Access Denied error exception when executing that operation

121990620-6756a780-cde1-11eb-849f-3235b73e5941

 

This scenario has been reported in the msgraph-sdk-dotnet github repository and they have confirmed this idea has to be done within Graph API so the wrapper can then support it.

https://github.com/microsoftgraph/msgraph-sdk-dotnet/issues/1047#issuecomment-873867323

 

More information about the Site.Selected permission:

https://developer.microsoft.com/en-us/graph/blogs/controlling-app-access-on-specific-sharepoint-site-collections/

 

Comments
Occasional Visitor

Also, there should be documentation on what's possible to do with the Sites.Selected permissions.

Frequent Contributor

I agree with @jennynguyen114  and have upvoted (hopefully others will too), creating sites should be included in the capabilities for a Sites.Selected holding app which has been granted the Write permission on a site.

 

Also agree with @allanhelbling that the reference material for Graph should list Sites.Selected as a suitable permission for every method that supports it.  It's a huge mystery right now, and finding out the hard way what won't be possible is nothing short of annoying, no matter how nice it was that we were blessed with this great feature.

Frequent Visitor

> creating sites should be included in the capabilities for a Sites.Selected holding app which has been granted the Write permission on a site.

@Jeremy Bradshaw, did you mean creating document libraries here?

Thank you for upvoting this.

 

I also agree with @allanhelbling about more documentation. Also thank you for the upvote.

Frequent Contributor

@jennynguyen114 I in fact meant lists, not sites, but lists and document libraries both would be nice.  For me, I use lists like spreadsheets in place of CSV or XLSX with my PowerShell scripts.  It's great, but with Sites.Selected only being able to deal with existing lists, it's a little limited right now.

Occasional Visitor

Read or write roles are not adequate to create document library, that's why you need 'fullcontrol' permission.

You would ask "How to add it given that the API doesn't accept it while creating permission?", well there is a workaround when you create a permission with 'read' or 'write' role and then use patch (against permission ID) to change the role to 'fullcontrol'.

This probably should be better documented by Microsoft, but at least there is a way to make it work with 'Sites.Selected' scope.

Frequent Contributor

@Relair That is some good info.  Thanks for providing.  By "better" documented, I assume there must be some documentation that covers this point you've shared.  Is there anywhere you can provide a link to or did you find out through insider circles?

Occasional Visitor

Well, there is documentation for the site permission resources: https://docs.microsoft.com/en-us/graph/api/resources/permission?view=graph-rest-1.0, there is no mention of 'fullcontrol' role there. They do mention 'owner' role though, I wonder if that would work as well and without the workaround I've mentioned.

New Contributor

@jennynguyen114 @Jeremy Bradshaw 

To expand on the suggestion by @Relair See this blog post explaining how to add the 'fullcontrol' role to your Sites.Selected permission, using PowerShell. I have verified that this allows creation of lists.

https://www.leonarmston.com/2022/02/use-sites-selected-permission-with-fullcontrol-rather-than-write...

 

This doesn't appear to be documented under existing documentation for the new Sites.Selected permission but it's obviously an import requirement.

Frequent Contributor

Thanks very much @johnnycardy , and especially for covering the ins and outs of how to get the FullControl permission set in your blog post.

 

I will take the time to ask since you showed that you're using the PNP module in your post.  Are you considering dropping that and going with the Microsoft.Graph.Sites module instead anytime soon?  I was/am using my own MSGraphPSEssentials module for all my SPO interaction from PowerShell, and am about to convert to the official module.  I purposely avoided PNP, mostly because my use cases for SPO in general is a short list and I was looking to prime myself on direct MS Graph consumption anyway.  But still wonder what experts like to use.

New Contributor

@Jeremy Bradshaw Apologies - I didn't meant to mislead, but I am not the blog author. Thanks for alerting me to the Microsoft.Graph.Sites module, I wasn't aware of it. The PnP modules are generally well regarded but it's good to have proper native support for these use cases.

Occasional Visitor

Personally I use Graph Explorer. Graph Explorer needs to have added Sites.FullControl.All delegated permission to control site permissions, but it's easy to login there and use once that's handled. Easiest way to setup that permission is to set route that doesn't exist on graph API and then in Modify Permissions select the permission from Open the permission panel link. Even if you're not an admin of the tenant you can request permission to be approved by one, so that's nice.