Symptoms
When executing a SmartObject that is supposed to get data from a list in a SharePoint 2013 site collection, the following error kept on popping up:
The remote server returned an error: (401) Unauthorized.Failed to initialize the Context:
URL: https://cloud-crm.domain.org/country
Username:
Error Details: Method: SharePointService.initializeContext
x-ms-diagnostics : 3001000reason='There has been an error authenticating the request.'category='invalid_client'
SPRequestGuid : eeb2209d-ee53-2079-a29b-93f0655d6a73
This usually happened on a SmartForms page, however we could reproduce this error by executing the SMO in the SmartObject Service Tester Tool.
Diagnoses
After a lot of digging around in the User Profile Sync service to check if it's configured correctly, making sure the user has the correct access permissions in the SharePoint site collection, to checking the user properties in the "/Runtime/AuthTest.aspx" page in SmartForms and comparing that to the ADFS configuration, to checking how the user logs in to SharePoint by either using the UPN or the Email address, we eventually found that there was not a separate K2 Security Label for ADFS. We used the default "K2" security label to login with ADFS, however it turns out you have to create a separate ADFS security label.
Resolution
So in order to resolve this issue we had to create a new LDAP security label using ADFS configurations and named it K2ADFS. We modified the claims mapping so that the ADFS issuer in K2 was linked to the K2ADFS label (it was previously mapped to the default ‘K2’ AD label), ensured that the UPN specifier was used for the identity and then tested to ensure that the users could authenticate with K2 via ADFS, this was successful – when now accessing the designer, the Data Label we put in the top right corner of the Form that should display the logged in user's FQN now displays K2ADFS:user@domain.com instead of K2:domainusername.
After still struggling with the authentication problem (401 error) in the SharePoint K2 test site, even after making the above adjustments, the K2 server logs were examined which seemed to indicate that the problem still lay in the fact that the user accessing SharePoint (via K2) did not have a profile in SharePoint UPS. We confirmed that the user K2.adm was able to retrieve its user properties from UPS via the https://sp.userprofiles.peoplemanager/getmyproperties web service – although no values were returned for the required fields SPS-ClaimID, SPS-ClaimProviderID, SPS-ClaimProviderType, and SPS-UserPrincipalName. We then attempted to access this web service using a different adm account in the same domain, which then returned an access denied error.
We then learned that none of the users in the CORP domain were synced with UPS (as is the case with adm users above). After syncing this domain, the 401 error was no longer displayed on the K2 management pages in SharePoint when accessing them with k2.adm and the other adm account from the CORP domain. We also tested access using other test users from the EMEA domain with success.
As to the reason why the CORP users needed to be synced with UPS in production when it works in the test environment where these users have not been synced, this is likely due to the fact that in the test environment, K2 has not been configured to use ADFS and instead always authenticates users using regular windows authentication. At this stage it is unclear why this results in the problem not occurring in testing, but for users to interact with SharePoint using OAuth they are required to have a profile synced in UPS that matches the user token from K2.
