This is excatly what I have been doing for a few years,
A collegue and I are in the middle of writing it up as a high level design, hopefully if we can remove the corporate references we will publish this as a paper
but a few thing to note so far are
We use CIFS (windows shares on sep file server for content) while this has a performance hit, separating web server from content opens up a whole new world of possibilities for scale out and DR situations
Each web site should have its owns app pool (this is now standard on IIS7)
Then restrictions are applied via ASP.NET trusts which enforce these restrictions on each application (each application will run under medium trust which prevents OS access and file system access outside the applications folder). This means you cannot use the ADO.NET managed OLE DB data provider to access databases. However, you can use the managed SQL Server provider to access SQL Server databases.
EventLogPermission is not available. ReflectionPermission is not available. This means you cannot use reflection.
RegistryPermission is not available. This means you cannot access the registry.
WebPermission is restricted. This means your application can only communicate with an address or range of addresses that you define in the <trust> element.
FileIOPermission is restricted. This means you can only access files in your application's virtual directory hierarchy. Your application is granted Read, Write, Append, and PathDiscovery permissions for your application's virtual directory hierarchy.
Each application pool runs under its own Active Directory identity. This is granted minimum server access and read-only access to its own code area. Each application is run inside a dedicated application pool in web server memory, again under the same identity
using unique ID for each sites uses a LOT of desktop heap
see http://support.microsoft.com/kb/831135
and http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx
SQL Database access / authentication will be achieved using a ‘trusted’ connection with the Worker process identity. As every application container has a dedicated domain account, this can be locked down to just code within the container. Using this method no extra UserId or password is required to connect to the database. Eliminating the use and need for any application accounts which can be used in an anonymous manner by the Application Support Groups or inadvertently displayed to end users during an error condition.
The application access to the SQL DB will only have Data_Reader and Data_writer
Where Possible the Application support staff only have DDL_admin , Data_Reader and Data_writer to the database as standard, while this may seem restrictive, it prevents them change various database parameters someone with DBO can, such as logging mode
ASP.NET caches pre-compiled ASPX code for speed. The default location of this cache is moved to the local data drive (typically H:) and minimal NTFS permissions set to ensure access is only available to appropriate worker processes. , ( i believe this is iis_wpg : create and create_owner:full control) this allows each app pool to create its cache and managed it, but it cannot be acess by any other application
To ensure the web as a service infrastructure is fully scalable, the touch points between the application and the infrastructure must be kept to a minimum and fully defined and controlled by the infrastructure. All touch points must be defined in virtual or alias terms.
- File Path : uses DFS
- Database connections : FQDN DNS Name
- Downstream service connectivity (web services) : FQDN DNS Name
- SMTP : All routed by Localhost