One of the really great capabilities brought to us by .NET is its configuration architecture. More then ever before, it is really easy to establish and use application, assembly, and web configuration files. Unfortunately, people often forget that .NET uses a Cascading configuration architecture. This means there are many levels of configuration that are combined at runtime to define a resulting configuration for your .NET application. Configurations are usually a combination of your applications configuration file (Ex. App.Config/Web.Config), a central machine-level configuration file (Ex. %WINDIR%\Microsoft.NET\Framework\v2.0.50727\CONFIG\Machine.Config), and an enterprise configuration file which may be distributed via Active Directory. Understanding the relationships between the different configuration files is important since they all have the potential to affect your products behavior. In some cases you receive the Union of configuration elements while in others you receive the Intersection of configuration elements.
Web Applications are affected by another configuration file (Ex. %WINDIR%\Microsoft.NET\Framework\v2.0.50727\CONFIG\Web.Config) that defines the default behavior of ASP.NET Applications. This is a great example of a configuration file that affects your applications security and performance. Consider the following example...
<?xml version="1.0" encoding="utf-8"?>
<!-- the root web configuration file -->
<add name="OutputCache" .../>
<add name="Session" .../>
<add name="WindowsAuthentication" .../>
<add name="FormsAuthentication" .../>
<add name="PassportAuthentication" .../>
<add name="RoleManager" .../>
<add name="UrlAuthorization" .../>
<add name="FileAuthorization" .../>
<add name="AnonymousIdentification" .../>
<add name="Profile" .../>
<add name="ErrorHandlerModule" .../>
<add name="ServiceModel" .../>
In the extract above you can see there are a number of modules that are running agaist your application(s) that you may not need. Generally speaking, if you have components enabled then they increase your attack surface and hamper security.
- If you are hosting an Internet solution using Forms authentication then you probably don't need the Passport or Integrated Security modules. Conversely, if you are hosting an Intranet application using integrated security such as Active Directory then you probably don't need the Passport or Forms Authentication modules.
- If you are not developing Web Parts or using any user profiling support then you can disable the Profile Module.
- If you have developed custom modules to manage authentication cookies or hydrate user principle objects (Ex. HttpContext.Current.User) then you probably don't need the RoleManager module. This is common when you are developing custom authentication/authorization providers and/or creating cross-domain or intra-domain SSO solutions.
If you review these files you will find there are a number of configuration elements that any applications don't need (Ex. Mobile application support, web parts files, handlers, etc...). If you are concerned about application performance or security, make sure you take the time to review these files and make sure you have a good understanding of what is present. Enjoy...
Note: There is an edge-case for configuration cascading. In some solutions; like pluggable thick clients; A configuration can be constructed and passed to AppDomains and Processes created by your application at runtime.