Elevating Privileges in SharePoint Code

Impersonation leads to Permission Trimming

SharePoint uses ASP.Net impersonation to personalize the platform based on the current authorized user. SharePoint objects are aware of the user’s identity and many parts of SharePoint take advantage of this ability. For example, when you get the lists in a site through the API, you only see the ones the current user has access to. Permission trimming, as similar functions in SharePoint are often referred, is a major convenience to the end user and a feature of SharePoint that many rely on.

Experienced in ASP.Net but not Impersonation

For many developers coming from backgrounds in ASP.Net projects where impersonation is not used, this can be very confusing. For example, many developers new to SharePoint, including myself, were surprised the first time they realized that opening a connection to a database was denied because the connection was access as the end user, not the application pool account. The natural first reaction is “Who moved my cheese? How do I get back to normal?” Where normal is the previous normal of ASP.Net web applications not using impersonation. However, as MSDN cautions, running with impersonation is something you should get used to when using Sharepoint:

If you use Windows authentication and your code calls the SharePoint object model from an Internet Information Services (IIS) worker process, the request must impersonate the calling user’s identity. SharePoint Foundation configures ASP.NET to impersonate the calling user automatically, but your code may work unexpectedly, or fail, if you suspend impersonation

Quoted from <http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite.aspx>

When to RunWithElevatedPrivileges, When not to

Often, failing to suspend impersonation in the way MSDN cautions about, the next step a developer will take to “solve the problem” of impersonation is to use a SharePoint API call named SPSecurity.RunWithElevatedPrivileges.

RunWithElevatedPrivileges is a great way to solve the database connection problem, but often it can become somewhat of a Pandora’s box. It can become a go-to tool for every permission error encountered in SharePoint code. However, there are some issues that can occur with overuse of this style of programming, not least of which is that you lose some core SharePoint functionality inherent with impersonating the user.

A StackOverflow discussion about the pitfalls of RunWithElevatedPrivilges is a good summary and starting point for reading on the subject. Also, I’ve included below 3 good references for further reading on the topic.

Further Elevated Privileges Reading

These first two links below are from Daniel Larson, co-author of Inside Microsoft Windows SharePoint Services 3.0 published by Microsoft Press. I consider that one of the best books written about SharePoint Development and I’ve read it cover to cover more than once. The first post is a set of good general guidelines. The second is a more concrete implementation of impersonating using the SPSite constructor. The third link is by a .Net Developer Keith Dalby who is a former Microsoft employee and MVP. I don’t use his approach, but I think some .Net Developers who are fond of recent changes in the .Net language would appreciate his take.