Hi team,
In order to make sharepoint connector work in easymorph, what do we have to implement on microsoft side in terms of scope ? Is it sharepoint scopes or is it graph api scopes ? What are you using in terms of API ?
My guess is that you are using sharepoint API. In that case what do you think about this link saying that graph API should be used ? SharePoint API vs Microsoft Graph API? - Microsoft Q&A
Alteryx seems to use graph API 
Thanks
Hi!
The required scopes you need to enable depend on your intended use for SharePoint. You can see the scope names in the connector window by hovering your cursor over the question mark:
AFAIK, AllSites.FullControl is the only scope that requires explicit admin consent in Azure AD. The other scopes do not require you to enable them on your end, and your users can use EasyMorph SharePoint without requiring administrator approval.
What are you using in terms of API ?
We use Microsoft's SharePoint CSOM library, which does not use either SharePoint REST API or Graph API. Unfortunately, it's not possible to switch Micorosft's CSOM library to use Graph API since they are very different in nature (CSOM is stateful).
As you may know, Easymorph, like any other app using Azure needs an explicite authorization in Azure portal including authorized scopes. Can you send a print screen of the scopes you have defined in your own testing azure tenant in order to authorize easymorph to interact with SPOL ?
Edit : seems I was initially right Episode #87 - Consuming SharePoint Online using CSOM, MSAL, and OAuth - YouTube
Easymorph needs to be registered first, then the necessary API permissions must be set at sharepoint level, even for CSOM library. You must have done that once to test it. You really should document all these steps or no one will be able to use power bi or SPOL connectors.
The full extent of the testing tenant’s scopes is AllSites.FullControl, AllSites.Manage, AllSites.Read, AllSites.Write, EnterpriseResource.Write, MyFiles.Read, MyFiles.Write, Project.Write, ProjectWebApp.FullControl, TermStore.ReadWrite.All.
But I really don’t think you’ll need to authorize all these scopes.
UPD The youtube video you posted is referring to creating a custom app registration for use with SharePoint. As this may not have been clear from previous messages, all of my responses have been about using the SharePoint connector with the default EasyMorph Azure App registration.
If you are actually creating a custom app, then you are correct in saying that you will need to specify all the scopes explicitly.
I think thats exactly the same when you want to consent easymorph app. The video also applies, whatever the app is. I will implement this on my side and give you a feedback.
I may be mistaken, but according to my understanding, by default if a user authorizes our existing app in the tenant, the tenant administrator may not need to grant consent unless the user asks for scopes that specifically require admin approval.
That behavior, however, is configured in the tenant, specifically in Azure Active Directory > Enterprise applications > Consent and permissions > User consent settings. There is a “User consent for applications” selector with a default setting of “Allow user consent for apps”, which corresponds with the behavior described above.
However, there is an option to set this selector to a more restrictive setting, such as “Do not allow user consent”. If this configuration is enabled, administrator consent is required for all attempts to grant permissions to the application.
Hi again,
Here is how it can work inside a big company like mine and what you can do about it.
First my administrators have disabled user consent for apps and even admin consent for apps. So everything is blocked by default including easymorph app. It means that everytime I want to use Microsoft on line connectors I get an error message by default.
If you want to approve easymorph app, then you can enable temporarily admin consent and get easymorph app id through requests. That’s what an azure admin can do. At this point an admin can grant a permanent authorization to the app but it’s including ALL the scopes exposed by the app and there are a lot. It’s highly probable that an admin would not accept all scopes from Easymorph. What an admin can do though : remove all scopes related to an API, like for example remove all scopes used by sharepoint connectors and keep all others. In this case of course you will not be able to use sharepoint actions. Note that in this configuration you can NOT decide to keep part of scopes and remove others for each API : it’s everything or nothing.
The other way to proceed is to register your own azure app with a dedicated id. Easymorph microsoft on line connectors enable to use your own app id instead of easymorph id. In this configuration, an admin can choose the scopes to authorize. When you define your app in “delegation mode”, the app will always use the end user credentials to do things which is better. So even if you include “create folder” scope for sharepoint in your dedicated azure app, the user will not be able to create folder if he does not have access to the sharepoint site.
Then what you can do is to create a service account with a dedicated azure email. You create your power bi, sharepoint or other connectors using your app id, tenant id (easy to get) and you authorize your connector using the service account. In the desktop it will create an embedded token but that’s not what you want. You will want to publish your connector on the server and then be able to run tasks with that service account. You will NOT want to publish such connector to end users as the service account would be used by them and auditability would be broken.
In the desktop the token of the service account lasts 90 days but the good thing is that when you share your connector through easymorph server, the token is implicitly refreshed each time you use it. So you don’t have to renew your connector authorization every 90 days.
In case when you have multiple teams, each one having a dedicated workspace like in our configuration, you can still try to create a dedicated service account to your team. Then you would be able to convince your security guys that users can use your shared connectors if each shared connector is authorized with the service account dedicated to the team. It’s not the best for auditability but still better than use one single service account for everyone. You can even decide to create service account by team AND API, like for example one service account for human resource team using sharepoint.
I tried to summarize something that is not obvious at all. Documentation about all of this would be greatly appreciated. Now I can work with sharepoint commands and oh my god, it’s changing my life
