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 objectpermissionsobject

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 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 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 tag in the Web.config file. We can specify impersonation in the following three ways: This means impersonation for the ASP.NET worker thread is enabled. 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. 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 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 tag in the Web.config file of this application and set the impersonate attribute to true For example:

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 tag of the Web.config file for that application. For example:

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 element by using Aspnet_regiis Run the following command to encrypt the element in the Web.config file. aspnet_regiis -pef "system.web/identity" " C:\Sites\IntranetSite" To decrypt the element Run the following command to revert the 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 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 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 +" ");// <-- 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 + " "); // <-- 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 + " "); 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 Impersonate-at-Code-Level-in-ASP-Net.aspx

Thank you