Programming MicrosoftВ® OutlookВ® and Microsoft Exchange 2003, Third Edition (Pro-Developer)

Although ASP.NET builds on the authentication methods used in ASP, there are some differences. For example, ASP.NET natively supports forms-based authentication. Also, ASP.NET has more granular control when doing impersonation than ASP. This section will explore the enhancements in ASP.NET.

ASP.NET supports four types of authentication: None, Passport, Forms, and Windows. You can guess what None and Passport authentication are. Windows authentication is just standard IIS authentication. Forms authentication requires a bit more discussion.

Forms Authentication

With ASP.NET, you can perform HTML forms-based authentication rather than the standard IIS authentication, such as NTLM or Basic. With forms-based authentication, all unauthenticated requests are directed to a specified HTML form using client-side redirection. The user can then supply logon credentials and post the form back to the server. If the application authenticates the request using application-specific logic, such as looking up the user information in a database or other datasource, ASP.NET issues a cookie that contains the credentials or a key for reacquiring the client identity. Subsequent requests are issued with the cookie in the request headers, which means that subsequent authentications are unnecessary because the user is considered authenticated. In Chapter 13 you will learn how to use forms authentication with Active Directory as the authentication mechanism.

Impersonation in ASP.NET

With ASP.NET, impersonation is more granular, whereby you can have IIS authenticate the user. After that, IIS will pass the token of the user to ASP.NET. Using settings in the web.config file, you can have your ASP.NET application perform different types of impersonation. Here are the different types of impersonation that ASP.NET supports.

• Impersonation enabled with no user account identified. In this instance, ASP.NET will impersonate the token passed to it by IIS, which will be either an authenticated user or the anonymous Internet user account. Here is the code that will appear in your web.config file:

  <identity impersonate="true"/>

• Impersonation enabled but with a specific impersonation identity specified. In this instance, ASP.NET will impersonate the token generated using the configured identity. In this case the client token, if applicable , is not used. The code that should appear in your web.config file is the following:

  <identity impersonate="true" name="domain\user" password="pwd"/>

• Impersonation disabled is the default setting for backward compatibility with ASP. In this instance, the ASP.NET thread will run using the process token of the application worker process, which by default is the IIS system account, regardless of which combination of IIS and ASP.NET authentication have been used. Here is the code that should appear in your web.config file:

  <identity impersonate="false"/>

To figure out what account you are currently running under in your ASP.NET applications, you can use the following snippet of code.

System.Security.Principal.WindowsIdentity.GetCurrent().Name

ASP.NET Worker Account

The ASP.NET application worker process is called aspnet_wp.exe. You should run this process using an account with weaker privileges than the default System account. You will want to do this so that if your system is breached, the intruder does not have strong access to your system.

To run the ASP worker process using a specified account, add a <processModel> element to the root configuration file (machine.config), located in the \Windows\Microsoft.NET\Framework\<Version>\Config folder, as shown here:

<system.web> <processModel enable="true" username="domain\user" password="pwd"/> </system.web>

In addition to specifying a particular user account, you can set the username attribute to one of two specially recognized values, SYSTEM and MACHINE . In both cases, the password attribute must be set to AutoGenerate because specific credentials are not required for these special accounts. The SYSTEM setting runs the worker process using the System account. The SYSTEM setting is the default for ASP.NET. The MACHINE value causes the worker process to run with a special account named with an ASPNET prefix. This account is similar to the IWAM_MACHINENAME account used by IIS for running instances of dllhost.exe when hosting regular ASP applications. The ASPNET account is created during .NET installation.

When you use CDO 1.21 with static profiles, one gotcha you need to remember is that information must be read from the registry for CDO 1.21 static profiles. This means that if you set the identity for the ASP.NET worker process to an identity that cannot read from the registry, you will get errors from CDO.

Impersonating Users Through Code

There might be times when you want to impersonate a specific user programmatically. For example, you might only want to impersonate the authenticated user to run a certain section of code. The following code performs this functionality.

Dim impersonationContext As _ System.Security.Principal.WindowsImpersonationContext Dim currentWindowsIdentity As System.Security.Principal.WindowsIdentity currentWindowsIdentity = CType(User.Identity, _ System.Security.Principal.WindowsIdentity) impersonationContext = currentWindowsIdentity.Impersonate() 'Insert your code that runs under the security context of the 'authenticating user here. impersonationContext.Undo()

To authenticate a specific user for all requests to the server, you can use the Win32 API LogonUser method, just like you can with ASP. The following code, written for ASP.NET, logs on as a specific user. When you use the LogonUser method, you must know the username and password of the user. You can get this information by asking the user or by some other means.

<%@ Page Language="VB" %> <%@ Import Namespace = "System.Web" %> <%@ Import Namespace = "System.Web.Security" %> <%@ Import Namespace = "System.Security.Principal" %> <%@ Import Namespace = "System.Runtime.InteropServices" %> <script runat=server> Dim LOGON32_LOGON_INTERACTIVE As Integer = 2 Dim LOGON32_PROVIDER_DEFAULT As Integer = 0 Dim oImpContext As WindowsImpersonationContext Declare Auto Function LogonUser Lib "advapi32.dll" ( _ ByVal lpszUsername As String, _ ByVal lpszDomain As String, _ ByVal lpszPassword As String, _ ByVal dwLogonType As Integer, _ ByVal dwLogonProvider As Integer, _ ByRef phToken As IntPtr) As Integer Declare Auto Function DuplicateToken Lib "advapi32.dll" ( _ ByVal ExistingTokenHandle As IntPtr, _ ImpersonationLevel As Integer, _ ByRef DuplicateTokenHandle As IntPtr) As Integer Public Sub Page_Load(s As Object, e As EventArgs) If ImpersonateUser("username", "domain", "password") Then 'Run code that you want to run under the user context undoImpersonation() Else 'Impersonation failed. Error should go here. End If End Sub Private Function ImpersonateUser( _ userName As String, _ domain As String, _ password As String) As Boolean Dim tempWindowsIdentity As WindowsIdentity Dim token As IntPtr Dim tokenDuplicate As IntPtr If LogonUser(userName, domain, password, _ LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, _ token) <> 0 Then If DuplicateToken(token, 2, tokenDuplicate) <> 0 Then tempWindowsIdentity = new WindowsIdentity(tokenDuplicate) oImpContext = tempWindowsIdentity.Impersonate() If oImpContext Is Nothing Then ImpersonateUser = False Else ImpersonateUser = True End If Else ImpersonateUser = False End If Else ImpersonateUser = False End If End Function Private Sub undoImpersonation() oImpContext.Undo() End Sub </script>