Best Practices for ASP.Net Application Production deployment

1. Use trusted SQL connections with integrated authentication

To make the production environment more secure, one of the things we looked into was securing the database connection information between the web server and SQL server.

2. Use the Aspnet_setreg.exe utility to encrypt the connection string and store it in the registry.

How to use this utility – Refer http://msdn.microsoft.com/en-us/library/aa302406.aspx

3. Using DPAPI (Data Protection application programming interface) to secure the connection string

How to use this DPAPI – Refer http://msdn.microsoft.com/en-us/library/aa302403.aspx

4. Set retail=”true” in your machine.config in the production server

<configuration>

<system.web>

<deployment retail=”true”/>

</system.web>

</configuration>

It will force the ‘debug’ flag in the web.config to be false, disable page output tracing, and also force the custom error page to be shown to remote users rather than the actual exception or error message. Refer http://mossjenkins.blogspot.com/2009/12/deployment-element-force-debug-flag-in.html

5. Create a new application pool for your site

When setting up your new site for the first time do not share an existing application pool. Create a new application pool which will be used by only by the new web application.

6. Set the memory limit for your application pool

When creating the application pool, specifically set the memory limit rather than the time limit which is set by default. Asp.net has a good whitepaper (http://www.asp.net/learn/whitepapers/aspnet-and-iis6/ ) which explains the value of this: By default IIS 6.0 does not set a limit on the amount of memory that IIS is allowed to use. ASP.NET’s Cache feature relies on a limitation of memory so the Cache can proactively remove unused items from memory. It is recommended that you configure the memory recycling feature of IIS 6.0.

7. Create and appropriately use an app_Offline.htm file

There are many benefits to using this file. It provides an easy way to take your application offline in a somewhat user friendly way (you can at least have a pretty explanation) while fixing critical issues or pushing a major update. It also forces an application restart in case you forget to do this for a deployment.

8. Develop a repeatable deployment process and automate it

It is way too easy to make mistakes when deploying any type of software. This is especially the case with software that uses configuration files that may be different between the development, staging, or production environments. I would argue that the process you come up with is not nearly as important as it being easily repeatable and automated. You can fine tune the process as needed, but you don’t want a simple typo to bring a site down.

9. Build and reference release versions of all assemblies / Version Your Assemblies

In addition to making sure ASP.NET is not configured in debug mode, also make sure that your assemblies are not debug assemblies. There are of course exceptions if you are trying to solve a unique issue in your production environment … but in most cases you should always deploy with release builds for all assemblies

Make sure you have a solid versioning policy in place. You can apply a version stamp using the AssemblyVersion attribute at compile time, for example:

[assembly: AssemblyVersion(”1.0.12.34″)]

It’s usually best to apply the same version number to all the assemblies in an application during the build process.

10. Give Assemblies Strong Names

An assembly is the smallest unit of versioning, security, deployment, version control and reusability of code in .NET. Each assembly contains:

Assembly Identity information (name, version, etc.)

Manifest and metadata information

MSIL code

Type and security information

Resources

An assembly with a strong name can be uniquely identified by a combination of its assembly version, culture information, and a digital signature.

You can create a strong name for your assembly using the strong name utility (sn.exe) provided by the .NET framework.

The utility requires you to provide the name of a strong name key file as a parameter. The resulting file is called a “strong-named” file. You can use the sn.exe tool from the command line to create a strong-named key file as follows: sn –k MyCompany.snk,

Creating a Strong-Named Key File: Running the sn.exe file from the command line as shown creates a strong-named key file.

When you create a project in Visual Studio, you’ll see a default file called AssemblyInfo.cs that you can use to specify the related attributes.

Here is how you can specify the strong name information in the AssemblyInfo.cs file.

[assembly: AssemblyCulture(”")]

[assembly: AssemblyVersion(”1.0.0.0″)] [assembly: AssemblyKeyFile(”MyCompany.snk”)]

11. Obfuscate Your Assemblies

It’s good practice to obfuscate your assemblies before you deploy them; obfuscation makes assemblies more difficult to decompile, and impedes reverse-engineering efforts, thus protecting your source code to some degree from potential threats. In addition, obfuscation reduces the size of your assemblies; thereby boosting the application’s performance.

12. Deploy Shared Assemblies to the GAC

You should deploy assemblies used by multiple applications to the Global Assembly Cache (commonly known as the GAC), which allows them to be shared by all applications that use the assembly. Deploying an assembly to the GAC improves its load performance compared to assemblies not located in the GAC. Strong-named assemblies load faster from the GAC because they’re verified at install time rather than at runtime—the .NET framework skips verification at runtime for GAC-loaded assemblies. The runtime always checks strong-named assemblies to verify their integrity. .NET refuses to load assemblies that are not trusted or that may have been tampered with. Note that you must provide a strong name for assemblies you want to install in the GAC.

You place an assembly into the GAC using the GACUtil tool. The following command places MyProject.dll into the GAC, thus making it globally accessible.

GacUtil /i MyProject.dll

To uninstall the assembly from the GAC, you would use: GacUtil /u MyProject.dll

Note that you can even make your strong-named assembly globally accessible without placing it in the GAC. For this, you need to deploy your assembly using the XCOPY command.

13. Pre-Compile Your Sites

You can use the ASP.NET 2.0 Pre compilation feature to minimize the initial load time of your web pages, and avoid having to deploy your source code to the server. Pre compilation is a great new feature that can detect and provide warnings about any compilation failure issues. It lets you deploy applications without having to store any source code on the deployment server. Pre compilation can both reduce application response time and improve performance. Learn more about pre compile http://www.devx.com/dotnet/Article/34418/0

14. Reduce File Sizes

It’s generally a good practice to squeeze extra white space and other unwanted characters from your web pages, script, and style sheets to minimize response size. You can also compress the rendered response to reduce network bandwidth and improve performance using IIS compression. Although there is a slight performance penalty for using IIS compression (compression requires extra processing), it’s still a good practice, because the performance penalty is negligible compared to the huge benefit you get from it; compression can reduce network bandwidth by nearly 50 percent! This article provides more information on file size reduction and IIS HTTP compression.

REF MSDN

Deployment Element - force the ‘debug’ flag in the web.config to be false

To disables ASP.NET certain configuration settings such as trace output, custom errors, and debug capabilities.

Set retail=”true” in your machine.config in the production server

<configuration>

<system.web>

<deployment retail=”true”/>

</system.web>

</configuration>

It will force the ‘debug’ flag in the web.config to be false, disable page output tracing, and
also force the custom error page to be shown to remote users rather than the actual exception or error message

Configurable Locations Machine.config Requirements IIS 6.0 .NET Framework 2.0 Visual Studio 2005
Note: Important

This value can only be set at the machine level, not at the application level, so do it only Production server.

REF MSDN

WIF - Windows Identity Foundation

Identity Challenges

Most developers are not security experts and many feel uncomfortable being given the job of authenticating, authorizing, and personalizing experiences for users. It’s not a subject that has been traditionally taught in computer science curriculum, and these features tend to be ignored until late in the software development lifecycle.
It’s not surprising nowadays to see a single company with tens or hundreds of Web applications and services, many of which have their own private silo for user identities, and most of which are hardwired to use one particular means of authentication. Developers know how tedious it is to build identity support into each application, and IT professionals know how expensive it is to manage the resulting set of applications.
One very useful step toward solving the problem has been to centralize user accounts into an enterprise directory. Commonly it’s the IT professional that knows the most effective and efficient way to query the directory, but today the task is typically left up to the developer. And in the face of mergers, acquisitions, and partnerships, the developer might be faced with accessing more than one directory, using more than one API.
In the Microsoft .NET Framework, there are lots of different ways of building identity support into an application, and each communication framework treats identity differently, with different object models, different storage models, and so on. Even in ASP.NET, developers can get confused about where they should look for identity: should they look at the HttpContext.User property? What about Thread.CurrentPrincipal?
The rampant use of passwords has lead to a cottage industry for phishers1. And with so many applications doing their own thing, it’s difficult for a company to upgrade to stronger authentication techniques.

A Better Solution

One step toward solving these problems is to stop building custom identity plumbing and user account databases into every new application that comes along. But even developers who rely on a central enterprise directory still feel the pain of mergers, acquisitions, and external partnerships, and may even be blamed for poor performance that is actually due to another application bogging down the directory with inefficient queries. The claims-based solution described in this paper does not require developers to connect to any particular enterprise directory in order to look up identity details for users. Instead, the user’s request arrives with all of the identity details the application needs to do its job. By the time the user arrives with these claims, the user has already been authenticated, and the application can go about its business without worrying about managing or finding user accounts.
Factoring authentication out of applications leads to many benefits for developers, IT professionals, and users. Simply put, there are less user accounts for everyone to manage, and the resulting centralization of authentication makes it easier to upgrade to stronger authentication methods as they evolve, and even federate identity with other platforms and organizations.
This paper will help you, as a developer, to understand the claims-based identity model and take advantage of it using Windows Identity Foundation (WIF), the new framework from Microsoft that is focused on identity.

What is Windows Identity Foundation?

Windows Identity Foundation (WIF) is a set of .NET Framework classes. It is a framework for implementing claims-based identity in your applications. By using it, you’ll more easily reap the benefits of the claims-based identity model described in this paper. Windows Identity Foundation can be used in any Web application or Web service that uses the .NET Framework version 3.5 SP1.
WIF is just one part of Microsoft’s Identity and Access Platform software family that implements the shared industry vision for an interoperable Identity Metasystem. Active Directory Federation Services (ADFS) 2.0 (previously known as “Geneva” Server), Windows CardSpace 2.0, and Windows Identity Foundation (previously known as “Geneva” Framework) form the core of Microsoft’s new claims based access strategy. You can refer to the Identity and Access Management web site for more information about AD FS and CardSpace components. Also, the white paper “Claims-based Identity for Windows“ provides an overview of these three components. As of this writing, the RTW of Windows Identity Foundation and Beta 2 releases of the other two products are available for download.

Learn detail about WIF