Category: ASP.NET

In my previous post I showed that ASP.NET application goes through 3 security context levels and discussed the first one :

1. IIS Level
2. ASP.NET worker process level
3. ASP.NET pipeline level

In this post, I will talk a little on ASP.NET worker process level, before starting I would like to point out the development environment we use, the development machines run windows XP and IIS 5.1, the server runs windows server 2003 on IIS 6 of course, so I need to point out the differences. [more]

2- The Worker Process Context :

IIS 5

After IIS authentication, if the request is for ASP.NET (.aspx, .ashx, ….etc. ) the IIS thread sends the request to aspnet_isapi.dll which starts the aspnet_wp worker process. This worker process runs under the ASPNET account. ASPNET account is a local account created when the .NET Framework is installed. ASPNET has minimum privileges to be able to run an ASP.NET application which you can know in this article :
from http://www.microsoft.com/technet…..mspx
You can change the identity from ASPNET to other one using the section in machine.config

	<processModel userName="xxx" password="XXX"/>
	

IIS 6

In IIS 6, the model is changed where the incoming request in first queued to the application pool that the website is hosted in, then the w3wp.exe worker process servers it.
This time rather than the ASPNET account a new one was introduced named NETWORK SERVICE with the same minimum privileges. To change the this account from the IIS manager, the Application Pool properties > Identity Tab as shown in figure, Read More on Application Pools.

Next in the worker process, one of the pooled threads picks the request. This thread will by default inherit the identity of the worker process itself defined before, this happens when impersonation is disabled, while if it is enabled the thread will take the identity handed by the IIS, shown in the previous post.

To enable impersonation use this section in web.config

<identity impersonate="true"/>

read more about it on How to implement impersonation in an ASP.NET application

Note: If the impersonation is enabled, the worker process account doesn't change, but impersonation is only used with the code executed in the page, where any database access or file access uses the impersonated account.

Next the last security context level is handled the request and executes, next post I will show preliminary information on the ASP.NET pipeline level.

Lately at SCS I have been assigned to build up the security module and related tasks in the Real Estate Management System we are building. So I decided to share what I have learned in this past period and of course to hear from the community to find optimal solutions for the scenarios I worked with, all what I write here might be repeated but I will share it anyway. [more]

In this part, I will show some important basic points that should be clear to everyone before implementing asp.net security tasks.

Looking at any web application, the security is a matter of users/passwords/roles/groups… etc. While ASP.NET provides more mechanisms for authentication and authorization that work with the Operating system,IIS and .NET framework classes. So the ASP.NET application runs through these 3 levels.

• IIS Level
• ASP.NET worker process level
• ASP.NET pipeline level

So, the Big Question, What is the Identity that runs my application ?

First, When an IIS web server machine receives an ASP.NET request, the IIS assigns it to one of the threads pooled in it, IIS runs under the SYSTEM account which has all the powers in a Microsoft Windows operating system. You can read extra information in the ASP.NET Application Life Cycle Overview article on the msdn.

Next, the 3 security levels run on the request one after the other.

1- The IIS thread context : the identity of this thread is determined according to the settings of the website in the IIS which has one of the following settings:

1. Basic authentication prompts the user for a user name and a password, also called credentials, which are sent unencrypted over the network.
2. Integrated Windows authentication uses hashing technology to scramble user names and password before sending them over the network.
3. Digest authentication operates much like Basic authentication, except that passwords are sent across the network as a hash value. Digest authentication is only available on domains with domain controllers running Windows Server operating systems.
4. Anonymous authentication allows everyone access to the public areas of the Web sites, without asking for a user name or password. When this is set, the identity impersonates the identity set in the textboxes, with the default user name IUSR_MACHINENAME. Like shown in the figure down below.

Further more, IIS provides SSL (Secure Socket Layer) authentication mode that is based on certificates, to authenticate users requesting/providing secret information on the server, two trusted certificate providers (which I know but never used) are http://www.thawte.com/ and http://www.verisign.com/.

After authentication, the thread sends the request to the appropriate external module.

Next part I will talk about the 2 next security level contexts.

ASP.NET as well as .NET applications have one more excellent feature, ASP.NET uses a flexible configuration management system that keeps the application configuration separate from application code. ASP.NET configuration is stored in XML files with the .config extension, which makes it easy for users to change it before, during and after deployment.

The configuration file we all are aware of is the web.config file found in the application root, which when added has almost very simple configurations. But guess what that is not the only configuration file that your ASP.NET application relies on, there are other config files that your application inherit that configuration by default, next I will show the Configuration Hierarchy in ASP.NET. [more]

Configuration Hierarchy

1. Server settings – machine.config : This is at the root of the configuration hierarchy. It defines global, default settings for all of the applications on the(a) server. The machine.config is located in the Config folder for the version of the .NET Framework installed on the computer. In default installation will be found in this path C:WindowsMicrosoft.NETFrameworkv2.0.50727CONFIGmachine.config *.
2. Root Web setting – web.config : This defines the default settings for ASP.NET applications on the(a) server, which inherits all the settings from machine.config. Can be located at C:WindowsMicrosoft.NETFrameworkv2.0.50727CONFIGweb.config*.
3. Web site settings – web.config : This file is the first optional file in the hierarchy it defines some settings that will be applied on all the ASP.NET applications within a website. For example, to set some default settings for all web applications in the Default Web Site that comes in the IIS, place a web.config file in this path C:inetpubwwwrootweb.config *.
4. ASP.NET application root settings – web.config : This comes to be the web.config we all know that is found in the application root.This file is also optional.
5. ASP.NET application subfolder settings – web.config : This file is found in subfolders of an application to set some specific settings on the pages contained in this folder. For Example, Admin folder needs an extra <authorization> setting to not allow non admins for accessing the folder.

NOTE : Although some of the settings in the machine.config file can be overridden by settings in the web.config file, other settings that apply to ASP.NET as a whole are protected and cannot be overridden.

Merging configuration at runtime

At runtime, all these settings are merged, all configuration settings are retrieved from the machine.config, then settings from the default web.config are then retrieved, new settings are add to those of the machine.config, changed settings override the orignal ones. And So on, for the rest of the config files.

Editing the web.config

It is highly recommended not to change the default settings in the machine.config and in the default web.config of a server, unless you know exactly what you are doing.
Example for changing, there is a default connectionString in the machine.config named LocalSqlServer, a lot of extensions and providers strongly rely on it, but this default connection string uses sqlexpress which is not preferred by a lot of developers which do not want to override it in every application they use, so you can change that.

Tools for editing Web.Config; Since the web.config is XML based there are many tools that can help reading and writing settings in it, like notepad , also there are tools that are made for the sake of editing the web.config. Example tools:

1. Web Administration Tool : which enables easy and quick creation and editing web.config files for specific web application and subfolders. The web administration tool comes with Visual Studio 2005, 2008, It is found in the Project/WebSite menu usually the last item named
2. My friend here found another tool that helps changing web.config file in a nice visual tree.

* These paths are the default when installing the visual studio