Sharepoint 2010 : The SharePoint Security Object Model (part 2) - Elevating Security

7/24/2012 3:54:24 PM

1. Elevating Security

Imagine that are you writing a simple WebPart which displays a disclaimer message to the end user. This disclaimer message has a little check box, allowing the user to acknowledge that he has read this disclaimer message. Checking this check box will update the list behind the scenes recording all the users that have accepted that disclaimer. Your WebPart is running under the same security credentials as the logged in user himself. Therefore, the same logged in user needs to have rights to edit the list in which you are recording the list of users that have accepted the disclaimer.

What this means is that after the user has accepted the disclaimer, he can go delete his list item from that list, which will clearly defeat the purpose of recording in the first place.

In situations like these, you need to be able to allow the user to update a list to which he usually would not have access to. This is commonly referred to as elevating the user's security rights. Elevation can be done in three different ways.

The first way to do elevation is to use Win32 API. This technique is shown in Listing 2.

Example 2. Impersonating Using Win32 API
namespace NetworkAuth
  class Program
    [DllImport("advapi32.dll", SetLastError = true)]
    public static extern bool LogonUser(
      string lpszUsername,
      string lpszDomain,
      string lpszPassword,
      int dwLogonType,
      int dwLogonProvider,
      out IntPtr phToken
    public enum LogonType : int
      LOGON32_LOGON_BATCH = 4,
    const int LOGON32_PROVIDER_DEFAULT = 0;
    static void Main(string[] args)

      IntPtr hToken;
      string username;
      string password;
      Console.Write("Enter your username without domain (example smalik):");
      username = Console.ReadLine();
        "\nEnter your password (btw password will be shown as cleartext, so make sure no one
is looking):");
password = Console.ReadLine();


if (LogonUser(username,
         "domainAsString", password,
         (int)LogonType.LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, out hToken))


This approach is useful when you're trying to impersonate with systems outside of SharePoint. Within SharePoint, however, there are a couple of other elegant methods.

The second approach to impersonate is to do so by using the SPSecurity.RunWithElevatedPrivelleges method. This approach will allow you to make changes to your objects using a fictional account called SharePoint\System. I say fictional because this account is not in your active directory; it is an account purely defined inside of SharePoint. This account has been given God rights within SharePoint, so it can do whatever it wishes. The problem this creates is that while God can edit a particular list item, if at a later date you wish to find out who exactly edited a particular list item, well, God edited it! So you lose any level of traceability.

This brings me to the third possible way of achieving elevation, or rather perhaps a more accurate term, impersonation. This is done by using a special constructor on the SPSite object which accepts an SPUserToken object. This can be seen in Listing 3.

Example 3. Impersonating to Another User
private static void DemonstrateElevation()
  using (SPSite site = new SPSite(siteUrl))
    SPWeb web = site.OpenWeb();


  using (SPSite site = new SPSite(siteUrl))
    using (SPSite otherUserSite =
      new SPSite(siteUrl, site.RootWeb.AllUsers["WINSMARTS\\johndoe"].UserToken))
      SPWeb web = otherUserSite.OpenWeb();



As you can see from Listing 12-5, I'm first creating an SPSite object and I'm printing out the current user's name. In the second instance, I create an SPSite object by using a special constructor that accepts a SPUserToken for "johndoe". Running this application will produce output, as shown in Figure 9.

Figure 9. Impersonation in effect

As you can see, in the second instance, all code is now running as John Doe. Therefore, you now will be able to run code against your SharePoint installation under the permissions of John Doe. What is notable is that you were able to impersonate as both SharePoint\system and as John Doe without actually requiring any passwords. Therefore, these approaches are not allowed in sandbox solutions. Also, this reinforces my point that whenever you allow anyone to deploy code on the server as a farm solution you need to review that code very well for things such as impersonation.

Top 10
Review : Sigma 24mm f/1.4 DG HSM Art
Review : Canon EF11-24mm f/4L USM
Review : Creative Sound Blaster Roar 2
Review : Philips Fidelio M2L
Review : Alienware 17 - Dell's Alienware laptops
Review Smartwatch : Wellograph
Review : Xiaomi Redmi 2
Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
Popular Tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8