Introduction
Maintaining the Application security is the main and important task of any developer. There are different configuration settings which are available to fine tune your ASP.NET Application. Out of other techniques which are available for Application security of ASP.NET is called Impersonation.
Impersonation is supported by legacy ASP 3.0 application. As the technology changes, ASP.NET application Impersonation is disabled by default. Let’s take a closer look exactly what the impersonation is.
What is Impersonation?
“Impersonation is a process in which COM object executes with identity of the entity on behalf of which it is performing work”
What does that mean? Ok! Let’s make it simple, in simple sense when the Server Impersonates, then it is performing the work for the client which is making the request for that work.
As mentioned earlier by default ASP.NET does not impersonate and instead executes all code using the same user account as the ASP.NET process, which is typically the ASPNET account, but we can mark it as enabled. If we enable it then it will impersonate for each and every request client makes and it executes code in the context of an authenticated and authorized client. This is contrary to the default behavior of ASP, which uses impersonation by default. In Internet Information Services (IIS) 6, the default identity is the NetworkService account.
Using impersonation, ASP.NET applications can optionally execute the processing thread using the identity of the client on whose behalf they are operating. You usually use impersonation for resource access control. Delegation is a more powerful form of impersonation and makes it possible for the server process to access remote resources while acting as the client
How Can I Configure Impersonation?
We have the following three options by which we can actually configure the Impersonation for our ASP.NET Application
1) To Enable the Impersonation: If you enable the impersonation, ASP.NET can impersonate the identity from IIS. (The identity which is to be impersonated must be authenticated.) or one must manually configure the settings in Web.config file.
<identity impersonate=”true”/>
Here in this instance ASP.NET impersonates the token passed by IIS, which is either authenticated user or Anonymous user from Internet.
2) To Disable the Impersonation: This is the default settings, and which is for backward compatibility with ASP Applications. In this instance, the ASP.NET thread runs using the process token of the application worker process regardless of which combination of IIS and ASP.NET authentication is used. By default, the process identity of the application worker process (aspnet_wp.exe) is the ASPNET account.
<identity impersonate=”false”/>
3) To Enable the Impersonation for the Specific Identity: Now, this settings, personally I like very much, as It impersonates specific identities, on the System/Domain/workgroup. In this instance, ASP.NET Impersonates the token generated using an identity generated in Web.Config.
<identity impersonate=”true”
Usename=”domain\user”
Password=”password”/>
If the application resides on a UNC share (Network Shared Path), ASP.NET always impersonates the IIS UNC token to access that share unless a configured account is used. If you provide an explicitly configured account, ASP.NET uses that account in preference to the IIS UNC token. You should be very careful while working with impersonation because it makes it possible for an application to potentially process code using permissions not anticipated by the application designer. For example, if your application impersonates an authenticated intranet user, that application possesses administrative privileges when impersonating a user with those privileges. Likewise, if the impersonated user possesses more restrictive permissions than anticipated, the user may not be able to use the application.
In Case if you want Anonymous access then you can use wildcards in identity tag of web.config.
<identity impersonate=”true”
Username=”*”
>
If you want to allow only authenticated users then you can configure as
<identity impersonate=”true”
Username=”?”
>
Important:
1) Impersonation can significantly affect performance and scaling. It is generally more expensive to impersonate a client on a call than to make the call directly.
2) Impersonation is local to a particular thread. When code changes threads, such as when using thread pooling, the new thread executes using the process identity by default. When impersonation is required on the new thread, your application should save the security token (Token Property) from the original thread as part of the state for the completion thread.
That’s all for now !!