Channels ▼
RSS

ASP.NET Impersonation


ASP.NET Impersonation

By default, per-request impersonation is disabled in ASP.NET, meaning that each request is always served by a thread running under a fixed account. The account is typically ASPNET or NETWORK SERVICE, depending on the underlying operating system. If per-request impersonation is enabled, the worker thread inherits the security token assigned to the request by IIS. Per-request impersonation changes the identity of the thread executing the current request, not the identity of the ASP.NET worker process hosting the serving thread. Per-request impersonation is activated with the following statement in the web.config file:

<identity impersonate="true" />
Another form of impersonation is possible in ASP.NET—per-application impersonation. In this case, you still ask the worker thread to impersonate an identity, except that the identity is fixed and hard-coded in the web.config file:

<identity impersonate="true" <br>    userName="MyAspNetAccnt" password="ILoveA$p*SinceVer1

Impersonation doesn’t really change the physical identity of the process running ASP.NET. More simply, all threads serving in the context of the ASP.NET worker process will always impersonate a given user for the duration of the application.

When a fixed identity is involved, the security token must be generated by the ASP.NET worker process. Running under a poorly privileged account like NETWORK SERVICE, though, the ASP.NET worker process may, in some cases, lack the permission to do that.

A process running under a nonadministrator account cannot impersonate a specific account on Windows 2000 unless you grant it appropriate privileges. Under Windows 2000, a process requires the “Act As Part Of The Operating System” privilege to impersonate a fixed identity. This is indeed a strong and powerful privilege that nonadministrator process accounts like ASPNET and NETWORK SERVICE are generally not granted for security reasons.

The requirement disappears with Windows XP and Windows Server 2003, which will also make it possible to impersonate a given identity to processes that lack the “Act As Part Of The Operating System” privilege.

In ASP.NET 1.1, though, impersonating a fixed identity is also possible under Windows 2000 machines and IIS 5.0. The ASP.NET 1.1 runtime plays some tricks to revector the call back to the aspnet_isapi.dll module, which is running inside IIS 5.0 and under the SYSTEM account. Basically, the ASP.NET 1.1 ISAPI extension creates the security token and duplicates it in the memory space of the worker process. In this way, ASP.NET 1.1 supports fixed impersonation without requiring the “Act As Part Of The Operating System” privilege on the worker process account.

In the end, expect to have troubles with fixed impersonation only if you’re still running ASP.NET 1.0 applications under Windows 2000. In this case, for the impersonation to work, you need to run your ASP.NET applications under the SYSTEM account, with the security repercussions that this might have.

A third possibility to change the identity of the ASP.NET worker process is impersonating through the IIS anonymous account. The idea is that the ASP.NET application grants access to anonymous users, and the anonymous account is configured in IIS to be the desired account for the application.

In this case, the application uses per-request impersonation and the ASP.NET code executes as the impersonated account. The process account remains set to ASPNET or NETWORK SERVICE. In this way, you don’t have to worry about replicating in the new account the minimum set of permissions on folders that allow ASP.NET to work.


Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Network and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and ADO.NET and Applied XML Programming for .NET. Contact Dino at dinoe@wintellect.com.



Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video