[This is preliminary documentation and subject to change]

# Passing Security Context

Windows establishes a security context for each logged on user. When IIS receives a request from a client, it authenticates the request and then impersonates the client. While IIS is impersonating the client, IIS operates within the confines of the authenticated client's security context. This security context may change during the various stages of request processing, depending on the nature of the client request. The following diagram illustrates the various security contexts that may play a part in request processing.

The security context of the IIS process (inetinfo) is known as LocalSystem. However, when IIS is processing a client request, it will impersonate the context of the client that generated the request. If the client is authenticated with the Anonymous authentication scheme, the security context will be IUSR_machinename for in process applications and IWAM_machinename for applications running in an isolated process. If the client is authenticated with any other authentication scheme, the security context will map to the individual account of the client.

If you create an instance of a COM component with ASP, the COM component will inherit the security context of the .asp file that created it. When IIS destroys the component instance, it will also use the security context of the .asp file in most instances. There is at least one case, however, where this will not occur. If the COM component has been given session scope (that is, Session("mysesscomp") = Server.CreateObject("MyComps.Comp1")), and the session times out before the component is destroyed, IIS will try to destroy the component by using its own security context (LocalSystem) rather than the context of the client that accessed the .asp file. If the component has accessed secured resources that it has not released, this scenario can have side effects throughout the system.

© 1997-2001 Microsoft Corporation. All rights reserved.