We're considering an identity delegation scenario where an external Web server will be consuming SharePoint REST services on behalf of the user visiting this Web server. Having done quite a research, I've figured out that:

  • SharePoint can issue a FedAuth cookie given a valid SAML token
  • I can get a delegation (OnBehalfOf) SAML token from ADFS given a "bootstrap" token by constructing a proper RST request to the token issuing endpoint (most likely trust/13/issuedtokenmixedsymmetricbasic256)

While I initially thought we would be all set with the above, I then bumped into this post: https://stackoverflow.com/a/8358003/370209 where they say

Perhaps if you wrote a whole new STS that could generate a trusted claim token that SharePoint would accept then you might be able to work around this using the ActAs token (SharePoint absolutely will not accept the OnBehalfOf token).

I am not sure I fully understand this quote (and, frankly speaking, the post it is coming from). But, if I get it right, my plan outlined above is doomed to failure due to the simple fact that SharePoint will not accept an OnBehalfOf SAML token issued by ADFS.

Is it indeed a known limitation of SharePoint identity normalization?

Also, since the referenced post also talks about creating an impersonated session using Claims, does this mean that an OnBehalfOf token will not work only if I am going beyond the boundaries of the SharePoint web app (I am only going to work with the list REST API - no BCS, no search - so I assume it's within the web app boundaries)?

Finally, there's this article https://blogs.msdn.microsoft.com/kaevans/2014/04/15/calling-o365-apis-from-your-web-api-on-behalf-of-a-user/ but it talks all the way about O365 and I am not at all sure if it is applicable to an on-premises scenario.

Please advise me on this issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.