Best way to Impersonate in SharePoint

Question

So far, I am aware of below 3 ways of performing impersonation in a SharePoint web part or page :

1. Using Win32 API

   [DllImport("advapi32.dll", SetLastError=true)]
   public static extern bool LogonUser(string lpszUsername, string lpszDomain, string lpszPassword, int dwLogonType, int dwLogonProvider, out IntPtr phToken);
   

2. Using SPSecurity.RunWithElevatedPrivileges

3. Using SPUserToken

   using(SPSite oSiteCollection = new SPSite("http://SpSite", bUserToken))
   {
      ----
   }
   

Any idea which the best and why?

Also, Is there any other way to perform impersonation?

Answer 1

It depends on what you need to do.

RunWithElevated only runs as the Application Pool Identity, so you might not have access to other web applications, only other site collections in the current web application, but you can be guaranteed that you will be running as a user that exists (the AppPool identity).

With UserToken, you need to be sure that the user exists that you're impersonating, and that that user has the permissions already set up.

With Win32 P/Invoke to LogonUser, I'd imagine that the limitations are similar to UserToken.

Edit: I just remembered about SharePoint Designer 2010's "Impersonation Step".

http://office.microsoft.com/en-us/sharepoint-designer-help/workflow-conditions-in-sharepoint-designer-2010-a-quick-reference-guide-HA010376962.aspx#_Toc259096791

With this, you can impersonate the user who created the workflow and have steps run as that user, within the workflow, without a single line of code. However, this only work as the person who published the Workflow, so care needs to be taken as to who does this, and what would happen to their account should that person leave the company (so do things like set up a dedicated 'application service account' for this purpose).

Answer 2

We have touched on this subject several times before. Last time i linked to Keth Dalbys explanation on SO https://stackoverflow.com/questions/1525953/sharepoint-2007-runwithelevatedprivileges-pitfalls-of-using-this

Which explains why you sould not use RWEP but in very specific situations, like when fetching data outside of SharePoint.

Answer 3

The best way depends on the situation .Few points I would like to mention :

• You should avoid using SPSecurity.RunWithElevatedPrivileges for elevation of privilege of SharePoint objects. Instead, use SPUserToken to impersonate SPSite with a specific account, as shown previously.If you want make network calls under the application pool identity or you don’t have a valid and known SPUser to retrieve SPUsertoken then SPSecurity.RunWithElevatedPrivileges is the only choice.

• If you need to use SPSecurity.RunWithElevatedPrivileges, it is must to dispose all objects in the block. Do not pass SharePoint objects out of the RunWithElevatedPrivileges block.

• If you want to impersonated in application outside SharePoint, the only option is to use WIN 32 API or WindowsIdentity.Impersonate(token).

Answer 4

1. Using Win32 API:

   This is not a SharePoint solution, so SharePoint is not fully "aware" of the impersonation. The code will indeed run under the new identity, but first thing, you'll need to create (and later destroy) new SPSite and SPWeb objects, as these objects retain the identity of the user who created them (and contextual SPSite and SPWeb were created by the current user).

   As SharePoint is not aware of the impersonation, and as these objects are created in an ASP.NET context (and SharePoint knows that), you may then encouter some troubles: indeed, on some API calls (unfortunately not listed in the doc) check the objects' identity against the initial user's identity. If this does not macth, an error may be raised.

   A ((very) bad?) way to avoid this is to trick SharePoint and makes it think it does not run in ASP.NET: you do that by creating a new Domain Application and run the code inside it.

2. Using SPSecurity.RunWithElevatedPrivileges:

   SPSecurity.RunWithElevatedPrivileges will do 2 things:

   • It will revert the Windows identity to the Application Pool's one (as you may do yourself with a Win32 call)

   • It will flag the new SPSite and SPWeb objects created in this section so there's no check as in the previous option.

   However, SPSecurity.RunWithElevatedPrivileges is only meant to access data Inside the current Site Collection (it will work to access data from other site collections in the same Web app, but it's not its primary purpose, and this is a bit "against" the SharePoint phylosophy)

3. SPUserToken has the same purpose as SPSecurity.RunWithElevatedPrivileges, but :

   • There's no Windows impersonation or revert-to-self

   • You can impersonate any user you want

   • There's no risk you leave the impersonation activated in case of failure (i.e. no need for a finally block)

In such scenarios where you need an empowered user to do actions in SP, you should always at least consider running the code in a SharePoint timer job. Jobs run under SPFarm, who has full permissions on the entire farm.