We have a client requirement where we have a scheduled process that needs to perform a collection of search queries towards Office365/SharePoint Online on behalf of various users to ensuring that the results are always security trimmed.

We have been scanning various search examples available on the internet, but we can't find one that really builds up a security context on behalf of a specific user. It is always limited to the security context of the App-Only ACS principal, which give a too broad result set that is not security trimmed.

Although given the information on https://social.msdn.microsoft.com/Forums/vstudio/en-US/f16869d1-f566-4b66-b92d-6604c9f541a6/impersonate-sharepoint-2013-search-api it is straight-forward through the SSOM API:

using System.IO;
using Microsoft.SharePoint;
using System.Data;
using Microsoft.Office.Server.Search.Query;
namespace ConsoleApplication1
    class Program
        static void Main(string[] args)
            // Impersonate
            string siteStr = "http://sp2013sps/sites/test";

            using (SPSite site = new SPSite(siteStr))
                using (SPWeb web = site.OpenWeb())
                    // Impersonate to user “sharepoint\exampleuser”
                    SPUserToken utoken = web.AllUsers[@"SHAREPOINT\exampleuser"].UserToken;

                    // Open site as that user
                    using (SPSite newSite = new SPSite(siteStr, utoken))
                        using (SPWeb newWeb = newSite.OpenWeb())
                            KeywordQuery keywordQuery = new KeywordQuery(newSite);
                            keywordQuery.QueryText = "SharePoint";
                            SearchExecutor searchExecutor = new SearchExecutor();
                            ResultTableCollection resultTableCollection = searchExecutor.ExecuteQuery(keywordQuery);
                            ResultTable resultTable = resultTableCollection.FirstOrDefault();
                            DataTable dataTable = resultTable.Table; 
                            // Impersonate code to interact with SharePoint

It looks like this impersonation strategy is just not available through an app-only ACS CSOM context. The documentation on https://msdn.microsoft.com/en-us/pnp_articles/app-only-elevated-privileges-sharepoint-add-in states:

  • [The app-only ACS] option does not execute code on behalf of a user and therefore may not be appropriate for all scenarios.

What are our options here?

  • Do you want to run queries on behalf of any user, knowing only login name? – Sergei Sergeev Dec 6 '16 at 14:01
  • exactly. I expect nothing less when the app-only security context has full control tenant permissions. – Carl in 't Veld Dec 6 '16 at 21:44
  • I don't think this is possible. Otherwise it breaks oauth design. You either need user login and password or generate and store refresh tokens (this approach requires user interaction) – Sergei Sergeev Dec 6 '16 at 22:39
  • I would say it would not break the oauth design. Oauth in my case would only be used to authenticate / authorize the app-only token. A specific CSOM flavor of the SSOM above would then kick in to retrieve a specific ClientContext based on a SharePoint UserToken; on the API level; not on the Bearer/Oauth token level. With regards to the refresh tokens - if we would be storing a refresh token per user, how long would it be valid? And approaching the issue from another angle, are there any code samples of security trimming done from custom code? – Carl in 't Veld Dec 7 '16 at 20:05
  • Refresh tokens appear to have a limited durability, 6 months, cf. msdn.microsoft.com/en-us/library/office/dn762763.aspx. How to cope with that? – Carl in 't Veld Dec 7 '16 at 20:22

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.