Pro ASP.NET 2.0 In CSharp 2005 (2005) [eng]

758 C H A P T E R 2 2 ■ W I N D O W S A U T H E N T I C AT I O N

Figure 22-4. Kerberos authentication and tickets

If the server can decrypt and validate the session ticket received from the client successfully, the communication session is established. Both the client and the server use the previously generated session key for encrypting the communication traffic. As soon as the session ticket has expired, the whole operation takes place again.

Every ticket—session tickets and ticket-granting tickets—are equipped with capabilities. For example, they can impersonate the client user on the server or delegate the client’s identity to another server. If the client and the KDC do not include these capabilities into the ticket, such features just don’t work. For this purpose, the user and the server need additional permissions, as you will see in the “Impersonation” section of this chapter.

We’ll discuss the basic concepts of NTLM and Kerberos so you can understand the necessary configuration steps for making impersonation and delegation work. In most cases, if something doesn’t work with impersonation (or delegation), it’s because the domain controller or the KDC is incorrectly configured (if you are not using Active Directory) or because the expiration date of the ticket is not set appropriately (it should not be set too long but not too short either).

Although covering these topics in great detail requires an entire book, this overview will allow you to understand how the protocol works and what the requirements for different usage scenarios are.

Implementing Windows Authentication

To use Windows authentication in an ASP.NET application and have access to the user identity in ASP.NET, you need to take three steps:

1.Configure the type of Windows authentication using IIS Manager.

2.Configure ASP.NET to use the IIS authentication information using the web.config file.

3.Restrict anonymous access for a web page, a subdirectory, or the entire application.

The following sections describe these steps.

Configuring IIS

Before you can use Windows authentication, you need to choose the supported protocols by configuring the virtual directory. To do so, start IIS Manager (select Settings Control Panel Administrative Tools Internet Information Services). Then right-click a virtual directory or a subdirectory inside a virtual directory, and choose Properties. Select the Directory Security tab, which is shown in Figure 22-5.

Figure 22-5. Directory security settings

Click the Edit button to modify the directory security settings. Enable the supported protocols in the Authenticated access box in the bottom half of the window. If you enable Basic authentication, you can also set a default domain to use when interpreting the user credentials. (The user can also log into a specific domain by supplying a user name in the format DomainName\UserName.) In the example in Figure 22-6, support is enabled for integrated Windows authentication and anonymous access.

<configuration>

<system.web>

<!-- Other settings omitted. -->

<authentication mode="Windows"/>

</system.web>

</configuration>

This tells ASP.NET that you want to use the Windows authentication module. The WindowsAuthenticationModule HTTP module will then handle the Application_AuthenticateRequest event.

Denying Access to Anonymous Users

As described earlier, you can force users to log on by modifying IIS virtual directory settings or by using authorization rules in the web.config file. The second approach is generally preferred. Not only does it give you more flexibility, but it also makes it easier to verify and modify authorization rules after the application is deployed to a production web server.

Chapter 23 describes authorization in detail. For now, you’ll consider only the simple technique of denying access to all unauthenticated users. To do this, you must use the <authorization> element of the web.config file to add a new authorization rule, as follows:

<configuration>

<system.web>

<!-- Other settings omitted. --> <authorization>

<deny users="?" />

</authorization>

</system.web>

</configuration>

The question mark (?) is a wildcard character that matches all anonymous users. By including this rule in your web.config file, you specify that anonymous users are not allowed. Every user must be authenticated using one of the configured Windows authentication protocols.

Accessing Windows User Information

One of the nice things about Windows authentication is that no login page is required. When the user requests a page that requires authentication, the browser transmits the credentials to IIS. Your web application can then retrieve information directly from the User property of the web page.

Here’s an example that displays the currently authenticated user:

if (Request.IsAuthenticated)

{

// Display generic identity information. lblInfo.Text = "<b>Name: </b>" + User.Identity.Name; lblInfo.Text += "<br><b>Authenticated With: </b>"; lblInfo.Text += User.Identity.AuthenticationType;

}

This is the same code you can use to get information about the current identity when using forms authentication. However, you’ll notice one slight difference. The user name is always in the form DomainName\UserName or ComputerName\UserName. Figure 22-7 shows an example with a user account named Matthew on the computer FARIAMAT.

764C H A P T E R 2 2 ■ W I N D O W S A U T H E N T I C AT I O N

Table 21-2. Continued

The following code displays extra Windows-specific information about the user:

if (Request.IsAuthenticated)

{

lblInfo.Text = "<b>Name: </b>" + User.Identity.Name;

WindowsIdentity identity = (WindowsIdentity)User.Identity; lblInfo.Text += "<br><b>Token: </b>";

lblInfo.Text += identity.Token.ToString(); lblInfo.Text += "<br><b>Guest? </b>"; lblInfo.Text += identity.IsGuest.ToString(); lblInfo.Text += "<br><b>System? </b>"; lblInfo.Text += identity.IsSystem.ToString();

}

Figure 22-9 shows the result.

Figure 22-9. Showing Windows-specific user information

Impersonation

Everything that ASP.NET does is executed under a Windows account. By default, this identity is the account ASPNET (in IIS 5), but it can be configured through the machine.config file, as described in Chapter 2. As each page request is processed, the configured identity determines what ASP.NET can and cannot do.

Impersonation provides you with a way to make this system more flexible. 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. This process of temporarily assuming the identity of another Windows account is impersonation.

By default the ASP.NET worker process account (the ASPNET user) has this privilege, so you don’t need to perform any extra configuration steps.

Impersonation and Delegation on Windows Server 2003

When using Windows Server 2003 as a stand-alone server, you have to assign the Impersonate a Client After Authentication privilege to the account of the application pool, as is the case for the worker process account on Windows XP. The local IIS worker process group (IIS_WPG) and the local service and network service account have this privilege by default. Therefore, you don’t need to configure anything if you use a network service or local service or if you create a custom account and add it to the IIS_WPG group.

But delegation is different. As mentioned previously, delegation means that a server that has authenticated the client can pass the client’s authentication ticket to another server in this network. This means that this server (and therefore your application) acts on behalf of the client across the network. Figure 22-13 shows this in detail.

Figure 22-13. Identity flows across network hops

In Figure 22-13, you can see the big difference of impersonation. While impersonation takes place on the local machine only, delegation brings the concept of impersonation to calls across the network. Of course, if every server could do that in an uncontrolled fashion, this feature would

definitely lead to a security risk. Therefore, Windows provides you with a way to specify which computer is trusted for delegation. By default no computer in the network except the domain controller is trusted for delegation. In Figure 22-13, the server you would configure for delegation would be the Web Application Server, as this is the one that needs to pass the credentials onto the next server.

You can configure delegation through the Active Directory Users and Computers management console on your domain controller. First, you have to open the Computers node, and then select the properties of the computer you want to configure for delegation. If you are running your domain with Windows Server 2003 at a functional level (which implies you don’t have any Windows 2000 or older machines in your network), you can use constrained delegation, as shown in Figure 22-14.

If you are running the application in domains with Windows 2000 servers, you can configure the Trust for Delegation setting on the General tab of the server’s properties page. Figure 22-15 shows the settings if you are running your domain with Windows 2000 (functional level).