Datasheet

Establishing Identity
Prior to the ISAPI extension performing any other initialization work, it ensures that the correct security
identity is established. The identity used for initialization is one of the following:
1. If the application is running from a local disk, and there is no <identity /> tag with an appli-
cation impersonation identity, then the identity of the worker process is used. Under IIS6 this
would be
NT AUTHORITY\NETWORK SERVICE. On older versions of IIS, the identity would the
local ASPNET machine account. Even if the current thread is running with other security cre-
dentials established by IIS, the ISAPI extension will temporarily revert to using the process
identity.
2. If the application has an <identity /> tag that enables impersonation, and there is an explicit
username and password configured (usually referred to as application impersonation), then ini-
tialization will run as the application impersonation identity. ASP.NET will attempt to create a
security token for this identity, calling
LogonUser in sequence for each of the following logon
types until a logon succeeds:
BATCH, SERVICE, INTERACTIVE, NETWORK_CLEARTEXT, and
NETWORK.
3. If the application was configured to run off of a UNC share, and there is no application imper-
sonation identity, initialization will run with the configured UNC credentials.
Initializing Directory Information
An ASP.NET application depends on a number of directories for the application to execute properly.
The extension will first ensure that the physical application directory exists. If the application directory
does not actually exist, or if the current security identity does not have read access to the application
directory, the extension returns an error stating that the server could not access the application directory.
Next, ASP.NET initializes the application-relative data directory information. In the v2.0 of the Framework,
ADO.NET supports the ability for applications to set application-relative path information to a data file.
This allows applications, such as ASP.NET applications, to deploy SQL Server files in an application-rela-
tive location (the
App_Data directory). The application can then reference the database using a standard
connection string syntax that does not change even when the underlying file structure is moved. For all of
this magic to work though, ASP.NET must set an application domain variable,
DataDirectory, with the
proper physical path information so that ADO.NET can correctly resolve relative directories in connection
strings. As part of application domain startup, ASP.NET determines the full physical path to the data direc-
tory and stores it in the
DataDirectory application domain variable.
Any code can query an application domain and retrieve this application domain variable just by calling
AppDomain.CurrentDomain.GetData(“DataDirectory”). Because storing physical paths could lead
to an information disclosure, ASP.NET also tells the framework to demand
FileIOPermissionAccess
.PathDiscovery
from any callers. In practice, this means any ASP.NET application running at Low
trust or higher can inspect this variable (trust levels and how they work are covered in Chapter3, “A
Matter of Trust.”)
The last major piece of directory related initialization involves the code generation directories used by
ASP.NET. Most ASP.NET applications cannot generate page output based solely on
.aspx pages that are
deployed to a web server. ASP.NET usually has to take additional steps to auto-generate classes (page
classes, user control classes, and so on) that are derived from the classes a developer works with in code-
behind files. In ASP.NET 2.0 there is a wide array of other auto-generated and auto-compiled artifacts
16
Chapter 1
04_596985 ch01.qxp 12/14/05 7:46 PM Page 16