Datasheet

For example, one question that arises when running global.asax is what happens if client imperson-
ation is in effect? To help frame this security problem, first a few terms should be discussed because
using the shorthand for security contexts in ASP.NET is a lot faster than always calling out the
<iden-
tity />
element and its settings.
Client impersonation means that all of the following are true:
❑ Integrated Windows Authentication, Digest Authentication, Basic Authentication or some type
of Certificate Mapping is configured for the ASP.NET application.
❑ The ASP.NET application’s
<authentication /> element has the mode attribute set to
Windows.
❑ The ASP.NET application’s
<identity /> element has the impersonate attribute set to true.
❑ The ASP.NET application’s
<identity /> element does not have the username or password
attributes set.
An example of configuration settings that correspond to client impersonation is:
<identity impersonate=”true” />
<authentication mode=”Windows”/>
Application impersonation means that all of the following are true:
❑ The ASP.NET application’s
<identity /> element has the impersonate attribute set to true.
❑ The ASP.NET application’s
<identity /> element explicitly sets the values for the username
and password attributes.
The value of
<authentication /> does not have any bearing on whether application impersonation
is in effect. Within ASP.NET, code paths that look for the application impersonation identity will ignore
any client credentials when an explicit application impersonation identity has been configured.
An example of configuration settings that correspond to application impersonation is:
<identity impersonate=”true” userName=”[e-mail]”
password=”pass!word1”/>
UNC identity means that the ASP.NET application content is deployed remotely on a UNC share. When
you configure an application to run on a UNC share in IIS, the IIS MMC prompts you to specify the way
to handle credentials for the UNC share. In most web server environments an administrator supplies a
unique username and password that have been granted read access to the remote share.
So, how does this all affect
Application_Start? The underlying thread identity that ASP.NET uses
when running
Application_Start can only be that of the process identity, application impersonation
identity, or the UNC identity. If client impersonation has been configured for an application, it is ignored
while the
Application_Start event is executing. This makes sense because if client impersonation
were honored during
Application_Start, you would end up with completely random behavior for
any security-dependent operations running inside of the event. For example, if the client credentials
were honored and a domain administrator just happened to be the first user that triggered application
domain startup, everything might work properly. Yet if the website was recycled in the middle of the
26
Chapter 1
04_596985 ch01.qxp 12/14/05 7:46 PM Page 26