ASP.NET Runtime Impersonation

Impersonation in ASP.NET

When we are doing I/O operations, the operation system makes security checks to understand if the user is authorized to do the operation. The same thing happens when you try to do operations on another machine in your network. Impersonation in ASP.NET occurs when ASP.NET executes code in the context of an authenticated and authorized user. By default, ASP.NET run in the ASPNET account. By using impersonation we can impersonate the ASPNET account to another account that has access to resources which aren’t granted in the internet security permission. One way to impersonate a user is by using the identity element in the web.config. When you use the following code in your web.config, ASP.NET impersonates to the authenticated user or to an anonymous internet user account:

<identity impersonate="true" />

If you want to impersonate to a specific user you can use the following configuration:

<identity impersonate="true" userName="domain\username" password="password" />

Runtime Impersonation

At my customer the previous configuration examples weren’t an option. The second way to impose impersonation is by runtime. This option can be achieved by using the System.Security.Principal and the WindowsIdentity class. The WindowsIdentity class has a method that makes impersonation and returns a WindowsImpersonationContext. The problem with this class is that you need to supply to it an IntPtr which is a security access token of the user that you wish to impersonate to. The solution is to use P/Invoke and call the LogonUser Win32 API. After you get the impersonation context you can run the network operations that you seek to perform. After you finish to do your operations you need to undo the impersonation. The following code shows an example of an impersonation service class:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

using System.Runtime.InteropServices;

using System.Security.Principal;

namespace WebApplication1

{

public class ImpersonationService

{

#region Consts

public const int LOGON32_LOGON_INTERACTIVE = 2;

public const int LOGON32_PROVIDER_DEFAULT = 0;

#endregion

#region External API

[DllImport("advapi32.dll", SetLastError = true)]

public static extern int LogonUser(

string lpszUsername,

string lpszDomain,

string lpszPassword,

int dwLogonType,

int dwLogonProvider,

out IntPtr phToken

);

[DllImport("advapi32.dll", SetLastError = true)]

public static extern bool RevertToSelf();

[DllImport("kernel32.dll", SetLastError = true)]

public static extern int CloseHandle(IntPtr hObject);

#endregion

#region Methods

public void PerformImpersonatedTask(string username, string domain, string password, 

int logonType, int logonProvider, Action methodToPerform)

{

IntPtr token = IntPtr.Zero;

if (RevertToSelf())

{

if (LogonUser(username, domain, password, logonType,

logonProvider, out token) != 0)

{

var identity = new WindowsIdentity(token);

var impersonationContext = identity.Impersonate();

if (impersonationContext != null)

{

methodToPerform.Invoke();

impersonationContext.Undo();

}

}

else

{

// do logging

}

}

if (token != IntPtr.Zero)

{

CloseHandle(token);

}

}

#endregion

}

}

Here is an example of how to use the class in your ASP.NET application:

using System;

using System.IO;

namespace WebApplication1

{

public partial class _Default : System.Web.UI.Page

{       

#region Page Events

private void Page_Load(object sender, System.EventArgs e)

{

var service = new ImpersonationService();

service.PerformImpersonatedTask("username", "domain", "password",

ImpersonationService.LOGON32_LOGON_INTERACTIVE, ImpersonationService.LOGON32_PROVIDER_DEFAULT, new Action(MethodToPerform));

}

#endregion

#region Methods

public void MethodToPerform()

{

var serverPath = @"\\ServerName\test";

var dirInfo = new DirectoryInfo(serverPath);

Response.Write(dirInfo.Exists);

}

#endregion

}

}

Summary

In the post I showed a simple way to implement a class that impersonate to a relevant account in order to achieve some functionality that internet security permissions don’t allow.  You should consider to use the web.config instead since it does all the communication with Win32 API instead of the supplied code. The impersonation isn’t limited only to ASP.NET and can be used also in other frameworks.