Once you have followed the approach described in the article How to configure IIS 7.x as a step of Windows Authentication in ASP.NET, the authentication process happens automatically. In case if you are using the Visual Studio test web server and you want to access the identity information for the authenticated user in your ASP.NET application, you need to manually configure the web.config file of your ASP.NET application to use Windows. With the next configuration settings you tell ASP.NET that you want to use the Windows authentication module:
<!– Other settings are skipped. –>
In this case the WindowsAuthenticationModule HTTP module handles the AuthenticateRequest event of the application to extract the identity previously authenticated by the web server and provide it to the web application. This is true independent from the underlying version of IIS!
When you configure IIS 7.x to use Basic or Windows authentication, it actually perform a bit more configuration work, because IIS uses two HTTP modules for performing dedicated parts of the authentication process:
– The WindowsAuthenticationModule module is a native HTTP module provided by IIS 7.x and is the web server’s implementation of the authentication protocol itself. Note: For Basic authentication IIS 7.x provides native module named BasicAuthenticationModule.
– The module named only WindowsAuthentication is the managed module provided by ASP.NET.
The next picture presents these two modules:
The native modules are responsible for handling the native authentication protocol. For example, in the case of Windows authentication, the module is responsible for handling the NTLM challenge/response or the Kerberos handshake as described in the articles: How does Integrated Windows Authentication work in ASP.NET, How does NT LAN Manager Authentication work in ASP.NET and How does Kerberos Authentication work in ASP.NET.
The managed module is responsible for extracting Windows user information for the user authenticated by the native module. After extracted, the Windows user information is available in your application—as is the case on any version of IIS.
When you care configuring Windows, Basic, or Digest authentication through the IIS 7.x management console, two configurations need to be performed:
1. You have to configure ASP.NET for Windows authentication
2. You have to configure the native authentication module. The native module is configured either in the central applicationHost.config configuration of the web server, or in the web.config file of your application, depending on the feature delegation configuration of the web server. The central configuration applicationHost.config is located in the inetsrv\config subdirectory of your system directory. For example, on a 32-bit Windows version this would be \Windows\system32\inetsrv\config.
By default, IIS 7.x feature delegation is configured and your web.config inherits the settings from the central applicationHost.config configuration for the native authentication modules, such as the native BasicAuthenticationModule. That means your web.config file contains only the ASP.NET specific configuration. You configure the native module in the central applicationHost.config configuration, as follows:
<location path=”Default Web Site/WinAuth”>
<anonymousAuthentication enabled=”true” />
<windowsAuthentication enabled=”false” />
You can change your feature delegation configuration of IIS 7.x so that even these settings are stored in your application’s web.config file. This would allow xcopy deployment of your application, as any setting can be stored directly in the web.config file (if the feature configuration delegation of the target web server is configured appropriately).The next picture shows IIS 7.x feature configuration with authentication modules selected. You can find the feature configuration option when clicking the toplevel node of the tree view on the left side of the management console. Feature delegation is always configured for the whole web server, and therefore affects any web application or virtual directory.
The feature delegation for authentication modules provided by IIS 7.x natively, such as Basic, Digest, and Windows authentication, is set to Read Only. That means these settings are configured by the management console in the central applicationHost.config configuration file, and inherited by your local web.config file. It even means that configuration settings for these modules are not allowed to appear in an application’s web.config configuration. For that reason you do not find any configuration settings for these modules in your local web.config file, by default.
If you change the feature delegation configuration for these modules (or one of these modules) to Read/Write, the configuration will be included in your web.config file. That means if you configure the feature delegation for Basic authentication and Windows authentication to the setting Read/Write, the following section will be added to your web.config file. It will be added when configuring one (or both) of these authentication methods for your web application using the authentication configuration feature of the IIS 7.x management console:
<compilation debug=”true” />
<authentication mode=”Windows” />
<windowsAuthentication enabled=”true” />
The configuration of the Windows authentication HTTP module shipping with ASP.NET resides in the <system.web> section. Any configuration specific to native HTTP modules typically shipping with IIS 7.x is added to the <system.webServer> configuration section. If you configure settings for native modules in the <system.webServer> section of your web.config, even though the central feature delegation configuration is set to Read Only, you will retrieve an HTTP 500 internal server error when trying to request the page. Even the IIS 7.x management console will respond with an error message when trying to configure the affected features, as shown in the next picture and you have to manually remove invalid web.config configuration entries from your web.config file.