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_INTERACTIVE = 2,
LOGON32_LOGON_NETWORK = 3,
LOGON32_LOGON_BATCH = 4,
LOGON32_LOGON_SERVICE = 5,
LOGON32_LOGON_UNLOCK = 7,
LOGON32_LOGON_NETWORK_CLEARTEXT = 8,
LOGON32_LOGON_NEW_CREDENTIALS = 9
}
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();
Console.Write(
"\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))
{
Console.WriteLine("Success");
}
else
{
Console.WriteLine("Failure");
}
Console.Read();
}
}
}
|
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();
Console.WriteLine(web.CurrentUser.Name);
}
Console.Read();
using (SPSite site = new SPSite(siteUrl))
{
using (SPSite otherUserSite =
new SPSite(siteUrl, site.RootWeb.AllUsers["WINSMARTS\\johndoe"].UserToken))
{
SPWeb web = otherUserSite.OpenWeb();
Console.WriteLine(web.CurrentUser.Name);
}
}
Console.Read();
}
|
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.
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.
