Impersonating Any User On SharePoint

When a SharePoint web part, or similar custom code, is running on SharePoint the active SPContext will either be impersonating the current user’s account or the guest account (if enabled). This means that all of SharePoint’s security is maintained when accessing lists, items, etc. However; there may be some instances when you want the custom code to be able to access items (or lists, etc.) which the current user does not have access to without actually giving the user direct access to these particular items. Fortunately, this is a pretty easy task to achieve and can be accomplished in a number of ways.

Method 1. Using elevated security

This method takes advantage of the Microsoft.SharePoint.SPSecurity static helper methods, in particular, the RunWithElevatedPrivileges method. The objective of this method is to execute code with full control regardless of the users delegated roles. Example:

SPSecurity.RunWithElevatedPrivileges(() => {
    // Code running with full control
});

The most important thing to note here is that any SharePoint context objects that have already been instantiated outside of the elevated security blocks do not have full control, even if referenced from within the elevated security blocks. This means that you can not simply call SPSecurity.RunWithElevatedPrivileges(() => SPContext.Current.ListItem.Delete()); and expect it to work if the current user does not have permission to the delete the current list item; instead, you must instantiate a new SPSite object within the elevated security blocks and then delete the list item. For example:

SPSecurity.RunWithElevatedPrivileges(() =>
{
    using (SPSite site = new SPSite(SPContext.Current.Site.ID))
    {
        using (SPWeb web = site.OpenWeb(SPContext.Current.Web.ID))
        {
            SPList list = web.Lists[SPContext.Current.List.ID];
            SPListItem item = list.Items[SPContext.Current.ListItem.UniqueId];
 
            item.Delete();
        }
    }
});

Now when the above code runs, it should not have any problems deleting the current list item, even if the current user does not have permission to delete the item.

Method 2. Impersonating another user

This is another simple method which involves instantiating a new SPSite object running under a different context to that of the invoking users’ context. To achieve this, when we are instantiating the new SPSite object, we simply pass in the SPUserToken of the user we wish to impersonate. For example, we could run under the system account:

using (SPSite site = new SPSite(SPContext.Current.Site.ID, SPContext.Current.Site.SystemAccount.UserToken))
{
    // code here
}

The thing to note with this method is that the user being impersonated needs to have permission to perform the actions specified.

The UserToken is available from SPUser objects. So before creating the new SPSite object, you would need to find the user object for the user you wish to impersonate, or otherwise, have some way of reference the user’s token.