Using Impersonation and Delegation in ASP.NET

for RuBoard

After reading Chapter 13 on getting users authenticated and reading this chapter on getting users authorized, you should have a good understanding of how to figure out getting users identities when they attempt to access a resource. One use for this information is to allow the server to impersonate the user or client. By default, in the machine.config file and the web.config file, impersonation is turned off (set to false ). Listing 14.14 shows this element in its default setting from a web.config file. Enabling impersonation is quite easy; it requires you to set the impersonation attribute of the identity element to true . But wait, there's more. Before using this feature, there is a bit to understand about what exactly is happening here, and just how careful to be with it.

Listing 14.14 Identity Element Snippet

 <system.web>      ...other elements <identity impersonate="false">      ...other elements </system.web> 

In Windows 2000, to configure the server to allow impersonation, the server identity must be configured as Trusted for Delegation within the Active Directory. This setting is located in the properties of a domain controller within the Active Directory Users and Computers Management Console, as shown in Figure 14.5. The check box for Trust Computer for Delegation must be checked. If a computer is not part of an Active Directory, delegation can still occur, and will by default. It's just that Active Directory gives you an easy way to disable delegation.

Figure 14.5. Domain Controller Properties page.

When it comes to configuring a user for delegation, the process is very similar. Within Active Directory is a place where you can allow or disallow a person's right to delegate. As with computers, if a user is not part of the Active Directory, he or she can still delegate. This property is exposed through the user properties page of the Active Directory Users and Computers Management Console, as shown in Figure 14.6.

Figure 14.6. User Properties page.

Now that the server and the client are allowed to delegate, impersonation can take place. If you have allowed impersonation as shown back in Listing 14.14, when a user is authenticated, the ASP.NET application will run with the permissions that the authenticated user has. There is another twist ”you can enable impersonation to occur as a single user. In other words, after any user is authenticated, the ASP.NET application runs as an account that you have established for this purpose. An example of this is shown in the code snippet in Listing 14.15.

Listing 14.15 Impersonation as a User Snippet

 <system.web>      ...other elements <identity impersonate="true" userName="KPCRASH\juser" password="password">      ...other elements </system.web> 

In Listing 14.15, all authenticated users will run as user juser , regardless of who they are. Even if the application is on a UNC share, IIS will pass the authenticated user token unless a static account, as shown in Listing 14.15, is used. An obvious downside to this is the plain text password being stored in the web.config file.

In a final note on impersonation and delegation within ASP.NET, the impersonated user must have read/write access to the Temporary ASP.NET Files folder. In Windows 2000, the Authenticated Users group has read and execute permissions by default, but not write access. It is necessary before deploying any ASP.NET application that will require impersonation to either enable the Authenticated Users group to write to that directory, usually found at %WINDIR% \Microsoft.Net\Framework\[VERSION]\Temporary ASP.NET Files\ , or enable write access to that directory on a per-user or per-group basis, depending on your specific network policies.

for RuBoard