The .NET framework caters to different types of authentication mechanisms to use within your applications – —including basic authentication, digest authentication, forms authentication, Passport, and Integrated Windows authentication. You also can develop your own custom authentication mechanisms; for instance, Windows authentication that matches web users to Windows user accounts that are defined on the local computer or other domain on the network. In this article, you will learn how to use Windows Authentication in your web application and how to apply impersonation to assume another identity temporarily.
The confidential data and resources must be shielded from malicious utilization and controlled in a way that unauthorized users could not be able to access any of the data—even if they are able to bypass your application’s built-in protection mechanism. Protecting data requires coordinating several different technologies such as Role-based security (RBS) which* *allows you to control what users can access based on their credentials and group memberships.
With the .NET Framework, you can make RBS decisions based on the local user database, an Active Directory Domain Services domain, or a custom user database. You can also use the .NET Framework to configure access control lists (ACLs). ACLs are the operating system’s method for tracking that should have access to what and determining which actions require adding an event to the event log. Finally, to protect data if an attacker bypasses operating system security, the .NET Framework provides cryptography tools for encrypting, validating, and signing data.
Authentication and Authorization
Authentication is the process that determines the identity of a user. After a user has been authenticated, a back-end mechanism determines if the identified user has the authorization to proceed. Authentication is often performed by providing a valid username and password on the internet or intranet environments. The username identifies you, and the password offers the computer system some assurance that you really are who you claim to be. After you are authenticated, the computer agrees that you are who you claim to be. However, it doesn’t yet know whether you are allowed to access the resource that you are requesting. That is why Authorization mechanisms came into effect and take care of the further process.
Authorization generally happens only after authentication. Authorization is the process of verifying that a user is allowed to access a requested resource. This process determines whether an authenticated user is permitted access to any part of an application, access to specific points of an application, or access only to specified datasets that the application provides. After all, how can you determine whether someone is allowed to do something if you don’t recognize that person’s identity?
Windows Authentication Overview
Form Authentication is a wonderful approach if you are implementing your own authentication process using a back-end database and a custom page. But if you are creating a web application for a limited number of users who already have a Windows account, then Windows Authentication is beneficial. Windows-based authentication is manipulated between the Windows server and the client machine.
The ASP.Net application directories typically reside at the Windows server, which is called IIS (Internet Information Server). The requests go directly to IIS to provide the authentication process in a Windows-based authentication model. This type of authentication is quite useful in an intranet environment where you can let the server deal completely with the authentication process — especially in environments where users are already logged onto a network.
In this scenario, you can utilize the credentials that are already in place for the authentication and authorization process. The entire responsibility of authentication us did by IIS. It first takes the user’s credentials from the domain login. If this process fails, IIS displays an alert dialog box so the user can enter or re-enter his login information.
Advantage of Windows Authentication
- It allows you to use the existing Windows Accounts.
- Dispense Single Authentication model for multiple types of applications.
- It lessens the burden of coding on the developer side. Disadvantage of Windows Authentication
- Non- Microsoft OS does not support this mechanism —tied to Windows users.
- It doesn’t give control over the authentication process. To set up your ASP.NET application to work with the Windows-based authentication, begin by creating some users and groups. Within your Windows operating system, go to Control panel à choose Add or Remove User. Then create this account “Test” as following. Figure 1.1 New User CreationType of Windows Authentication During the implementation of Windows Authentication, typically IIS proposes a range of possible authentication strategies to authenticate each request it receives as following.
- Basic Authentication
- Digest Authentication
- Integrated Windows Authentication
- UNC Authentication
- Anonymous AuthenticationBefore implementing such aforementioned strategies, first it is required to configure IIS. You can confirm whether IIS is already installed or not by typing the loopback address http://localhost (or http://127.0.0.1) in the browser. The following page displayed in the browser ensures that IIS is configured: Figure 1.2 IIS PageIf this page is not displayed, then we can anticipate that IIS is pre-configured. We have to turn on the IIS from the Windows Feature manually. Here, you just enable the Internet Information Services option as follows: Figure 1.3 Windows features will take some to configure. After that, you can open the IIS manager from Administrative Tools or open it directly from Run by typing inetmgr command. The IIS Manage opened-up as follows: Figure 1.4 IIS ManagerNote: It is suggested that you register the ASP.NET 4.0 version with the IIS 7.0 web server before creating any projects via this command “aspnet_regiis.exe -i” Basic AuthenticationThis form of authentication is supported by all browsers. When a website requests client authentication using Basic authentication, the web browser displays a login dialog box from the user name and password as follows: Figure 1.5 IIS Basic AuthenticationAfter a user provides built-in Windows user account information, the data is transmitted to a web server. Once IIS receives the authentication data, it attempts to authenticate the user with the corresponding Windows account. This password is encoded using Base64 and sent to the server. It is important to note that the Base64 encoding is not encryption. So the drawback of this mechanism is that the user name and password are sent in clear text (unencrypted) during communication. MITM attack can be executed by a malicious hacker and crucial credentials can be captured in between the communication. Hands-on In order to see Basic Authentication into action, we create an ASP.NET website that is hosted on local IIS web server. Follow these steps:
- First, open the Visual Studio 2010 IDE. Then go to menu FileàNewàWebsite and named this website as “WinAuthTest”.
Figure 1.6 New ASP.NET website
- Make sure that IIS 7.0 is properly configured with the registration of ASP.NET 4.0 and other components as discussed earlier
- Open the IIS manager using the inetmgr command from Run.
- Notice in the IIS manager that the website “WinAuthTest” entry is added with its corresponding virtual directory as follows:
Figure 1.7 IIS
- Now click on Authentication under IIS in the dialog box. The following options will appear as:
Figure 1.8 Authentications
- It might be possible that the above different authentication options are not displayed because they are turned on by default. So you can configure them manually from Windows Features under Internet Information Services Security options as follows: Figure 1.9 IIS Security options
- Now as per reference Figure 1.8 enable the Basic Authentication and compile the ASP.NET “WinAuthTest” project by F5, Windows will pop-up Figure 1.5 images.
- Enter the temporarily-created Windows account “test” in Figure 1.1 to proceed. Windows won’t let you open the website until you enter the correct user name and password.
Digest authentication can also be performed programmatically. We can enable this authentication using AppCmd command as follows:
appcmd.exe set config /section:basicAuthentication /enable:true
Digest Authentication, like Basic Authentication, requires the user to provide account information using a login dialog box that is displayed by the browser. Unlike the basic authentication, the user name and password are not transmitted in cleartext. Instead, a cryptographically secure hash with this information is sent. We can implement this authentication by simply enabling this option in IIS as follows:
Figure 1.10 Digest Authentications
Digest Authentication involves hashing the user’s password using the MD5 algorithm. Windows is unable to store MD5 hashes of password for local accounts (SAM database) thus the limitation of Digest Authentication is that in IIS, it functions only when the virtual directory being authenticated or controlled by Windows Active Directory Domain Controller.
Digest Authentication protects users and applications against a variety of malicious attacks by incorporating a piece of information about the request as inputs to the hashing algorithm.
Enabling and disabling digest authentication can also be performed programmatically. We can enable this authentication using AppCmd command as follows:
appcmd.exe set config /section:digestAuthentication /enable:true
Integrated Windows Authentication
Integrated Windows Authentication is the most reasonable mechanism for LAN-WAN-based applications. For this authentication to work properly, both client and server must be on the same network. In fact, integrated authentication does not transmit any credential information. Instead, it coordinates with the domain server where it logged in and gets that computer to send the authentication information to the server.
It performs authentication without any client interactions. When IIS asks the client to authenticate itself, the browser sends a token that represents the Windows account of the current user. Technically, this authentication incorporates two authentication mechanisms: NTLM and Kerberos. Enabling integrated authentication via IIS manager typically enables supports for both of these two mechanisms as follows:
Figure 1.11 Integrated Authentications
UNC (Universal Naming Convention) authentication allows you to configure IIS to use a specified user account when accessing resources on a remote share. This authentication can be implemented during the creation a virtual directory for a web application. To configure UNC authentication follow these steps as:
- Open the IIS manager using inetmgr from Run.
- Locate the website at which you wish to add a new virtual directory. Right-click and choose Add Virtual Directory.Figure 1.12 UNC Authentications
- Enter the alias name that the directory should be accessed under and UNC physical path as: Figure 1.13 UNC Authentications
- Now click the Connect as a button, and choose the Application User radio button. Choose a specific user account. Finally, click the OK button. Figure 1.14 User Account
A remote user is not required to supply credentials to access a file when Anonymous Authentication is enabled. By default, the configured anonymous access account is the IUSR account created when IIS is installed. Anonymous Authentication can be configured from IIS manages as follows:
Figure 1.15 Anonymous Authentications
It is important to note that if you enable more than one authentication option, the client will use the strongest authentication method as long as anonymous authentication is not enabled. If anonymous authentication is enabled, the client will access the website anonymously. So it is suggested that you disable anonymous authentication during more than one authentication implementation.
You can access some additional information about the currently authenticated user using WindowsIdentity class. The following code is required to achieve this foot as:
public partial class _Default : System.Web.UI.Page
protected void Button1_Click(object sender, EventArgs e)
// Display generic identity information.
lblData.Text = "<b>Name: </b>" + User.Identity.Name;
if (User is WindowsPrincipal)
WindowsPrincipal principal = (WindowsPrincipal)User;
lblData.Text += "<br><b>Power user? </b>";
lblData.Text += principal.IsInRole(
WindowsIdentity identity = principal.Identity as WindowsIdentity;
lblData.Text += "<br><b>Token: </b>";
lblData.Text += identity.Token.ToString();
lblData.Text += "<br><b>Guest? </b>";
lblData.Text += identity.IsGuest.ToString();
lblData.Text += "<br><b>System? </b>";
lblData.Text += identity.IsSystem.ToString();
When you build this program, the following extra Windows-specific information would be displayed as:
Figure 1.16 Information’s
Everything that ASP.NET does is executed under a Windows account. Impersonation is the process by which an application can take on the identity of its user to access all the resources for which the user has credentials. Instead of using a fixed account for all users, web pages and applications, you can temporarily change the identity that ASP.NET uses for certain tasks.
As an analogy, you are operating your operating system remotely and want to access some resources residing on the local system. This requires you to login with a particular user name and password on the local system. Let’s say that you have some files in the location C:\temp. In the ACL editor for the folder, temp removes all the groups and users to leave just the Administrator user and Administrator user group associated with it as shown below:
Figure 1.17 ACL
Now create a simple ASP.NET web application with Button and List box control to access all files resides in the temp folder as follows:
protected void Button1_Click(object sender, EventArgs e)
String xfiels = Directory.GetFiles(@"c:\temp");
foreach (string a in xfiels)
Configure the application in IIS to use Windows integrated authentication. Finally, build the project. When you click the button to access the files in the temp folder, you would see an error that would indicate that access to C:\temp is denied. This is because your application is running with an ASP.NET account which will not be allowed access to the C:\temp folder according to the ACL.
So we need to make our application run under the Administrator’s identity which can be achieved by impersonation. We would add the following code in the web.config file to impersonate Administrator identity as;
<identity impersonate ="true" userName ="ajay" password ="zxcvbnm123"/>
Now, build the project again to test the application, and it should work fine when you click the button as follows:
Figure 1.18 output
Alternately, you can configure impersonation from the IIS manager. Let’s take the above example reference when you are done with all programmatic and other configurations related to impersonation. If you notice in the IIS manager, the ASP.NET impersonation option is enabled and configured with impersonates “ajay” account as follows:
Figure 1.19 Impersonations
In this article, we examined the various authentication mechanisms proposed by ASP.NET such as Basic, Digest, Anonymous, Integrated, and UNC. Additionally, we looked at the techniques of configuring them from IIS and programmatically. We also learn how to retrieve user information and how to impersonate users so your code runs under different Windows accounts.