Skip to main content
  • EN

I’m having a workspace with some connections to files that are on sharepoint. I did create the correct setup with the web connections to have a sharepoint account with client & tenant id etc in it.

 

workspace works fine at my side, but the account that was provided is an account that has access to a lot off stuff.

When I want to share the workspace with production so that they can run it, they also need to have the webconnection present in their workbench to get it to work (otherwise sharepoint online connector turns red etc).

With this they can actually access more files than what is stricly needed (even though my workspace is password protected, nothing stops them from using that account for fetching different files) and this may lead to security issues.

Although using a account with limited access to files on sharepoint would also help, I’m wondering if there is a different way to access files from sharepoint?

 

I’m comparing it a bit with database connections:

  • Connections are convenient if you don’t need to share or everybody has the same rights and you can share the connections
  • If you don’t want to share you fall back to embedded details (hidden as private paramters). 

I’m kinda looking if there is also an “embedded” option for sharepoint

Hi @tva, if you are trying to connect to a SharePoint server (not SharePoint Online) and read/write list data, you may be able to use basic authentication in the SharePoint List Reader/Writer (If the SharePoint server allows it).

Otherwise, yes you’d need to use a web connection. But, there may not be a reason for concern. Microsoft currently uses the OAuth2.0 authorization code flow, which is a standard authentication flow used by websites. It’s quite different than connecting to a database. There are no user credentials stored; the credentials are only used to authorize the app to act on behalf of the user. Then, a short-lived access token is used. So there isn’t a way to implement an embedded option. Here is Microsoft’s documentation:

https://learn.microsoft.com/en-us/graph/auth-v2-user?tabs=http
 

When a users authorizes the connection on their machine with their SharePoint credentials, the token that gets created only has access to the resources that user has access to in SharePoint. For example, see description for the delegated permission files.readwrite.all from Microsoft: https://learn.microsoft.com/en-us/graph/permissions-reference#filesreadwriteall

 

To make sharing somewhat easier, you can export the web service you created with your client id and share it with other FME Form users. They can then import it and create their own web connection with it, authorized using their SharePoint credentials.  

Edit: added more MS doc links.

Hi @mattmatsafe,

Shouldn’t it be possible to put the logic from the web connection behind the scenes in the transformer. So that you either provide the web connection or client id/secret & tenant. if it’s web connection → works as is. If it’s the other options are provided, that the authorization happens on the fly?

 

I’m not keen on share the web connection because I only have a super user connection which I don’t want to share to operations who should normally have their limit read only user (but IT doesn’t want to create this for me 😞 ) 

Hi @tva, the Oauth2.0 process used by Microsoft requires more than just the ClientID and Secret, other settings may need to be configured in the underlying web service for a customer’s environment (for example, different URLs depending on tenancy).
A user won’t be able to use the web connection you authorized with your super user credentials, though. They will need to first authorize it with their credentials in FME Form. Sharing a web connection won’t share your super user privileges in SharePoint.

Reply


Community Stats

30,351
Posts
115,342
Replies
38,083
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.