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

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

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
Free Mobile And Desktop Apps For Accessing Restricted Websites
TOYOTA CAMRY 2; 2.5 : Camry now more comely
KIA SORENTO 2.2CRDi : Fuel-sipping slugger
How To Setup, Password Protect & Encrypt Wireless Internet Connection
Emulate And Run iPad Apps On Windows, Mac OS X & Linux With iPadian
Backup & Restore Game Progress From Any Game With SaveGameProgress
Generate A Facebook Timeline Cover Using A Free App
New App for Women ‘Remix’ Offers Fashion Advice & Style Tips
SG50 Ferrari F12berlinetta : Prancing Horse for Lion City's 50th
- Messages forwarded by Outlook rule go nowhere
- Create and Deploy Windows 7 Image
- How do I check to see if my exchange 2003 is an open relay? (not using a open relay tester tool online, but on the console)
- Creating and using an unencrypted cookie in ASP.NET
- Directories
- Poor Performance on Sharepoint 2010 Server
- SBS 2008 ~ The e-mail alias already exists...
- Public to Private IP - DNS Changes
- Send Email from Winform application
- How to create a .mdb file from ms sql server database.......
programming4us programming4us