Co-Sponsored by: Latest Features  • Reuse, Recycle, Extend  • RSS Toolkit  • Migration Confrontation  • Load Balancing and Scaling Your WCF Services  • Got Maps? Article Rating Rate this article on a scale from 0 to 5 5 Best 4   3   2   1   0 Worst Email Tell a friend about this article!

Secure ASP.NET

ASP.NET Impersonation

By Don Kiely

Most of the time, a typical ASP.NET application runs in the security context of a local machine account created when you install the .NET Framework. On Windows 2000 and XP, this account is ASPNET; on later versions of Windows it is NETWORK SERVICE. These accounts are pre-configured to have all the permissions that a typical ASP.NET Web application needs to load, build, and transmit dynamic Web pages. Usually you don’t need to tinker with the default security context.

But what if you need to access some protected resource, such as a file on the local machine or a remote machine that is protected by tight security, to which the ASP.NET local account doesn’t have access? In general, you have two choices: you can either add Windows permissions to the context account or you can impersonate the security context of the user running the application. The first option requires changing the security settings in Windows of the protected resource to allow access by the ASP.NET account. This is fairly straightforward, but you definitely want to follow the principals of Least Privilege to protect external resources from abuse.

The other option, impersonation, is a bit trickier — but far more powerful if used carefully. Impersonation in ASP.NET allows you to change the security context of a page request to some other principal, either the user running the application or some other Windows account. Once you’ve impersonated another user or account, code that accesses Windows resources has the permissions of the impersonated account instead of those of the original security context.

There are several ways to implement impersonation, varying by the details used and the source of the impersonated credentials. Here I’ll take a brief look at configuring impersonation in web.config and one example of programmatic impersonation.

If you want to change the security context of all requests using the client/user’s security credentials, you can enable impersonation using the <identity> element in web.config:

<configuration>

   <system.web>

       <identity impersonate="true">

   </system.web>

</configuration>

You also can use the <location> element to make this setting more granular at the file or directory level.

If you want to specify a particular user to impersonate, you can use the userName and Password attributes of the <identity> element. If you leave off those attributes, ASP.NET will impersonate the client running the application. Which context this is depends on how you configure IIS. If the client has been authenticated by Windows, it uses that account’s security context. If the client is not authenticated, ASP.NET uses the IUSR_[machinename] account, or whatever account you have set in IIS for anonymous access to the Web site.

For more control, you can impersonate in code, such as to temporarily change security contexts before accessing a protected disk file. Here is a simple pattern you can use:

public void AccessProtectedResource()

{

   WindowsIdentity identity = (WindowsIdentity)Context.User.Identity;

   using (WindowsImpersonationContext wic = identity.Impersonate())

   {

       // Do something with client credentials

   }

}

As long as the client is authenticated, Context.User.Identity returns a WindowsIdentity object with the properties of the client’s security context. This object includes an Impersonate method that changes the security context and returns a WindowsImpersonationContext object.

It is critical to return the security context to its original state after accessing the protected resource by calling either the Undo or Dispose methods of the WindowsImpersonationContext object. In the code above, the call to Impersonate is in a using block, which calls the specified object’s Dispose method at the end of the block. This way you never have to worry about making the Undo or Dispose call yourself. If you fail to restore the original security context, the impersonated context will remain for the remainder of the page request, possibly leading to errors if it doesn’t have the necessary permissions for regular page creation operations.

There are plenty of other ways to impersonate programmatically, such as to impersonate a particular Windows account other than the current authenticated client. Explore the System.Security.Principal namespace in the .NET Framework for more information.

Impersonation can be a handy technique when you need to access protected system resources from within an ASP.NET application — as long as you follow the principals of least privilege and keep permissions narrow and in place only as long as you need them. The nice thing is that if Windows lets you impersonate, it isn’t fraudulent at all!

Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications as well as providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office. He writes regularly for several trade journals, and trains developers in database and .NET technologies. You can reach Don at mailto:donkiely@computer.org and read his blog at http://www.sqljunkies.com/weblog/donkiely/.