Understanding IIS 7.0 Identity Configuration: Application Pool vs. Website Identity Explained for Developers


2 views

In IIS 7.0, identity configuration occurs at two distinct layers with different security implications:

  1. Application Pool Identity: Governs worker process execution context (w3wp.exe)
  2. Website Identity: Controls impersonation for individual requests when enabled

The application pool identity (set in applicationHost.config) defines the base security context:

<applicationPools>
  <add name="MyAppPool" managedRuntimeVersion="v4.0">
    <processModel identityType="SpecificUser" 
                  userName="APPPOOL\CustomUser" 
                  password="EncryptedPasswordHere"/>
  </add>
</applicationPools>

Website-level identity requires explicit impersonation configuration in web.config:

<system.web>
  <identity impersonate="true" 
            userName="WEBSITE\WebUser" 
            password="ClearTextPassword"/>
</system.web>

Consider these execution scenarios:

  • Default Mode: All requests use application pool identity
  • Impersonation Enabled: Each thread temporarily switches to website identity
  • Authentication Interaction: Windows Authentication modifies this behavior

For a secure file access scenario:

// Without impersonation (uses app pool identity)
File.ReadAllText(@"C:\AppData\file.txt"); 

// With impersonation (uses website identity)
using (WindowsIdentity.Impersonate(webIdentityToken))
{
    File.ReadAllText(@"C:\AppData\file.txt");
}
  • Always run application pools under least-privilege accounts
  • Prefer application pool identity for most scenarios
  • Only use website-level impersonation when strictly necessary
  • Never store plaintext passwords in web.config

Diagnostic PowerShell commands:

# Check current execution context
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

# Verify IIS configuration
Import-Module WebAdministration
Get-ItemProperty IIS:\AppPools\MyAppPool | Select-Object processModel

In IIS 7.0, the security model introduces a clear separation between application pool identities and website identities. The application pool identity serves as the worker process identity (w3wp.exe), while website identity (when configured) controls the thread impersonation level during request processing.

// Typical applicationHost.config snippet
<applicationPools>
    <add name="MyAppPool" autoStart="true" managedRuntimeVersion="v4.0">
        <processModel identityType="NetworkService" />
    </add>
</applicationPools>

The key operational differences manifest in these scenarios:

  • File System Access: Application pool identity needs NTFS permissions for worker process
  • Impersonation Context: Website identity controls thread security token during execution
  • Authentication Flow: Anonymous authentication uses application pool identity by default

To demonstrate the relationship, let's examine web.config settings:

<system.web>
    <identity impersonate="true" userName="DOMAIN\WebUser" password="encrypted" />
</system.web>

<system.webServer>
    <security>
        <authentication>
            <anonymousAuthentication enabled="true" userName="" />
        </authentication>
    </security>
</system.webServer>

When permissions conflict occurs, use Process Monitor to verify:

  1. Worker process startup credentials (application pool identity)
  2. Thread token during request processing (impersonated identity)
  3. Final effective permissions (intersection of both identities)

For scenarios requiring specific identity switching:

// C# code to demonstrate runtime identity switching
WindowsIdentity.RunImpersonated(userToken, () => 
{
    // Code executed under impersonated context
    File.WriteAllText(@"\\server\share\file.txt", "content");
});

Remember that IIS 7.0's Integrated Pipeline mode affects how identities flow through the request lifecycle. Classic mode maintains separate identities for ISAPI and managed code.