Windows Authentication

In this article we will cover Windows Authentication.

Contents

• Definitions of few keywords to understand Windows Authentication.
• What is Windows Authentication.
• Why Windows Authentication.
• How Windows Authentication is implemented in ASP.NET Application.
• Configuring impersonation in an application.

Authentication: Authentication is the process of determining the identity of a user based on the user’s credentials. The user’s credentials are usually in the form of user ID and password, which is checked against any credentials' store such as database. If the credentials provided by the user are valid, then the user is considered an authenticated user.

Authorization: After successful authentication, deciding which resources a user can access based on their identity and checking whether the authenticated user has sufficient rights to access the requested resource is authorization.

Impersonation: Impersonation is a process in which user accesses the resources(Ex:Files,DB…) by using the identity of another user.

Ex: If anonymous(not logged in/not Authenticated) access is enabled for a website in IIS, then IIS runs all the users' requests using the identity of the IUSR_machinename account, which is created by IIS. This is the default option in IIS.

WindowsIdentity: It represents the current Windows User.

Authentication Providers

In ASP.NET authentication is done by both IIS and ASP.NET. ASP.NET implements authentication through authentication providers that contains the code necessary to authenticate the requestor's credentials. There are three types of authentication providers built into ASP.NET. They are:

1. Windows Authentication Provider.
2. Forms Authentication Provider.
3. Passport Authentication Provider.

Windows Authentication Provider: Provides information on how to use Windows authentication in conjunction with Microsoft Internet Information Services (IIS) authentication to secure ASP.NET applications.

Why Windows Authentication:

1. Windows authentication is generally used if the users accessing the application belong to same organization.
2. This authentication method uses Windows accounts for validating users' credentials. This type of authentication is very good for intranet Web sites where we know our users.

How Windows Authentication is Implemented in ASP.NET Application

With this type of authentication, initially IIS performs the authentication through one of its authentication options (e.g., basic, digest, Integrated Windows, or some combination of them). After successful authentication, IIS passes the credentials of the authenticated user to the ASP.NET thread. Selection of appropriate identity for the ASP.NET worker thread is performed by using the process defined under the ASP.NET Impersonation section. Based on the credentials supplied by IIS, windows identity is created by WindowsAuthenticationModule module in ASP.NET. This identity is set as current user identity (setting the security information for the current HTTP request)for the application. This is the default authentication mode in ASP.NET and it is set in web.config file of the application using below code:

<system.web>
  <authentication mode="Windows"/>
</system.web>

Although the Windows Authentication mode sets the value of the current User property to a WindowsIdentity based on the credentials supplied by IIS. The Windows identity supplied to the operating system used for permission checking, such as NTFS file permissions, or for connecting to a database using integrated security is the identity of the ASP.NET process. On Microsoft Windows 2000 and Windows XP Professional, this is the identity of the ASP.NET worker process, which is the local ASPNET account. On Windows Server 2003, this is the identity of the IIS Application Pool that the ASP.NET application is part of. Which is the NETWORK SERVICE account.

We can configure the Windows identity of our ASP.NET application as the Windows identity supplied by IIS by enabling impersonation. Here ASP.NET application impersonates the identity supplied by IIS for all tasks that the Windows operating system authenticates, including file and network access.

Configuring Impersonation in an Application

In machine.config file it is configured as below:

<processModel enable="true" username="machine"
password="AutoGenerate" ....... />

In the above line, "machine" is a special value that causes the ASP.NET worker process to run under the less-privileged account, ASPNET.

IIS always maps a user request to some Windows account; in case of anonymous access, this is IUSR_machinename account or any other account that has been defined to be used with anonymous access; in the case of Windows authentication, this is the account whose credentials are provided by the Web site user.

• If impersonation is enabled and any specific Windows account has not been listed in the Web.config file for impersonation, then the ASP.NET worker thread runs under the client identity passed to it by IIS.
• If impersonation is not enabled, then the ASP.NET worker thread runs under the identity of the ASP.NET worker process (which has been defined by using the <processModel> tag in the Web.config file)
• If impersonation is enabled and a specific Windows account has been listed in the Web.config file for impersonation, then the ASP.NET worker thread runs under the identity generated using that account.

To enable impersonation for our Web application, in the application's Web.config file set the impersonate attribute of the identity element to true, as below:

<system.web>
  <authentication mode="Windows"/>
  <identity impersonate="true"/>
</system.web>

There are three ways of defining impersonation:

• <identity impersonate="true"/> This means impersonation for the ASP.NET worker thread is enabled.
• <identity impersonate="true" name="username" password="password"/> This means impersonation for the ASP.NET worker thread is enabled, but the worker thread will run under the identity that will be generated by using the credentials specified by username and password attributes.
• <identity impersonate="false"/> This means impersonation for the ASP.NET worker thread is not enabled.

Windows Authentication Provider

The authentication and authorization processes in ASP.NET are pretty simple and can be implemented in the code. Any request in ASP.NET is first authenticated and then authorized by IIS.

In ASP.NET authentication is done by both IIS and ASP.NET.

In ASP.NET there are different ways in which authentication is performed as discussed below:

• Anonymous Access: There is no authentication performed and the user is treated as anonymous user by iis. This is the default authentication mode.

ASP.NET implements authentication through authentication providers that contains the code necessary to authenticate the requestor's credentials. There are three types of authentication providers built into ASP.NET.

1. Windows Authentication Provider: Provides information on how to use Windows authentication in conjunction with Microsoft Internet Information Services (IIS) authentication to secure ASP.NET applications. This is the default authentication mode in ASP.NET and it is set in web.config file of the application using below code:

   <system.web>
    <authentication mode="Windows"/>
   </system.web>

   Here, the identity supplied by IIS is treated as authenticated user in an ASP.NET application.

   • IIS provides a number of authentication mechanisms to verify user identity as follows: Anonymous Authentication: IIS allows any user to access the ASP.NET application.
   • Basic Authentication: The Windows user name and password has to be provided to connec and this information is sent over the network in plain text, and, hence, this is an insecure method of authentication.
   • Digest Authentication: It is the same as basic authentication except that the password is hashed before it is sent across the network.
   • Integrated Windows Authentication: In this kind of authentication technique, passwords are not sent across the network. The application here uses either the kerberos or challenge/response protocols to authenticate users.

   Based on the credentials supplied by IIS, windows identity is created by WindowsAuthenticationModule module in ASP.NET. This identity is set as current user identity for the application.

2. Forms Authentication Provider: Provides information on how to create an application-specific login form and perform authentication using your own code. In ASP/NET forms authentication is also implemented using ASP.NET membership and ASP.NET login controls, which together provide a way to collect user credentials, authenticate them, and manage them, using little or no code.
3. Passport authentication Provider: Provides information about the centralized authentication service provided by Microsoft that offers a single login and core profile services for member sites.

Authentication

Authentication is the process of determining the authenticity of a user based on the user’s credentials. Whenever a user logs on to an application, the user is first authenticated and then authorized. The application’s web.config file contains all of the configuration settings for an ASP.NET application. It is the job of the authentication provider to verify the credentials of the user and decide whether a particular request should be considered authenticated or not. An authentication provider is used to prove the identity of the users in a system. ASP.NET provides three ways to authenticate a user:

• Forms authentication
• Windows authentication
• Passport authentication

Hence, ASP.NET contains the three respective authentication providers to support the above authentication modes.

Forms Authentication

This authentication mode is based on cookies where the user name and the password are stored either in a text file or the database. After a user is authenticated, the user’s credentials are stored in a cookie for use in that session. When the user has not logged in and requests for a page that is insecure, he or she is redirected to the login page of the application. Forms authentication supports both session and persistent cookies. Authentication modes can be specified in the application’s web.config file as shown below:

Listing 1

<configuration>
  <system.web>
    <authentication mode="[Windows/Forms/Passport/None]">
    </authentication>
  </system.web>
</configuration>

The following needs to be specified in the application’s web.config file for using Forms Based Authentication in ASP.NET:

Listing 2

<configuration>
  <system.web>
    <authentication mode="Forms"/>
    <forms name="login"loginUrl="login.aspx" />
    <authorization>
        <deny users="?"/>
    </authorization>
  </system.web>
</configuration>

Note: The statement <deny users="?"> in the web.config file as stated in Listing 2 implies that all permissions are granted only to the authenticated users. The users who are not authenticated are not granted any permission. The symbol "?" indicates all Non Authenticated and Anonymous users.

Generally the user’s credentials are stored in the database and the entered credentials are verified using those that are stored in the database. Typically, the user enters the username and the password, clicks the login button and the form validates the values against values from the database. This is shown in the code snippet below:

Listing 3

if (Verify (txtUserName.Text, txtPassword.Text))
{
  FormsAuthentication.RedirectFromLoginPage(txtUserName.Text, False);
    else
  lblMessage.Text = "Invalid login name orpassword specified...";
}
  
private Verify(string userName, string password)
{
      //Usual Code to connect to the DB
      // and verify the user's credentials
}

The static method RedirectFromLoginPage creates an authentication ticket and is used to redirect an authenticated user back to the originally requested URL or the default URL. The authentication ticket creates a persistent cookie that becomes a part of the HttpResponse object. Later, when the user tries to access a page in a restricted folder, the ASP.NET framework uses the cookie to retrieve the ticket and determine whether the user has access to that particular resource. The first parameter to this method identifies the user while the second is used to specify whether the user’s authentication cookie needs to be persisted across multiple site visits.

The user’s credentials can be also be specified in the web.config file as shown below:

Listing 4

<configuration>
    <system.web>      
    <authentication mode="Forms">
    <forms loginUrl="login.aspx">
        <credentialspasswordFormat="Clear">
            <user name="Joydip"password="Joydip" />
        </credentials>
    </forms>
    </authentication>
    <authorization>
    </system.web>
</configuration>

An authentication system is how you identify yourself to the computer. The goal behind an authentication system is to verify that the user is actually who they say they are.

Authorization

Once the system knows who the user is through authentication, authorization is how the system decides what the user can do.

Authentication is to check about user.Through authentication check the user exist or not. It check that user exist or not.

Authorization check that authentic user have proper permission or not to access that particular page or services.

Authentication is the process of determining the authenticity of a user based on the user’s credentials. Whenever a user logs on to an application, the user is first authenticated and then authorized. The application’s web.config file contains all of the configuration settings for an ASP.NET application. It is the job of the authentication provider to verify the credentials of the user and decide whether a particular request should be considered authenticated or not. An authentication provider is used to prove the identity of the users in a system. ASP.NET provides three ways to authenticate a user:

How Authentication and Authorization Works:

The following section lists the sequence of events that take place in the authentication and authorization process when a new request arrives. The IIS first checks the validity of the incoming request. If the authentication mode is anonymous (default) then the request is authenticated automatically. But if this authentication mode is overridden in the web.config file settings, the IIS performs the specified authentication check first before the request is passed on to ASP.NET.

Now ASP.NET checks whether Impersonation is enabled or not. If impersonation is enabled, ASP.NET executes with the identity of the entity on behalf of which it is performing executing the task. If impersonation is not enabled, the application runs with the identity of the IIS local machine’s identity and the privileges of the ASP.NET user account. ASPNET or NETWORK SERVICE is the default ASP.NET unprivileged account on Windows XP and Windows Server 2003, respectively. Now, the identity that has already been authenticated and verified is used to request resources from the operating system. Then ASP.NET performs an authorization check on the requested resources and if the user is authorized, it returns the request through IIS.

Application security plays a major role in building robust applications. The application should be able to restrict or limit access to the resources based on the user’s credentials and even disallow access to resources to unauthorized users of the system. This article just gave a basic idea about ASP.NET’s in-built Authentication and Authorization support.

Authentication and Authorization are security concepts.

There are four different kinds of Windows authentication options available that can be configured in IIS:

• Anonymous Authentication: IIS runs all the users’ requests using the identity of the IUSR_machinename account which is created by IIS. This is an example of Impersonation wherein user accesses the resources by using the identity of the another user. IIS doesn't perform any authentication check. IIS allows any user to access the ASP .NET application.
• Basic Authentication: For this kind of authentication, a Windows user name and password have to be provided to connect. However, this information is sent over the network in plain text and hence this is an insecure kind of authentication. Basic Authentication is mostly supported by older, non-IE browsers.
• Digest Authentication: It is same as Basic Authentication but for the fact that the password is hashed before it is sent across the network. However, to be using Digest Authentication, we must use IE 5.0 or above.
• Integrated Windows Authentication: In this kind of authentication technique, passwords are not sent across the network. The application here uses either the kerberos or challenge/response protocols to authenticate users. Kerberos, a network authentication protocol, is designed to provide strong authentication for client-server applications. It provides the tools of authentication and strong cryptography over the network to help to secure information in systems across entire enterprise.

Using impersonation, the ASP.NET engine will operate under the identity IIS passes to it. If anonymous access is allowed in IIS, ASP.NET will run under the IUSR_ComputerName account that IIS uses. If anonymous access is not allowed, ASP.NET will take on the identity of the authenticated user. Impersonation can also be configured so that a single, static user account is used for all requests

This article covers

• ASP.NET security fundamentals.
• Various ways of controlling ASP.NET Web applications security.
• Different security options provided by both IIS and ASP.NET together.

Security Fundamentals

Impersonation: Impersonation is a process in which user accesses the resources(Ex:Files,DB…) by using the identity of another user.

Ex: If anonymous access is enabled for a website in IIS, then IIS runs all the users' requests using the identity of the IUSR_machinename account, which is created by IIS. This is the default option in IIS.

Authentication: It is the process of identifying a user. the security infrastructure collects the user's credentials, usually in the form of user ID and password, checks those credentials against any credentials' store. If the credentials provided by the user are valid, then the user is considered an authenticated user.

Authorization: After successful authentication , decides which resources a user can access based on their identity and checks whether the authenticated user has sufficient rights to access the requested resource.

ASP.NET Security

Security is implemented in ASP.NET using IIS and Windows operating system. Most of the IIS security settings can be replaced with configuration files.

Whenever IIS receives requests for some ASPX page, ASMX Web Service, or any other resource that is associated with ASP.NET, it uses the IIS applications mappings to send the request to ASP.NET. ASP.NET applications use configuration files for security and other Web application settings.

ASP.NET applications on a particular machine inherit their security configuration from a file named machine.config. Each ASP.NET application can in turn override some of the settings in machine.config using an application-level configuration file named Web.config.

ASP.NET works with IIS and the Windows operating system in order to implement the security services. In ASP.NET, most of the IIS settings have been replaced with configuration files. However, security settings made in IIS are still valid in some of the areas because IIS is still handling the process of accepting users' requests. In fact, whenever IIS receives requests for some ASPX page, ASMX Web Service, or any other resource that is associated with ASP.NET, it uses the IIS applications mappings to send the request to ASP.NET.

ASP.NET applications use configuration files for security and other Web application settings. All ASP.NET applications on a particular machine inherit their security configuration from a file named machine.config present in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG folder. Each ASP.NET application can in turn override the settings in machine.config using an application-level configuration file named Web.config.

All the ASP.NET files such as .aspx, .asmx are mapped to aspnet_isapi.dll that means ASP.NET is an ISAPI server extension DLL.

Since aspnet_isapi.dll is a DLL file, it will be mapped into the address space of the process hosting this DLL which is an IIS process -- inetinfo.exe. inetinfo.exe process runs under the SYSTEM account, and since we have aspnet_isapi.dll running in the IIS address space, it means all the Web site users will be running their requests under this account!

Let me answer this question.

aspnet_isapi.dll runs under the SYSTEM account and It forwards the requests to the ASP.NET application worker process, aspnet_wp.exe. This worker process runs under a less-privileged account called ASPNET. This worker process performs the actual request processing and returns the results back to the aspnet_isapi.dll that returns it to the IIS.

In machine.config fileit is configured as below:

<processModel
enable="true" username="machine"
 
password="AutoGenerate"
....... />

In the above line, "machine" is a special value that causes the ASP.NET worker process to run under the less-privileged account, ASPNET.

there is one instance of aspnet_wp.exe per processor that serves all the Web applications hosted on a box. This worker process always runs under the security context defined by the <processModel> tag. The aspnet_wp.exe creates a separate thread, called worker thread, for servicing each client request. We have to distinguish between the server process and the worker threads in order to understand the impersonation and security details of ASP.NET.

Security is concerned with protecting users accessing web applications and the data that pass between them.

The most common aspect of security is user authentication, where a user attempts to prove their identity, and authorization, where a service decides which resources a user can access based on their identity.

In ASP.NET, the users requesting a webpage are, by default, anonymous. There are different techniques available for determining the identity of an anonymous user. by default, Web applications allow for anonymous users.

When a request comes in for an ASP.NET Web page, the request is sent to the Web server software (IIS), which performs authentication and authorization.

If the user is not authenticated, or does not have access, the request is not processed further and an appropriate message will be returned. If, however, the request passes IIS's authentication and authorization, the request will be sent to the ASP.NET engine, which can impose its own authentication and authorization schemes.

1. By default, IIS allows anonymous access thus requests are automatically authenticated. However, this can be overridden for each application within IIS. Otherwise authentication is performed.
2. The authenticated user request is passed to ASP.NET.
3. ASP.NET checks whether Impersonation is enabled or not. By default impersonation is not enabled in ASP .NET.
   1. If impersonation is enabled, ASP.NET executes with the identity of the user credentials in web.config file.
   2. If impersonation is not enabled, the application runs with the privileges of the ASPNET user account.
   3. Finally, the identity that has been authenticated and checked for in the previous steps is used to request resources from the OS.
   4. Forms Authentication Provider
      The forms authentication provider uses custom HTML forms to collect authentication information. As an ASP.NET developer using forms authentication, you must write your own logic/code to check the user's supplied credentials against a database or some other data store. When a user is successfully identified via forms authentication, the user's credentials are stored in a cookie for use during the session.

By default, the ASP.NET engine operates under the ASPNET user account. Impersonation is a means by which you can have the ASP.NET engine operate under the authenticated user's user account.

Authentication is a process of identifying a user.

Authorization is the process of determining if an authenticated user has access to the resource(s) they requested.

Typically, authentication is achieved by the user credentials that verify the user's identity.

Whenever Websever(IIS) receives the request for any resource such as an aspx page/asmx page ... It forwards the requests to aspnet_isapi.dll and since this DLL file is hosted in the address space of IIS, it runs under the SYSTEM account. But it forwards the requests to the ASP.NET application worker process, aspnet_wp.exe. This worker process performs the actual request processing and returns the results back to the aspnet_isapi.dll that returns it to the IIS.

Important point to note here is that ASP.NET worker process runs under the ASPNET account which is less privileged account than the system account.

Actually There is one instance of aspnet_wp.exe per processor that serves all the Web applications hosted on a box. This worker process always runs under the security context defined by the <processModel> tag in machine.config file. The aspnet_wp.exe creates a separate thread, called worker thread, for handling each client request. With ASP.NET impersonation, the thread servicing the client request can also execute with the identity of the client.

IIS always maps a user request to some Windows account; in case of anonymous access, this is IUSR_machinename account or any other account that has been defined to be used with anonymous access; in the case of Windows authentication, this is the account whose credentials are provided by the Web site user. After successful authentication, IIS forwards this logged-in user's identity to the ASP.NET worker thread. Now the ASP.NET worker thread has the following three options:

• It can run under the identity defined by the <processModel> tag.
• It can run under the client identity passed to it by IIS.
• It can run under the identity of the user whose credentials have been listed for impersonation.

Now the decision depends on the impersonation settings for the ASP.NET application.

• If impersonation is enabled and any specific Windows account has not been listed in the Web.config file for impersonation, then the ASP.NET worker thread runs under the client identity passed to it by IIS.
• If impersonation is not enabled, then the ASP.NET worker thread runs under the identity of the ASP.NET worker process (which has been defined by using the <processModel> tag in the Web.config file)
• If impersonation is enabled and a specific Windows account has been listed in the Web.config file for impersonation, then the ASP.NET worker thread runs under the identity generated using that account.

Impersonation for ASP.NET applications can be set up by using the <identity> tag in the Web.config file. We can specify impersonation in the following three ways:

• <identity impersonate="true"/> This means impersonation for the ASP.NET worker thread is enabled.
• <identity impersonate="true" name="username" password="password"/> This means impersonation for the ASP.NET worker thread is enabled, but the worker thread will run under the identity that will be generated by using the credentials specified by username and password attributes.
• <identity impersonate="false"/> This means impersonation for the ASP.NET worker thread is not enabled.

Security has always been a top issue for all kinds of applications, especially Web applications. Web apps are accessible to almost the entire universe and are open to attack.

Web Services is a current hot topic because of its interoperability, ease of consumption, use of standard Web protocols, seamless integration with heterogeneous systems, etc. Therefore more platforms are now incorporating Web Services into their architecture. And with that greater amount of use, the need for security also increases.

Since Web Services are part of ASP.NET, and these are hosted by ASP.NET runtime, anything relevant to ASP.NET will also be true for Web Services.

This article will discuss:

• Security concepts
• ASP.NET security
• How to control security by running the ASP.NET application worker process (aspnet_wp.exe) using an account with weaker privileges than the Local System account
• Different security schemes offered by ASP.NET and Internet Information Server (IIS), and how ASP.NET and IIS work together to provide security to Web apps, including Web Services
• Some code examples on how to use these security schemes for Web Services

Setting Up the Sample Applications

I have created a project in C# (CSWebservices) that contains some Web Services. This project will be used for the demonstration of different security schemes. There is also a C# Web site (CSWebsite) that has some Web pages for invoking methods on our Web Services.

To install the applications:

• Extract all the code from attached ZIP file.
• Create two virtual directories named CSWebservices and CSWebsite, and map the CSWebservices and CSWebsite virtual directories to the CSWebservices and CSWebsite physical directories on your hard drive.

Creating Windows User Accounts

To test Windows security, a valid Windows account is needed. Create a user account called Test on your computer. You can do so by running the Computer Management application from Control Panel -> Administrative Tools -> Computer Management. In the Computer Management application, right click on the Users node under the Local Users and Groups node, select New User... option from the context menu, enter "Test" in the User name text box, enter some password in Password and Confirm password text boxes, uncheck the User must change password at next logon check box, and check the User cannot change password check box. Your screen should look like the following:

Click the Create button. The Test user has been created successfully. Follow the same steps and create another user called Test2.

Security Concepts

Before proceeding further, I will describe some concepts that represent the key functionalities that a security system must provide.

Impersonation

Sometimes we want users' requests to be run in the security context of some other user identity. For that we use impersonation. Impersonation is a process in which a user accesses the resources by using the identity of another user. An example of impersonation is the use of the IUSR_machinename account that is created by IIS. When a Web site has anonymous access enabled, then IIS runs all the users' requests using the identity of the IUSR_machinename account.

Authentication

Authentication is a process in which the security infrastructure makes sure that the users are who they say they are. In order to do this, the security infrastructure collects the user's credentials, usually in the form of user ID and password, checks those credentials against any credentials' store. If the credentials provided by the user are valid, then the user is considered an authenticated user.

Authorization

Once we have authenticated the user and the user has valid credentials, it is time to check authorization.

Authorization is a process in which the security infrastructure checks whether the authenticated user has sufficient rights to access the requested resource. If user has sufficient rights to access a resource, for example, the user has "write rights" on a file, then the operation succeeds; otherwise the operation fails.

ASP.NET Security

ASP.NET works with IIS and the Windows operating system in order to implement the security services. In ASP.NET, most of the IIS settings have been replaced with configuration files. However, security settings made in IIS are still valid in some of the areas because IIS is still handling the process of accepting users' requests. In fact, whenever IIS receives requests for some ASPX page, ASMX Web Service, or any other resource that is associated with ASP.NET, it uses the IIS applications mappings to send the request to ASP.NET.

ASP.NET applications use configuration files for security and other Web application settings. All ASP.NET applications on a particular machine inherit their security configuration from a file named machine.config. Each ASP.NET application can in turn override some of the settings in machine.config using an application-level configuration file named Web.config.

So what really is an ASP.NET application? To find the answer to this question, start the Internet Services Manager, right click on the Default Web Site node, select Properties from the context menu, go to the Home Directory tab on the Web site properties dialog box, and click the Configuration... button. It will pop up the following dialog box.

As you can see in the above dialog box, the Web Services files, Web form files, and all of the other .NET file types are mapped to the aspnet_isapi.dll. This signifies that the ASP.NET is an ISAPI server extension DLL.

This is very important point. Since aspnet_isapi.dll is actually a DLL file, it will be mapped into the address space of the process hosting this DLL. This process is an IIS process -- inetinfo.exe!! A user must be thinking that inetinfo.exe runs under the SYSTEM account, and since we have aspnet_isapi.dll running in the IIS address space, it means all the Web site users will be running their requests under this account!

Let me answer this question. Yes, aspnet_isapi.dll runs under the SYSTEM account, but it does not do much in terms of processing Web requests, rather it forwards the requests to the ASP.NET application worker process, aspnet_wp.exe. This worker process performs the actual request processing and returns the results back to the aspnet_isapi.dll that returns it to the IIS.

ASP.NET Worker Process

Aspnet_isapi.dll forwards requests to the ASP.NET worker process. If you have .NET Framework Beta 2 installed on your machine, then the worker process will be running under the SYSTEM account, but since the Release to Manufacturer version (RTM) of .NET, worker process runs under a less-privileged account called ASPNET.

Find the machine.config file on your hard drive and search for a tag called <processModel>. In beta versions of .NET, it would look as follows:

<processModel enable="true" username="System"

password="AutoGenerate" ....... />

In the RTM version of .NET, it would look as follows:

<processModel
  enable="true" username="machine"
password="AutoGenerate"
  ....... />

In the above line, "machine" is a special value that causes the ASP.NET worker process to run under the less-privileged account, ASPNET.

In order to avoid running the Beta 2 ASP.NET process under the SYSTEM account, change the username and password to some other valid Windows account. For example, the

<processModel
  enable="true" username="MyDomain\Testuser"
  password="userpassword" ...... />

line will cause the ASP.NET worker process to run under the privileges assigned to the MyDomain\Testuser. It is always recommended to use a specific account that has fewer privileges (like the ASPNET account used by the RTM version of .NET) for the ASP.NET worker process. In this way, even if your server gets hacked, the intruder may not be able to harm your server due to the lesser privileges assigned to the account.

If you plan on using a custom Windows account for the worker process, then you must make sure that the account has proper rights on different directories because ASP.NET needs to read and write files to/from different directories. The custom Windows account should have at least:

• Read rights on application directory
• Read rights on %installroot% hierarchy to make it possible to access the system assemblies
• Read/Write rights on the %installroot%\ASP.NET Temporary Files directory
• Read/Write rights on the %temp% directory

ASP.NET Impersonation

An understanding of ASP.NET impersonation is important before going into the details of authorization and authentication. Therefore, first we will discuss ASP.NET impersonation in this section.

Before delving into the details of ASP.NET impersonation, I would like to clarify one important point that many folk are not aware of. Actually there is one instance of aspnet_wp.exe per processor that serves all the Web applications hosted on a box. This worker process always runs under the security context defined by the <processModel> tag. The aspnet_wp.exe creates a separate thread, called worker thread, for servicing each client request. We have to distinguish between the server process and the worker threads in order to understand the impersonation and security details of ASP.NET.

With ASP.NET impersonation, the thread servicing the client request can optionally execute with the identity of the client. Let me explain it in detail.

IIS always maps a user request to some Windows account; in case of anonymous access, this is IUSR_machinename account or any other account that has been defined to be used with anonymous access; in the case of Windows authentication, this is the account whose credentials are provided by the Web site user. After successful authentication, IIS forwards this logged-in user's identity to the ASP.NET worker thread. Now the ASP.NET worker thread has the following three options:

• It can run under the identity defined by the <processModel> tag.
• It can run under the client identity passed to it by IIS.
• It can run under the identity of the user whose credentials have been listed for impersonation.

Now the decision depends on the impersonation settings for the ASP.NET application.

• If impersonation is enabled and any specific Windows account has not been listed in the Web.config file for impersonation, then the ASP.NET worker thread runs under the client identity passed to it by IIS.
• If impersonation is not enabled, then the ASP.NET worker thread runs under the identity of the ASP.NET worker process (which has been defined by using the <processModel> tag in the Web.config file)
• If impersonation is enabled and a specific Windows account has been listed in the Web.config file for impersonation, then the ASP.NET worker thread runs under the identity generated using that account.

Impersonation for ASP.NET applications can be set up by using the <identity> tag in the Web.config file. We can specify impersonation in the following three ways:

• <identity impersonate="true"/> This means impersonation for the ASP.NET worker thread is enabled.
• <identity impersonate="true" name="username" password="password"/> This means impersonation for the ASP.NET worker thread is enabled, but the worker thread will run under the identity that will be generated by using the credentials specified by username and password attributes.
• <identity impersonate="false"/> This means impersonation for the ASP.NET worker thread is not enabled.

ASP.NET Authentication

As stated above, ASP.NET and IIS securities go hand in hand. Therefore ASP.NET authentication also relies on the settings that we make in IIS. ASP.NET offers following types of authentications:

• Windows authentication
• Forms authentication
• Passport authentication
• None

The authentication option for the ASP.NET application is specified by using the <authentication> tag in the Web.config file, as shown below:

<authentication
  mode="Windows | Forms | Passport | None">

other authentication options

</authentication>

Windows Authentication

As the name implies, this authentication method uses Windows accounts for validating users' credentials. This type of authentication is very good for intranet Web sites where we know our users.

With this type of authentication, initially IIS performs the authentication through one of its authentication options (e.g., basic, digest, Integrated Windows, or some combination of them). After successful authentication, IIS passes the identity of the authenticated user to the ASP.NET thread. Selection of appropriate identity for the ASP.NET worker thread is performed by using the process defined under the ASP.NET Impersonation section of this article.

We can secure a Web Service by using one of the following Windows authentication schemes:

• Integrated Windows authentication
• Basic and basic with SSL authentication
• Digest authentication
• Client Certificate authentication

Integrated Windows Authentication

Integrated Windows authentication is a secure way of passing a user's credentials on wire. It can use either NT LAN Manager (NTLM) or Kerberos authentication. This is the best scheme that can be used for intranet environments using Windows, but this scheme cannot be used for Internet because it works only with Windows clients.

In order to set up Integrated Windows authentication for our Web Services, we have to specifically tell IIS to use Integrated Windows authentication. We can do this by using the Internet Services Manager application. Run this application from Control Panel -> Administrative Tools -> Internet Services Manager; in the left-hand pane, select the CSWebservices node under the Default Web Site node; in the right-hand pane, right click on the IWAWebservice.asmx Web Service, select Properties from the context menu and go to the File Security tab. Following is the File Security tab:

Click Edit button in Anonymous access and authentication control group box and it will popup the following dialog box:

By default, Anonymous access is checked. This means IIS will not stop anyone from accessing our Web Service; in fact no authentication will be performed at all. The only entity that might stop a user from accessing this Web Service is the NT File System (NTFS) permissions. NTFS is a file system that has security capabilities built into it. NTFS always checks the security credentials of the identity that is trying to access the file. If NTFS permissions require some authentication, then IIS will challenge the user for credentials.

We don't want this. Therefore, uncheck the Anonymous access check box and leave the Integrated Windows authentication box checked.

Apart from that, change the <authentication> tag in the Web.config file and set the mode attribute to "Windows"; similarly set the impersonate attribute of the <identity> tag to "true". Following is the snippet from the updated Web.config file:

<system.web>
    <authentication mode="Windows"/>
    <identity impersonate="true"/>
</system.web>

This secures our Web Service with Integrated Windows authentication. In order to test whether our Web Service has been set up, browse the IWAWebservice.asmx file from a browser. You might need to browse the Web Service from a computer that is not part of your domain. Why? Because if you browse it from a computer on which someone has already logged into the domain, the browser will transparently pass your logged-in user's credentials in response to the server challenge, and no password dialog box will be shown.

Browsing the IWAWebservice.asmx file from a computer that is not connected to your domain causes the following dialog to pop up.

This shows that our Web Service will only be accessible if you provide valid Windows account credentials.

Similarly, if we don't pass valid credentials and try to access the Web Service in the btnTestIWA_Click handler in the testws.aspx page, then it will generate the following error.

Following is the code that generates the error because we are not passing credentials with our method invocation request:

CSWebservices.IWAWebservice
  objws = 
new
  CSWebservices.IWAWebservice() ;
CSWebservices.MyIdentity
  objIdentity ;
objIdentity
  = objws.GetMyIdentity() ;

In order to access a Web Service that has been protected by some authentication mechanism, we use the NetworkCredential object to pass those credentials. Following is the complete code from the testws.aspx page, which accesses the IWAWebservice.asmx Web Service by passing the valid credentials of the test user that we created for testing purposes:

private void btnTestIWA_Click(object sender, System.EventArgs e)
{
	// Create Web Service object.
CSWebservices.IWAWebservice objws = 
new CSWebservices.IWAWebservice() ;

	// Create credentials object.	
NetworkCredential objCredential = 
new NetworkCredential("Test", "test", "yourdomain") ;

// Let Web Service know about your credentials.
objws.Credentials = objCredential ;
	
	// Call method on Web Service.
CSWebservices.MyIdentity objIdentity ;
	objIdentity = objws.GetMyIdentity() ;
	
	........................
}

So after updating the code in btnTestIWA_Click handler, if we browse to testws.aspx page and click on the Test Integrated Windows Authentication button, we should see a page similar to the following.

Basic and Basic with SSL Authentication

The problem with Integrated Windows authentication is it uses the NTLM/Kerberos protocol for authentication purposes. For users to have one of these protocols, they must be Windows clients. (For example, Unix clients do not understand NTLM.) Some of our Web Service clients may not be aware of this protocol and will not be able to access our Web Service! We are limiting our clients. One way to circumvent this problem is to use basic authentication.

The basic authentication mechanism is different from Integrated Windows authentication because it does not require clients to compute hash for the authentication purposes.

Basically during the Integrated Windows authentication process, the client machine computes a hash value by encrypting the user's credentials and sends it to the server. Instead, in basic authentication, the user is prompted for a username and password. This information is then transmitted to the server, but first it is encoded using base64 encoding. Most of the browsers, proxy servers, and Web servers support this method, but it is not secure. Anyone who knows how to decode a base64 string can decode users' credentials.

Basic authentication itself is not secure, but if we use it with the secure hypertext transfer protocol (HTTPS), which encrypts all communication between the client and server, it becomes quite useful. The beauty of this option is we can easily use it on the Internet without facing any problem from proxy servers, Web servers, etc. We can enable basic authentication by using the Authentication Methods dialog box. Now we will enable basic authentication for the BAWebservice.asmx Web Service. Open the Authentication Methods dialog box for the BAWebservice.asmx Web Service, uncheck the Anonymous access and Integrated Windows authentication check boxes, and check the Basic authentication (password is sent in clear text) check box. The dialog should look like the following.

Click OK. We had already enabled Windows authentication in the Web.config file, therefore we don't have to do anything more. We have successfully enabled basic authentication for our Web Service.

Now if we try to access the BAWebservice.asmx file from a browser, the following dialog box will be displayed.

We are not using Integrated Windows authentication, therefore this dialog box will be shown even on a machine logged into the domain.

Code for accessing the BAWebservice.asmx Web Service is the same as the code used for IWAWebservice.asmx. The following page will be displayed after clicking the Test Basic Authentication button on the testws.aspx page:

Digest Authentication

Digest authentication is a new type of authentication that is available on Windows 2000 domains, and only IE5 or later clients can use it. In this type of authentication, user's credentials are not sent on the wire in the form of text, rather credentials are encrypted using a hashing mechanism called Message Digest 5 (MD5). This is a good option for Internet Web Services, but the client and server requirements limit its adoptability. On the server side, you will need the Windows 2000 domain to have all the user accounts stored in the Active Directory; on the client side, you have to have either the .NET platform or IE 5.0 or later.

If we plan to use a custom Windows account for the worker process, then we must make sure that the account has proper rights on different directories because ASP.NET needs to read and write files to/from different directories.

• Forms Authentication: With forms authentication, custom logic can be built into an ASP.NET application. The following happens when forms authentication is used in an ASP.NET application:
  • When a user requests a page for the application, ASP.NET checks for the presence of a special session cookie.
  • If the cookie is present, ASP.NET assumes the user is authenticated and processes the request.
  • If the cookie isn’t present, ASP.NET redirects the user to a web form where the custom logic has been built into the code. The authentication checks can be incorporated into the web form, and when the user is authenticated ASP.NET needs to be informed of the same by setting a property. Once this is done, ASP.NET creates the special cookie to handle any subsequent requests.

.NET framework policy defines what resources code in executing assemblies may access.

Policy in .NET Framework is automatically installed on every machine for each user account.

It can be deployed across windows domains via Group Policy.

The default security policy shipped with .NET Framework is is intended to create a safe execution environment for a typical end user. It can be customized by sufficiently privileged administrative accounts to address unique needs.