Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
3  
Great question, I would love to see more questions about best practices. –  Mike Oryszak Nov 26 '11 at 16:32
    
Yes, but also a very open question with several possible answers. Hence marked community wiki –  Anders Rask Nov 27 '11 at 8:42
add comment

3 Answers

up vote 9 down vote accepted

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).

share|improve this answer
add comment

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).

For details, You can check this article : Impersonation in SharePoint : An Extreme Overview

share|improve this answer
add comment

We have touched on this subject several times before. Last time i linked to Keth Dalbys explanation on SO http://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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.