February 25, 2021
Hot Topics:

IIS 6.0 and ASP.NET - XML, Security, and More

  • By Thiru Thangarathinam
  • Send Email »
  • More Articles »

Security in IIS 6.0 and ASP.NET

Because an ASP.NET Web application runs on top of the IIS Web server, every ASP.NET application can leverage the security options provided by IIS. When the user requests a specific resource on the system, that request is routed to IIS. IIS authenticates the user requesting the resource and then hands off the request and the security token for the authenticating the user to the ASP.NET worker process. The ASP.NET worker process then decides whether to impersonate the authenticated user. If impersonation is enabled in the web.config file, the ASP.NET worker process impersonates the authenticated user. Otherwise, the thread runs under the ASP.NET worker process identity.

In the world of ASP.NET, authentication is implemented via Providers. Providers are basically classes that contain static methods to assist ASP.NET in authenticating requests from clients. ASP.NET provides built-in support for user authentication through several authentication providers.

  • Forms-based authentication—The application is secured by using a custom authentication model with cookie support.
  • Passport authentication—Passport authentication is part of Microsoft's .NET strategy for authenticating users in Internet applications. Passport is a single sign on (SSO) service, which allows registered users to access participating Web sites with a single user ID and password. Microsoft Passport servers maintain user identity information and provide an authentication mechanism.
  • Windows authentication—The application is secured by using integrated Windows authentication where access to a Web application is allowed only to those users who are able to verify their Windows credentials.
  • Custom authentication—If none of the existing authentication modules satisfy your requirements, the .NET Framework allows you to implement your own custom authentication strategy.

One of the new features in IIS 6.0 is the support for .NET Passport integration. The next section provides you with an overview of the support IIS 6.0 provides for authenticating users via .NET Passport.

.NET Passport Integration with IIS 6.0

The integration of .NET Passport with IIS 6.0 enables .NET Passport authentication services from within the core Web server. .NET Passport 2.0 uses interfaces provided by standard Passport components, such as Secure Sockets Layer (SSL) encryption, HTTP redirects, and cookies. By using the .NET Passport, you can make your Web sites and applications available to the entire .NET Passport customer base, which is composed of over 150,000,000 users, without having to deal with account management issues such as password expiration or provisioning. After a user has been authenticated, the user's .NET Passport Unique ID (PUID) can be mapped to an account in Microsoft Active Directory services—if such provisioning has been configured for your Web sites. A token is created by the Local Security Authority (LSA) for the user and set by IIS 6.0 for the HTTP request. You can use this security model for authorization based on Active Directory users. These credentials can also be delegated by using the new Constrained Delegation feature that is supported in Windows Server 2003. You can enable .NET Passport authentication by selecting the Default Web Sites-> Virtual Directory Name from the IIS manager and selecting Properties from the context menu. In the Properties dialog box, select the Directory Security tab and then click the Edit command button to bring up the following dialog box.

In the preceding dialog box, once you select .NET Passport Authentication as the authentication mechanism, the Default domain text box will be enabled, allowing you to specify the domain name.

Configuring Directory Permissions from IIS Manager

You also can set file permissions for the file system directory by using the Permissions option that is available from the context menu when you right-click on the virtual directory.

By using this new feature, you can set directory permissions from within the IIS manager itself.

Impersonation behavior in ASP.NET applications

Impersonation allows a worker process to run under security credentials that are different from its base identity. As discussed in Part 2 of this article, the identity for an ASP.NET Web application is configured at the application pool level. However, there are times when you might want to configure the ASP.NET Web application to execute using the credentials of the authenticated user or a specific user account. You can do this by enabling impersonation in the ASP.NET application.

Unlike ASP applications (where impersonation is enabled by default), in ASP.NET you need to explicitly configure the impersonation behavior for ASP.NET applications. By default, impersonation is disabled in ASP.NET. If you enable impersonation, ASP.NET receives the security token to impersonate from IIS. You can control the impersonation behavior by using the identity element in the web.config file. You have the following three options when specifying this setting:

Impersonation is disabled

This is the default setting. In this case, 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 token of the application worker process is NetworkService. To disable impersonation, set the impersonate attribute of the identity element to false.

<identity impersonate="false" />

Impersonation is enabled

In this instance, ASP.NET impersonates the token passed to it by IIS, which is either an authenticated user or the anonymous user account (IUSR_machinename). For backward compatibility with ASP, you must enable impersonation. To enable impersonation, modify the identity element in the web.config file to look like the following:

<identity impersonate="true" />

Impersonation is enabled and a specific impersonation identity is specified

In this instance, ASP.NET impersonates the token that is generated using the configured identity. In this case, ASP.NET does not use the token of the authenticated client except when performing access checks.

To enable impersonation and specify an impersonation identity, modify the web.config file to look like the following:

<identity impersonate="true" name="domain\user"
                             password="password" />

An example ASP.NET application that demonstrates impersonation

To demonstrate the impersonation behavior, let us create a very simple ASP.NET application named ImpersonationExample. Once the project is created, we will enable Integrated Windows authentication for the Web application using the IIS manager. This is illustrated in the following screenshot.

After that, add the following lines of code to the Page_Load event of the default web form.

private void Page_Load(object sender, System.EventArgs e)
  Response.Write("Credentials under which the ASP.NET application
     executing is : <b>" + WindowsIdentity.GetCurrent().Name
                         + "</b><br>");
  Response.Write("Name of the logged on user name is  :<b>" +
    Context.User.Identity.Name + "</b><br>");

If you execute the preceding code, you will see an output that is somewhat similar to the following. In the output, it is important to note that the ASP.NET application runs using the credentials of NetworkService account.

Click here for a larger image.

Let us modify the web.config file by adding the identity element under the system.web element.

<identity impersonate="true"/>

Now if you execute this code, you will see that the ASP.NET application executes using the credentials of the logged-on user.

Click here for a larger image.


In this series of articles on IIS 6.0 and ASP.NET, we understood the new features of IIS and demonstrated how these features contribute to the increase in reliability, scalability, and security of your ASP.NET applications. We also looked at how XML-based storage is used to store the IIS configuration settings that provides for a number of enhancements when compared to the previous versions of IIS. Finally, we also understood the new security model of IIS 6.0, in which, by default, the code runs using the fewest possible privileges. All these new features of IIS 6.0 in conjunction with the seamless integration of IIS and ASP.NET should make a compelling case for the migration of your existing Web servers from IIS 5.0 to IIS 6.0.

About the Author

Thiru has six years of experience in architecting, designing, developing and implementing applications using Object Oriented Application development methodologies. He also possesses a thorough understanding of software life cycle (design, development and testing).

He is an expert with ASP.NET, .NET Framework, Visual C#.NET, Visual Basic.NET, ADO.NET, XML Web Services and .NET Remoting and holds MCAD for .NET, MCSD and MCP certifications.

Thiru has authored numerous books and articles. He can be reached at thiruthangarathinam@yahoo.com.

# # #

Page 2 of 2

This article was originally published on August 18, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date