Mario Briana Weblog : Securing asp.net applications in an hosted environment using impersonation
Microsoft released the ASP.NET 2.0 Hosting Deployment Guide in October 2005. It talks about the security concepts like trust levels in and hosted ASP.NET environment. It recommends Medium Trust Level in a hosting environment. This document is a “must read” for every hoster.
In this blog entry I want to give you a hint how impersonation can be used in a hosted environment. This information is intended to be additional information and is complimentary to the document mentioned above. You don’t need this information if you’re running in mediume trust.
There are several security principals involved when running/hosting asp.net. There is the notion of Application Pool identities where it is specified under which security context the ASP.NET application (the IIS worker process) is running. For scalability reasons in a shared hosting environment this means you will put a lot of Webs running under the same application pool. But if the hoster allows the customer to upload ASP.NET code it would be possible to actually read the content of directories of other users on the same server using System.IO namespace objects.
So this brings impersonation in the picture. If you choose to setup impersonation in you web.config file ASP.NET will impersonate with the user specified or use the principal specified in IIS Administrator (inetmgr.exe). The appropriate setting would be
<system.web>
<identity impersonate=“true“ />
But what if the customer has the right to edit the web.config file and set impersonate=”false” ?
I would encourage to use the machine.config file – where the customer will not have access to and specify the following
<system.web>
<identity impersonate=“true“ lockItem=“true“ />
The lockItem setting will cause an error when the customer overwrites the impersonate setting in the web.config file to false.
The attached sample app can be used to check this implementation.
I created a principal for the application pool and another one for the impersonation of the customer. I created a directory c:\web and c:\web\customer0 plus c:\web\customer1. The application pool user has read access to c:\web and these rights will be inherited at sub directory level. The customer principal has modify rights to the customer1 directory. If this is set up correctly you can play arround with these settings. If you use them correctly you should end up with the right behaviour.