Impersonation gives ASP.NET applications the capability to
In the event of
The only type of code that is impersonated is application code. The configuration and compilation are read as the process token. When using an application on a UNC share, ASP.NET always impersonates the token given to IIS to use the share unless a configured account is provided. If an explicit configured account is provided, ASP.NET uses that account in preference to the IIS UNC token. If an application should want per-request impersonation, the application can easily be configured to impersonate the user making the request.
Impersonation is not disabled only if the computer is overridden. Impersonation is defaulted at the computer level to be disabled, and all application domains inherit this setting. You can enable impersonation by
Being that most configuration directives apply hierarchically, the same is to be expected with the impersonation directive. Only when applications are explicitly overridden will they not be respected by the nested applications. Following are the default values for the impersonation setting:
A minimal configuration file to enable impersonation for an application might look similar to the following example:
// Web.config file <identity impersonate="true" name="username" password="password" />
There is also name support for running an application as a configurable identity. For example:
<identity impersonate"true" name="Reidsville\Developer" password="bar" />
This enables the entire application to run as Reidsville\Developer , regardless of the identity of the request, as long as the password is correct. This type of impersonation can be delegated to another computer.
Security in the .NET world is just as important as ever. But the tools are there to provide you with the mechanisms that you need to create secure applications.
In this chapter you've learned about server and client certification and how to use the