The ASP.NET User Principal (HTTPContext.User) clearly depends upon the Authentication Mechanism that you selected in IIS 6.0 "Authenication Tab" and if you use Integrated Windows Authentication then it is dependant on the IIS impersonation token that get handed off in the extension control block via the ASP.NET 2.0 ISAPI API.  

With ASP.NET 2.0 it is always possible to get the credential of the logged on user--hence the IIS impersonate token stored in the extension control block--even with Forms Authentication by using the Request.LogonUserIdentity.  This was extremely difficult to do under ASP.NET 1.1.

So how does the IPrincipal object then get set in ASP.NET 2.0?  If you are using Windows Authentication then one of two things occur inside of ASP.NET 2.0. It either takes the impersonation token and wraps it in the WindowsPrincipal object.  Now a .NET Developer can do the standard User.IsInRole checks from inside your code-behind pages.  However, if you allow Anonymous access inside IIS, ASP.NET detects this and ignores the impersonation token and ASP.NET puts in the Windows Anonymous identity instead.  There is a boolean property on WindowsIdentity that tells you whether this token is anonymous or not.

Now what get interesting is when you use Windows Authentication and your Web Application will be acessing the File System.  In this case IIS always uses the FileAuthorizationModule and as a result the FileAuthorizationModule always uses the IIS imperonation token and ignores the WindowsPrincipal on the context.

For example if you are using "Client Impersonation" the OS thread calls into ASP.NET 2.0 runtime and the "Set Client Token" API is fired and the IIS impersonation token is passed to the Windows Authentication Module and you can do checks against NT Security Groups.  However, if you have anonymous enbled in IIS then the IIS Machine Account or Anonymous User will be swapped instead.  Now as the request continues it will hit the FileAuthorizationModule, however, regardless of all the work that has been done up to this point the FileAuthorizationModule will do an access check using the IIS impersonation token, thus completely ignores what is set on the OS thread or the User Property as it always goes back out to IIS and finds out what the impersonation token is.

To test this you can create a sample webpage. This simple webpage will identity four parts:

The User identity's name on the HTTPContext,
The OS thread identity--by default NT Authority\Network Service,
Whether WindowsIdentity is Anonymous or not,
The User identity from the impersonation token.

The code would look similar to this in the page_load event:
{

lblHttpContext.Text += "'" + User.Identity.Name + "'"
lblOSThread.Text += WindowsIdentity.GetCurrent().Name;
lblIsAnonymous+=((WIndowsIdentity)User.Identity).IsAnonymous;
lblFromToken += Request.LogonUserIdentity.Name;--this allows to get back to Impersonation token

}

So as you will see we can have three different identities in ASP.NET.

To test out the behaviour of the FileAuthorizationModule you can modify the permission on the folder that contains your webpage and place an explicit deny permission on the "Internet Guest Account".  On the "Authorization Tab" in IIS 6.0 clear the check box for "Windows Integrated Security" which will force the applicaiton to run as Anonymous User.  Now when you try to run the Webpage, you will receive an Access Denied error, however, this error comes from ASP.NET 2.0 runtime and not from IIS which is the result of FileAuthorizationModule failing authorzation and the authorization check was done against the IUSER Account.  Therefore, if you are using Anonymous user then the IUSER Account will have to be given permission at least read permission on your webpages.

For the second test go back to the "Authentication Tab" and enable the "Windows Integrated Security" and when you refresh the page you will now see the results of the webpage and you will notice the impersonate token and the HttpContext are now in sync.  The OS thread will still be the Network Service Account and Anonymous WindowsIdentity will be false. 

Therefore, you will not need to enable impersonalization for File Authentication to work as clearly behind the scene we have proven that the FileAuthenticationModule is using the impersonate token value contained in the extension control block. 

So why would you turn impersonate on then?  Because you need to flow identity off the box and you have delegation setup, or if you use an Authentication such as Basic which will give you one hop. Finally you might have an application that uses the File Object in your ASP.NET 2.0 code to perform some kind of File IO.  Now if you set <identity impersonate="true"/> in your web.config and refresh the webpage you will now see that OS thread, HttpContext, and the IIS impersonate token are now all in sync.

On a final note this should reveal that the identity of OS thread alone is not going to provide you with some kind of silver bullet security to your WebApplication.  I do not like the idea of changing the Network Service account which is already a very low privilege account for a domain account and think my Web Application will be more secure.  First the Nework Service is already one of the lowest privilege accounts on WIndows 2003 where as the domain account will be a interactive account with a password, thus actually is has higher privilege.  In fact it increases the attack surface and is now subject to account and password management. 

Therefore, security is dependent upon the OS thread, the HTTPContext the trust level of your ASP.NET 2.0 Web Application as well as the way in which your application is configured.  Finally, most importantly the input validation you put in your server side code.  There is no silver bullet but rather defence in depth using a wide variety of mechanism. 

If someone tells you something is 100% secure don't believe it as there is no such thing as perfect in this world.  Do not look for the silver bullet for security as it does not exist.  Would you do banking at a bank that uses the simpliest security mechanism to save your identity and money, probably not.  So why go with the simpliest solution and think it will give you the highest level of security.