Office365 Sharepoint API fails for federated domains

1
votes

I'm currently exploring the (Academic Licensed) Office365 API via oAuth access_tokens and have succeeded in retrieving a simple OneDrive folder list via the SharePoint API using access tokens, as a proof of concept.

But this seems to work only for users that are in the Azure maintenance domain that's NOT SSO enabled to our on-premise ADFS server.

The domain that is SSO enabled to our own ADFS server succesfully gets logged in on acquiring the oAuth code and I get a genuine access_token while trading in this code. But using this access_token to retrieve a simple folder list for the user results in this error instead of a folderlist.

{"error_description":"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}

Wich I can't check since I'm not in control of the Azure Sharepoint server.

Did anyone succeed in using the Office365 API icw SSO enabled domains/users?

1
apisharepointazurems-officesingle-sign-on
The OAuth implementation certainly works for federated users. It sounds like one coming from the web server rather than from SharePoint. That error looks like the default one you’ll get on an ASP.Net web site that runs into an unhandled exception rather than one coming from SharePoint. What’s likely happening is that your code is calling into SharePoint, getting an exception back from us, and his ASP.Net web site isn’t handling the exception and is configured to return custom errors. – Jeremy Thake MSFT
Thx for the comment. In the meantime I've had contact with MS support and they confirmed this was a problem with the user (and the error was from Sharepoint). It seems Azure/Sharepoint was choking on users that were previously deleted and then re-provisioned. That's not supported at the moment and they're working on a fix. – MrVanes

1 Answers

0
votes

You'll struggle with an ADFS setup. Any code I've written relies on managed accounts only (i.e. those accounts with a UPN ending with onmicrosoft.com). Each synchronised user from on-premise will have a matching onmicrosoft.com secondary identifier which you should use instead.