Impersonating an admin user in order to save form to list

Question

I have a requirement to create an Infopath form that saves the information to a list where no users should have read access. I have been thinking to accomplish this with impersonation where I want to impersonate an admin user when saving the form. Is this even possible?

Do you have any other idea of how I can save an Infopath form to a list without giving the user read permission to the list?

Answer 1

Since RWEP is notoriously buggy and unforgiving to work with (lots of quirks with threading and security context that can hit you hard and leave you in an unsupported state), I usually dont use it. If you dont believe me, read Dan Larssons article on Best Practices for Elevated Privilege in SharePoint.

There is a more elegant way of elevating privileges using SPUserToken.

// this example will only work from inside SharePoint since it uses SPContext, but can easily be adapted to use url
using (SPSite hubSite = new SPSite(SPContext.Current.Site.ID, GetSystemToken(SPContext.Current.Site)))
{
    // code goes here
}

The user token is fetched using GetSystemToken helper method that, if and only if access is denied uses RWEP and only to get the SPUserToken for site collection administrator:

    internal SPUserToken GetSystemToken(SPSite site)
    {
         SPUserToken token = null;

         bool tempCADE = site.CatchAccessDeniedException;
         try
         {
            site.CatchAccessDeniedException = false;
            token = site.SystemAccount.UserToken;
         }
         catch (UnauthorizedAccessException)
         {
             SPSecurity.RunWithElevatedPrivileges(() =>
             {
                 using (SPSite elevSite = new SPSite(site.ID))
                     token = elevSite.SystemAccount.UserToken;
             });
         }
         finally
         {
             site.CatchAccessDeniedException = tempCADE;
         }
         return token;
     }

This pattern is adapted from Keith Dahlbys examples here.

Answer 2

Come to think of it, another solution exist: You could create a custom permission pattern that allowed users to only create content, not read it.

What you want to do is to copy a contributor permission level and call it something like Limited Contributor, and uncheck the contributors permissions to read, delete and other permissions you do not want to grant the users.

More on creating custom permissions here. Find a list of OOB permission levels here.

You also can set ReadSecurity and WriteSecurity on a list, so that users can only read/edit items they have created. You set this under List Settings for the list.

Answer 3

You can do it with SPSecurity.RunWithElevatedPrivileges. The important thing is, that you open the web inside of RunWithElevatedPrivileges.

SPSecurity.RunWithElevatedPrivileges(() =>
{
  using (SPSite s = new SPSite("http://weburl"))
  {
    using (SPWeb w = s.OpenWeb())
    {
      SPList list = w.Lists["ListName"];
      // do what ever with the list....
    }
  }

});

Answer 4

Another solution, would be to create another list on the site with high security. After the user submits the form, use a SharePoint Designer Workflow (on item create) to copy the submitted values into the secure list. A final step would be to delete the original submission.

Sharepoint Designer workflows run with elevated permissions.

Answer 5

To build on the answers given by Anders Rask, if you want to allow anonymous users to submit an InfoPath form (e.g., an InfoPath form on an Internet website), you will likely need to impersonate another account to perform the submission. However, if only authenticated users should be able to submit the form, a custom permission level is probably a better approach. In that case, I would suggest creating a SharePoint group for the InfoPath form(s), granting the custom permission level to the SharePoint group, and adding anyone that needs to submit the InfoPath form(s) to the SharePoint group.

From a performance standpoint, I believe it is best to cache SharePoint objects instead of calling the same SharePoint API multiple times, since there is often extensive logic associated with retrieving SharePoint objects. In addition, as indicated by the CA1822: Mark members as static code analysis warning, methods should be static unless they need access to instance data. Thus, the impersonation pattern becomes:

SPContext context = SPContext.Current;
SPSite contextSite = context.Site;
SPWeb contextWeb = context.Web;
using (SPSite site = new SPSite(contextSite.ID, GetSystemToken(contextSite))) {
    using (SPWeb web = site.OpenWeb(contextWeb.ID)) {
        // Do real work here
    }
}

static SPUserToken GetSystemToken(SPSite site) {
    bool cade = SPSecurity.CatchAccessDeniedException;
    SPSecurity.CatchAccessDeniedException = false;
    SPUserToken token = null;
    try {
        token = site.SystemAccount.UserToken;
    }
    catch (UnauthorizedAccessException) {
        SPSecurity.RunWithElevatedPrivileges(delegate() {
            using (SPSite elevatedSite = new SPSite(site.ID)) {
                token = elevatedSite.SystemAccount.UserToken;
            }
        });
    }
    finally {
        SPSecurity.CatchAccessDeniedException = cade;
    }
    return token;
}

Note: The code pattern above can be used to impersonate any account by replacing GetSystemToken(contextSite) with the appropriate SPUserToken.