Using Impersonation

Impersonation is the process by which ASP.NET takes on the security context of the user making the request. This allows ASP.NET (and components called by ASP.NET) to gain access to resources that the user is authorized to access.

In classic ASP, impersonation was used by default. If the user making the request had not been authenticated by IIS using basic or NTLM authentication, ASP requests ran with the security context of the IUSR_MACHINENAME built-in account. In ASP.NET, impersonation must be turned on explicitly by using the impersonation attribute of the <identity> element. Without impersonation, ASP.NET runs as the built-in ASPNET account. (You can use the <processModel> configuration section to configure ASP.NET to run as a different account that has more privileges, such as the SYSTEM built-in account, but this carries some increased security risks because of the higher privilege level of the SYSTEM account.)

Note

As mentioned earlier in this chapter, IIS 6.0, when running in native mode, ignores the <processModel> configuration element in favor of its own process model settings. The default identity for ASP.NET applications running under IIS 6.0 is Network Service.

For example, you might want to take advantage of impersonation to use trusted connections with SQL Server. Trusted connections use Windows security to connect to a SQL Server database without the need for a SQL Server username and password. As discussed earlier in this chapter, one of the challenges facing ASP.NET developers is where to store database login information to reduce the risk of it being compromised. With trusted connections, this is not a problem because the login information is never stored by the application.

Enable trusted connections to SQL Server

1. Configure your application to use Windows authentication, as described earlier in this chapter.

2. Add the <identity> element to your configuration file to make ASP.NET impersonate the identity of the client making the request.

   <identity impersonate="true">

3. Add the desired Windows accounts to the SQL Server security database.

4. In the connection string used to connect to the database, specify Trusted_Connection=yes. The full connection string would look similar to the following:

   "server=(local)\VSdotNET;database=pubs;Trusted_Connection=yes"

5. Using one of the accounts that you added to the SQL Server security database, log in to the ASP.NET application. You should be able to access the data on the SQL Server database.

   Note

   If you cannot use Windows authentication in your ASP.NET application, you might still be able to take advantage of trusted connections by configuring the default ASPNET (or Network Service, in IIS 6.0) account (used to run the ASP.NET worker processes) as a SQL Server login account. Keep in mind, though, that this will allow anyone who can access any ASP.NET application to access the database according to the SQL Server permissions you have set up for the ASPNET account. The process of setting up the ASPNET account as a SQL Server login is described in Chapter 9.