System.Security.SecurityException: Request for the permission of type ‘System.Web.AspNetHostingPermission … failed

This Monday I was trying to deploy an ASP.net website that contained the ASP.net AJAX toolkit inside to a server running Windows 2008 R2 (64 bits) and IIS 7.5. This was the first time that I had attempted to do so on such a server.

The way in which I went about copying the site to the server (which is live on the internet) was the following:

  • I made myself a ZIP file containing all the assemblies of the site which I had precompiled with Visual Studio 2008 beforehand.
  • I placed these files inside my Skydrive and the proceeded to download the on the Windows 2008 R2 server where I wanted to deploy.
  • I unzipped the files and proceeded to place them in the C:\inetpub\wwwroot folder (as it happened I was deploying to the Default Web Site).

Now normally, what we tell our customers is that just doing an X-Copy on an ASP.net application inside IIS will just work – there is nothing else to do. I guess Monday mornings are a bit different. When trying to load the site I immediately had an error message stating that:

 
 Server Error in / Application.
 Security Exception

 Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration
file.

 Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′ failed.

 

Now there are several ways around this problem, and this problem is NOT only limited to the AJAX Control Toolkit. I ran into the same problem today when deploying an MVC application onto another Windows 2008 R2 server. But I would like to explain a bit the root cause of the problem.

Root Cause:

In my application from Monday morning I had just added a reference to the AjaxControlToolkit.dll that I had downloaded from the Microsoft ASP.net website directly. Visual Studio 2008 copied the .dll into the bin folder of my application following this addition.

However, the file was copied from another machine, and notably from another zone (the Internet Zone). Had I compiled the toolkit in Visual Studio along with my site, the newly generated .dll would have been in the same Zone (the My Computer Zone) as the rest of the .Net assemblies for my site. However this was not the case.

When copying the site to the server, these settings were preserved, and thus the assemblies from my website did not have the same trust level as the AjaxControlToolkit.dll that I had downloaded from the Internet. The Ajax Control Toolkit assembly had fewer privileges than the rest of my assemblies, and thus posed a problem.

In IIS 7.5, the default application pool is no longer Network Service , like in IIS 6 (that came with Windows 2003) and IIS 7 (that comes with Windows 2008), but rather a built in account called ApplicationPoolIdentity. This is even more restrictive than Network Service, in that required trust levels for .Net assemblies to be loaded inside an application pool have to be greater than what was permitted with Network Service.

Solutions:

The easy way out is just to go back to using Network Service as an application pool identity instead of the ApplicationPoolIdentity used by IIS 7.5. However, this undermines the new security enforcements that the IIS team has created, and kind of defeats the purpose of using IIS 7.5 as opposed to IIS 7.

The way to achieve this is to ensure that the assembly in question has the necessary privileges for the .Net Runtime to load inside the application pool when the application is started. To grant the assembly the needed trust level, the simplest way to proceed is to open a Windows Explorer and locate the assembly and then do a right click on the file.

Inside the properties window that appears you should have the same warning as highlighted in the screenshot. The solution to the problem is as simple as clicking on the Unlock button next to the warning message and all will start working as promised.

By Paul Cociuba – ASP.net Dev Support Team

Follow what I read via Linqto.me