.NET IMPERSONATION

acceptableseashoreSecurity

Nov 5, 2013 (4 years and 3 days ago)

93 views

GUDURU PRAVEEN REDDY

.NET IMPERSONATION


Contents


Introduction


Impersonation Enabled


Impersonation Disabled


Impersonation Class Libraries


Impersonation Options


Authorization Options


Impersonation for ASP.NET application


Example


Advantages


Disadvantages


References



INTRODUCTION


Definition:

Users access a resource as though they were someone else. This is known
as impersonation.


HTML pages, ASP pages, and components in version 3.0 and earlier
can be accessed through two accounts named IUSR_machinename and
IWAM_machinename



Both the accounts are set up during IIS installation, and are
automatically added to all the folders in every web site on the server.


There is no need to authenticate a user in the case of IIS. When IIS
receives a request for a web page or other resource that has permission
for anonymous access, IIS treats the IUSR_machinename account as
the user's account, to access the resources.


If the resource requested by the user is an ASP page that uses a COM or
COM+ component, that component is executed using the
IWAM_machinename account.


In ASP.NET, when impersonation is turned off, the
resources can be accessed using a "local system process"
account.



When impersonation is turned on, ASP.NET executes
every resource using the account of a specified user who is
authenticated when the user makes the request.



If you specify the IUSR_machinename account to be used
as the user account, then ASP.NET will behave like
previous versions of ASP, in providing access to the
resources.

Impersonation Enabled

If impersonation is enabled in an ASP.NET application then:

• If anonymous access is enabled in IIS, the request is made
using the IUSR_machinename account.

• If anonymous access is disabled in IIS, the request is
made using the account of the authenticated user.

• In either case, permissions for the account are checked in
the Windows Access Control List (ACL) for the resource(s)
that a user requests, and a resource is only available if the
account they are running under is valid for that resource.


An

access control list

(
ACL
), with respect to a computer
file system, is a list of

permissions

attached to an

object

Impersonation Disabled

If impersonation is disabled in an ASP.NET application then:

• If anonymous access is enabled in IIS, the request is made
using the system
-
level process account.

• If anonymous access is disabled in IIS, the request is
made using the account of the authenticated user.

• In either case, permissions for the account are checked in
the Windows ACL for the resource(s) that a user requests,
and a resource is only available if the account they are
running under is valid for that resource.


Impersonation Class Libraries


Microsoft .NET Framework Class Library namespaces:



System.Web.Security



System.Security.Principal



System.Runtime.InteropServices






Impersonation Options



Windows authentication without impersonation.

This is the default setting. ASP.NET performs operations and
accesses resources by using your application's process
identity, which by default is the Network Service account on
Windows Server 2003.


Windows authentication with impersonation.
With
this approach, you impersonate the authenticated user and
use that identity to perform operations and access resources.


Windows authentication with fixed
-
identity
impersonation.

With this approach, you impersonate a
fixed Windows account to access resources using a specific
identity.



Authorization Options



Regardless of impersonation, you can authorize users and
control access to resources and business operations by
using the following mechanisms:


1)URL authorization.
You use URL authorization to
control access to requested files and folders based on the
request URL. You configure URL authorization by using an
<
authorization
> element in the Web.config file to control
which users and groups of users should have access to
requested resources. Authorization is based on the
IPrincipal

object stored in
HttpContext.User
. With
Windows authentication, this object is of type
WindowsPrincipal

and it contains a
WindowsIdentity

object that holds the Windows token for the authenticated
user.

2)

File authorization.

For file types mapped by IIS to the ASP.NET
automatic access checks are performed using the authenticated user's
Windows access token against the access control list (ACL) attached to
the requested ASP.NET file. The
FileAuthorizationModule

class only
performs access checks against the requested file. For example, if you
request Default.aspx and it contains an embedded user control
(Usercontrol.ascx), which in turn includes an image tag (pointing to
Image.gif), the
FileAuthorizationModule

performs an access check
for Default.aspx and Usercontrol.ascx, because these file types are
mapped by IIS to the ASP.NET . The
FileAuthorizationModule

does
not perform a check for Image.gif, because this is a static file handled
internally by IIS. However, because access checks for static files are
performed by IIS, the authenticated user must still be granted read
permission to the file with an appropriately configured ACL.

Note

Impersonation is not required for file authorization.



3)Role checks.
You can check the authenticated user's role
membership by using methods such as
User.IsInRole

and
Roles.IsUserInRole
.



You can also use principal permission demands and use
class
-
level and method
-
level declarative security to control
which users should be allowed to call classes and methods.

Impersonation for ASP.NET application

Impersonation for ASP.NET applications can be set up by using the
<identity>

tag in the
Web.config

file.


We can specify impersonation in the following three ways:


<identity impersonate="true"/> This means impersonation for
the ASP.NET worker thread is enabled.


<identity impersonate="true" name="username"
password="password"/> This means impersonation for the
ASP.NET worker thread is enabled, but the worker thread will run
under the identity that will be generated by using the credentials
specified by
username

and
password

attributes.


<identity impersonate="false"/> This means impersonation for
the ASP.NET worker thread is not enabled.





Impersonation


If you want to impersonate a user on a thread in ASP.NET, you
can use one of the following methods, based on your
requirments:



Impersonate the IIS authenticated account or user


Impersonate a specific user for all the requests of an ASP.NET
application


Impersonate the authenticating user in code


Impersonate a specific user in code


Impersonate the IIS Authenticated Account or User

To impersonate the Microsoft Internet Information Services
(IIS) authenticating user on every request for every page in an
ASP.NET application, you must include an
<identity>

tag
in the Web.config file of this application and set the
impersonate

attribute to
true

For example:


<identity impersonate="true" />

Impersonate a Specific User for All the Requests of an
ASP.NET Application:

To impersonate a specific user for all the requests on all pages
of an ASP.NET application, you can specify the
userName

and
password

attributes in the
<identity>

tag of the
Web.config file for that application.


For example:



<identity impersonate="true" userName="accountname"
password="password" />


If you use this approach, you should encrypt the credentials. With
ASP.NET version 2.0, you can use the Aspnet_regiis.exe tool. With
ASP.NET version 1.1, you can use the Aspnet_setreg.exe tool.


To encrypt the
<
identity
>

element by using
Aspnet_regiis


Run the following command to encrypt the <
identity
> element in the
Web.config

file.


aspnet_regiis

-
pef

"system.web/identity" "
C:
\
Sites
\
IntranetSite"


To decrypt the
<
identity
>

element

Run the following command to revert the <
identity
> element to plain
text.


aspnet_regiis

-
pdf

"system.web/identity" "
C:/Sites/IntranetSite "



The identity of the process that impersonates a specific user on a
thread must have the "Act as part of the operating system"
privilege. By default, the Aspnet_wp.exe process runs under a
computer account named ASPNET. However, this account does
not have the required privileges to impersonate a specific user. You
receive an error message if you try to impersonate a specific user.
This information applies only to the .NET Framework 1.0. This
privilege is not required for the .NET Framework 1.1.


To work around this problem, use the following methods:



Grant the "Act as part of the operating system" privilege to the
ASPNET account (the least privileged account).




Impersonate the Authenticating User in Code:


To impersonate the authenticating user (
User.Identity
)
only when you run a particular section of code, you can use
the code to follow. This method requires that the
authenticating user identity is of type
WindowsIdentity
.



For example:

System.Security.Principal.WindowsImpersonationContext impersonationContext;


impersonationContext =

((System.Security.Principal.WindowsIdentity)User.Identity).Impersonate();


//Insert your code that runs under the security context of the authenticating user


here. impersonationContext.Undo
();

Impersonating by Using the WindowsIdentity
Constructor:

One of the overloads for the constructor on the
WindowsIdentity

class permits you to obtain a Windows
token and logon session for a given domain account by
supplying a user principal name (UPN). With this approach
(shown in the following example), you do not need the
account's password.


using
System.Security.Principal
; ...

WindowsIdentity

wi

= new
WindowsIdentity
(
userName@fullyqualifieddomainName
);
WindowsImpersonationContext

ctx

= null;


try {

ctx

=
wi.Impersonate
();

// Thread is now impersonating


}

catch {

// Prevent exceptions propagating. }

finally

{

// Ensure impersonation is reverted
ctx.Undo
();

}




However, the disadvantage is that if your code needs to access local
resources, you must grant the
Act as part of the operating system

privilege to your Web application process account to get an
impersonation
-
level token.

To grant the Act as part of the operating system privilege:


On the
Start

menu, click
Control Panel
.


Click
Administrative Tools
.


Click
Local Security Policy
.


Expand
Local Policies
, and then click
User Rights Assignments
.


In the right pane, right
-
click
Act as part of the operating system
,
and then click
Properties
.


Click the
Add User or Group

button, then enter the account used to
run your ASP.NET application (
Network Service
by default).



WindowsIdentity



You can use the following code to determine what user the
thread is executing as


System.Security.Principal.WindowsIdentity.GetCurrent().N
ame


Example

<identity impersonate="true" />


The above
config

setting will make sure that the asp.net is always
running under the identity of the user who is connecting the
application

Code:


WindowsIdentity

wId

=
(
WindowsIdentity
)
HttpContext.Current.User.Identity
;



WindowsIdentity

wIdb4 =
WindowsIdentity.GetCurrent
();



string name = wIdb4.Name;



Response.Write
("Before impersonation"+name +"<
br
>");// <
--

Writes ASPNET Account


//Till this
line,code

is executed in the context of worker process


WindowsImpersonationContext wIdCon = wId.Impersonate();



WindowsIdentity wIdafter = WindowsIdentity.GetCurrent();



name = wIdafter.Name;



Response.Write("After Impersonation " + name + "<br>");

// <
--

writes Logged in user



//Run in the context of logged authenticated user, do your


//operations that require impersonation



wIdCon.Undo();



WindowsIdentity wIdafterUndo = WindowsIdentity.GetCurrent();



name = wIdafterUndo.Name;



Response.Write("After undo Impersonation " + name + "<br>");





OUTPUT


Before impersonation SERVER
\
ASPNET

After Impersonation TestAccount

After undo Impersonation SERVER
\
ASPNET







Advantages

The advantages of the impersonation :


Auditing.

You benefit from operating system auditing. This allows
administrators to track which users have attempted to access
specific resources.


Auditing across tiers.

The user's security context is maintained
across the physical tiers of your application, which allows
administrators to audit across tiers. Generally, auditing is
considered most authoritative if the audits are generated at the
precise time of resource access and by the same routines that
access the resource.


Granular access controls.

You can configure granular access in
the database. You can restrict individual user accounts
independently of one another in the database.



Disadvantges

The disadvantages of the impersonation :



Scalability.
The impersonation / delegation model does not
allow you to make efficient use of database connection pooling
because database access is performed by using connections that are
tied to the individual security contexts of the original callers. This
significantly limits the application's ability to scale to large
numbers of users.


Increased administration effort.

ACLs on back
-
end resources
need to be maintained in such a way that each user is granted the
appropriate level of access. When the number of back
-
end
resources increases (and the number of users increases), a
significant administration effort is required to manage ACLs.



References

http://msdn.microsoft.com/en
-
us/library/ff647404.aspx

http://msdn.microsoft.com/en
-
us/library/ff647405.aspx

http://www.codedigest.com/CodeDigest/9
-
Identity
-
Impersonate
-
at
-
Code
-
Level
-
in
-
ASP
-
Net.aspx

http://support.microsoft.com/kb/306158#1

http://www.15seconds.com/issue/020312.htm






Thank you