feat: experimental transfer sharepoint authentication to AzureAD

[mateuszkuprowski]

Refined authentication method to get rid of deprecated login/password with sharepoint client in favour of EntraID auth.

[bryan-unstructured]

should we provide with a value for permissions_client_cred and permissions_application_id here? otherwise this integration test would fail in CI pipeline

[mateuszkuprowski]

It won't actually fail (and it doesn't) as this connector can work in 2 modes, either with or without permissions. There's a separate e2e test for that in the test_e2e/dest/sharepoint.sh and sharepoint_with_permissions.sh

[bryan-unstructured]

when I use SHAREPOINT_PERMISSIONS_TENANT value in Keeper, this line reports an error. After I remove the second part of the string and only keeps the first part, it works.

[mateuszkuprowski]

I might need a little more explanation on this not sure which part do you mean? Like it works without the /.default/ but it doesn't with it?

[bryan-unstructured]

I've taken the route of minimal changes to the whole structure. I've been reading and experimenting a bit and came up with this solution. It feels elegant and should cover what we need - changed the authorisation method without changing the whole code structure. The doownside of this is that tenant_id which is required when using sharepoint's REST API had to be taken from permissions, which is fine for tests, but we'd have to ensure that it works correctly with entire system via UI as well. Hence I'm asking for you opinion - can we stick with it as is or should we maybe create separate parameter for tenant_id besides permissions? That'd most likely duplicate which isn't ideal either, but would have to be this way since permissions are using graph api instead of REST api that has different capabilities.

on the platform UI, what's differences between permissions and AccessConfig? Aren't both of them shown on the UI?

[mateuszkuprowski]

I've taken the route of minimal changes to the whole structure. I've been reading and experimenting a bit and came up with this solution. It feels elegant and should cover what we need - changed the authorisation method without changing the whole code structure. The doownside of this is that tenant_id which is required when using sharepoint's REST API had to be taken from permissions, which is fine for tests, but we'd have to ensure that it works correctly with entire system via UI as well. Hence I'm asking for you opinion - can we stick with it as is or should we maybe create separate parameter for tenant_id besides permissions? That'd most likely duplicate which isn't ideal either, but would have to be this way since permissions are using graph api instead of REST api that has different capabilities.

on the platform UI, what's differences between permissions and AccessConfig? Aren't both of them shown on the UI?

Unfortunately there's no permission config to be setup in the UI. All I need is tenant for this to work. Actually you indirectly input a tenant when you give link to the proper site, I was wondering if simple copy that info to tenant wouldn't work. In tests it's exactly like that.