Sogeti Phoenix Blogs

I'm a product developer, even though I'm a consultant.  I try to approach all of my projects from that perspective, even though I may not be with them for years, I try to think about how they'll be maintained, enhanced, and deployed when I'm no longer with a project.  One of the hardest things to consider when developing software that will later be deployed is how to plan for the security settings in the deployment environment.

Each deployment environment is different and provides its own challenges.  I've been in environments where users all have administrative rights for their machines.  I've been at a client site before where users were not allowed to write to their Windows registry, even their user settings, and all Internet access went through a proxy server that was locked down.  These are the things that you have to consider when planning for deploying software into production environments.

When I start building a new software application from scratch, I usually begin by working with the security settings.  Typically, my approach is that I plan for the minimal security settings that I need, so I will start off by creating my own security sandbox.  If I'm developing a desktop application, I'll go into the .NET security policy settings and create a code access security policy that gives me no security rights, except for executing.  Then, as I build more and more features, I'll selectively turn on those security settings that I need for the new feature to work.  I'll also make the decision at that time as to what's necessary functionality and what's optional functionality, so I can implement degrading functionality as necessary to still get my application to run in stricter application environments.

One application type that I honestly haven't been using a sandboxed approach for are ASP.NET websites and web applications.  I've been lucky so far, in that all of the environments that I've developed web applications for have let me run in full trust, but I understand that may not be desirable or necessary in all cases.  I know of quite a few hosters out there that require websites run in medium trust.  My hoster doesn't, but I understand why some do.  I also see this as a problem that pops up sometimes when people try to use pre-packed web applications such as Community Server and BlogEngine.NET in a medium trust environment.  Reflecting on this, I realize that if I build a website in full trust mode, I have no idea how it's going to perform in a medium trust environment, or if I'm doing all that I need to do to make sure that my assemblies will run in a restricted environment.

I think that it's good every now and then to take a step back, look around at other projects, see what kinds of problems that they are having, and look to see what you can do to improve your own development process.  This reflection has made me understand that I need to start sandboxing myself when it comes to building ASP.NET websites and web applications, and it's time to start developing for medium trust environments.

Fortunately, ASP.NET comes preconfigured with the security settings for the medium trust environment.  All that you have to do in order to switch your website into medium trust is add the following to your Web.config file:

   1: <configuration>

   2:     <system.web>

   3:         <trust level="Medium" originUrl=""

   4:             processRequestInApplicationTrust="true"/>

   5:     </system.web>

   6: </configuration>

For more information about developing ASP.NET applications in medium trust, read these articles:

How To: Use Medium Trust in ASP.NET 2.0
• Running ASP.NET in Medium Trust
• Hosting ASP.NET Applications in Medium Trust