When code runs within a custom WSS component, such as a Web Part or application page, it is important that you distinguish between two different security and authorization subsystems. There is both a WSS security context and a Windows security context. Let us provide a little more background to illustrate the difference.
As you know, WSS uses a user security token created by either Windows authentication or forms authentication to establish its own security context. This WSS security context is used to conduct access control checks in internal WSS objects such as sites, lists, and items. However, just because WSS adds it own authorization layer doesn't mean that the Windows authorization layer goes away.
The WSS components you write, such as Web Parts and application pages, often must access external resources. Access control to these external resources is controlled not by WSS, but instead by the Windows operating system itself, which means that you also must be aware of the current Windows security context as well as the WSS security context.
The standard web.config file for WSS Web applications has the following entry:
By setting the impersonate attribute to true, WSS instructs the ASP.NET runtime to process all requests under the Windows security context of the current user. When you write code for a Web Part or application page that attempts to access an external resource, such as a file system resource, database call, or Web service call, it runs under the impersonated Windows identity. This enables the Windows authorization subsystem (local or remote) to determine whether it should grant or deny access.
Understanding the Windows security context is fairly straightforward when you are using the default Windows Authentication provider because its identity is synchronized to the same user account as the identity of the WSS security context. However, things aren't so obvious when you are using forms authentication. Because forms authentication doesn't involve authenticating against a Windows account, the Windows security content takes on the identity of the IUSR_MACHINENAME account, or the account specified in the Authentication Methods dialog box of IIS (the same dialog box that enables IIS anonymous access).
Please note that forms authentication impersonates the anonymous access Windows account. As credentials leave WSS and transition to the Windows authentication protocol, this anonymous user account is used.
623c02bc-e73d-4ffc-b929-56a0d55c425e|0|.0
SharePoint