-----------------------------------------------------------

New Message on MumbaiUserGroup

-----------------------------------------------------------
From: hereiam_always
Message 1 in Discussion

 
ASP.NET Impersonation<o:p></o:p> 
Introduction<o:p></o:p> 
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. <o:p></o:p> 
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.<o:p></o:p> 
<o:p> </o:p> 
What is Impersonation?<o:p></o:p> 
“Impersonation is a process in which COM object executes with identity of the 
entity on behalf of which it is performing work” <o:p></o:p> 
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.<o:p></o:p> 
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.<o:p></o:p> 
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<o:p></o:p> 
<o:p> </o:p> 
How Can I Configure Impersonation?<o:p></o:p> 
<o:p> </o:p> 
We have the following three options by which we can actually configure the 
Impersonation for our ASP.NET Application<o:p></o:p> 
<o:p> </o:p> 
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.<o:p></o:p> 
<identity impersonate=”true”/><o:p></o:p> 
Here in this instance ASP.NET impersonates the token passed by IIS, which is 
either authenticated user or Anonymous user from Internet.<o:p></o:p> 
 <o:p></o:p> 
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.<o:p></o:p> 
<identity impersonate=”false”/><o:p></o:p> 
            <o:p></o:p> 
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.<o:p></o:p> 
<identity impersonate=”true” <o:p></o:p> 
  Usename=”domain\user” <o:p></o:p> 
 Password=”password”/><o:p></o:p> 
<o:p> </o:p> 
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. <o:p></o:p> 
<o:p> </o:p> 
In Case if you want Anonymous access then you can use wildcards in identity tag 
of web.config.<o:p></o:p> 
<identity impersonate=”true”<o:p></o:p> 
Username=”*”<o:p></o:p> 
><o:p> </o:p> 
<o:p> </o:p> 
If you want to allow only authenticated users then you can configure as 
<o:p></o:p> 
<identity impersonate=”true”<o:p></o:p> 
Username=”?”<o:p></o:p> 
><o:p> </o:p> 
<o:p> </o:p> 
<o:p> </o:p> 
Important:<o:p></o:p> 
<o:p> </o:p> 
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.<o:p></o:p> 
<o:p> </o:p> 
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.<o:p></o:p> 
<o:p> </o:p> 
<o:p> </o:p> 
That’s all for now !!<o:p></o:p>

-----------------------------------------------------------

To stop getting this e-mail, or change how often it arrives, go to your E-mail 
Settings.
http://groups.msn.com/MumbaiUserGroup/_emailsettings.msnw

Need help? If you've forgotten your password, please go to Passport Member 
Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help

For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact

If you do not want to receive future e-mail from this MSN group, or if you 
received this message by mistake, please click the "Remove" link below. On the 
pre-addressed e-mail message that opens, simply click "Send". Your e-mail 
address will be deleted from this group's mailing list.
mailto:[EMAIL PROTECTED]

Reply via email to