With anonymous authentication turned off, IIS permits requests only from users that it can authenticate either in its domain or in a trusted domain.

For static file types (for example .jpg, .gif and .htm files—files that are not mapped to an ISAPI extension), IIS uses the NTFS permissions associated with the requested file to perform access control.

The ASP.NET gatekeepers include the UrlAuthorizationModule, FileAuthorizationModule and principal permission demands and role checks.

FileAuthorizationModule

For file types mapped by IIS to the ASP.NET ISAPI extension (Aspnet_isapi.dll), automatic access checks are performed using the authenticated user’s Windows access token (which may be IUSR_MACHINE) against the ACL attached to the requested ASP.NET file.

Note

Impersonation is not required for file authorization to work.

The FileAuthorizationModule class only performs access checks against the requested file, and not for files accessed by the code in the requested page, although these are access checked by IIS.

For example, if you request Default.aspx and it contains an embedded user control (Usercontrol.ascx), which in turn includes an image tag (pointing to Image.gif), the FileAuthorizationModule performs an access check for Default.aspx and Usercontrol.ascx, because these file types are mapped by IIS to the ASP.NET ISAPI extension.

The FileAuthorizationModule does not perform a check for Image.gif, because this is a static file handled internally by IIS. However, as access checks for static files are performed by IIS, the authenticated user must still be granted read permission to the file with an appropriately configured ACL.

This scenario is shown in Figure 8.2.

Figure 8.2. IIS and ASP.NET gatekeepers working together

Note to system administrators:

The authenticated user requires NTFS read permissions to all of the files involved in the scenario. The only variable is regarding which gatekeeper is used to enforce access control. The ASP.NET process account only requires read access to the ASP.NET registered file types.

In this scenario you can prevent access at the file gate. If you configure the ACL attached to Default.aspx and deny access to a particular user, the user control or any embedded images will not get a chance to be sent to the client by the code in Default.aspx. If the user requests the images directly, IIS performs the access checks itself.

When you use Windows authentication together with impersonation, the following authorization options are available to you:

Programmatic security refers to security checks located within your Web application code. The following programmatic security options are available when you use Windows authentication and impersonation:

Use Windows authentication and impersonation when:

Before using impersonation within your application, make sure you understand the relative trade-offs of this approach in comparison to using the trusted subsystem model. These were elaborated upon in "Choosing a Resource Access Model" in Chapter 3.

The disadvantages of impersonation include:

When you use Windows authentication without impersonation, the following authorization options are available to you:

The following programmatic security options are available:

Use Windows authentication without impersonation when:

Using a fixed impersonated identity is not recommended when using the .NET Framework 1.0 on Windows 2000 servers. This is because you would need to give the ASP.NET process account the powerful "Act as part of the operating system" privilege. This privilege is required by the ASP.NET process because it performs a LogonUser call using the credentials that you have provided.

When you use Forms authentication, the following authorization options are available to you:

The following programmatic security options are available:

Forms authentication is most ideally suited to Internet applications. Use Forms authentication when:

Passport authentication is used on the Internet when application users do not have Windows accounts and you want to implement a single-sign-on solution. Users who have previously logged on with a Passport account at a participating Passport site will not have to log on to your site configured with Passport authentication.

Take note of the following when you configure URL authorization:

Configuration settings are hierarchical. Web.config file settings in subdirectories override Web.config settings in parent directories. Also, Web.config settings override Machine.config settings.

You can lock configuration settings to prevent them being overridden at lower levels, by using the <location> element coupled with the allowOverride attribute. For example:

<location path="somepath" allowOverride="false" />
. . . arbitrary configuration settings . . .
</location>

Note that the path may refer to a Web site or virtual directory and it applies to the nominated directory and all subdirectories. If you set allowOverride to false, you prevent any lower level configuration file from overriding the settings specified in the <location> element. The ability to lock down configuration settings applies to all types of setting and not just security settings such as authentication modes.

In the context of machine.config, the path must be fully qualified and include the Web site, virtual directory name and optionally a sub directory and filename. For example:

<location path="Web Site Name/VDirName/SubDirName/PageName.aspx" >
. . .
</location>

In the context of web.config, the path is relative from the application's virtual directory. For example:

<location path="SubDirName/PageName.aspx" >
. . .
</location>

You can use the HttpForbiddenHandler class to prevent certain file types from being downloaded over the Web. This class is used internally by ASP.NET to prevent the download of certain system level files (for example, configuration files including web.config). For a complete list of file types restricted in this way, see the <httpHandlers> section in machine.config.

You should consider using the HttpForbiddenHandler for files that your application uses internally, but are not intended for download.

▸ To use the HttpForbiddenHandler to prevent a particular file type from being downloaded

You must start by retrieving a set of credentials (user name and password) from the user. If your application does not use Windows authentication, you need to ensure that clear text credentials are properly secured on the network by using SSL.

If you have configured Windows authentication, credentials are validated automatically using the underlying services of the operating system.

If you use an alternate authentication mechanism, you must write code to validate credentials against a data store such as a SQL Server database or Active Directory.

For more information about how to securely store user credentials in a SQL Server database, see "Authenticating Users against a Database" within Chapter 12.

Your user data store should also contain a list of roles for each user. You must write code to retrieve the role list for the validated user.

Authorization occurs against the authenticated user, whose identity and role list is maintained within an IPrincipal object (which flows in the context of the current Web request).

If you have configured Windows authentication, ASP.NET automatically constructs a WindowsPrincipal object. This contains the authenticated user’s identity together with a role list, which equates to the list of Windows groups to which the user belongs.

If you are using Forms, Passport, or custom authentication, you must write code within the Application_AuthenticateRequest event handler in Global.asax to create an IPrincipal object. The GenericPrincipal class is provided by the .NET Framework, and should be used in most scenarios.

Attach the IPrincipal object to the current HTTP context (using the HttpContext.User variable). ASP.NET does this automatically when you use Windows authentication. Otherwise, you must attach the object manually.

Use .NET roles either declaratively (to obtain class or method level authorization), or imperatively within code if your application requires more fine-grained authorization logic.

You can use declarative or imperative principal permission demands (using the PrincipalPermission class), or you can perform explicit role checks by calling the IPrincipal.IsInRole() method.

The following example assumes Windows authentication and shows a declarative principal permission demand. The method that follows the attribute will only be executed if the authenticated user is a member of the Manager Windows group. If the caller is not a member of this group, a SecurityException is thrown.

[PrincipalPermission(SecurityAction.Demand,
                     Role=@"DomainNameManager")]
public void SomeMethod()
{
}

The following example shows an explicit role check within code. This example assumes Windows authentication. If a non-Windows authentication mechanism is used, the code remains very similar. Instead of casting the User object to a WindowsPrincipal object, it should be cast to a GenericPrincipal object.

// Extract the authenticated user from the current HTTP context.
// The User variable is equivalent to HttpContext.Current.User if you are
// using an .aspx or .asmx page
WindowsPrincipal authenticatedUser = User as WindowsPrincipal;
if (null != authenticatedUser)
{
// Note: To retrieve the authenticated user's username, use the
// following line of code
// string username = authenticatedUser.Identity.Name;

// Perform a role check
if (authenticatedUser.IsInRole(@"DomainNameManager") )
{
  // User is authorized to perform manager functionality
}
}
else
{
  // User is not authorized to perform manager functionality
}

For more information about creating your own IPrincipal class, see "Appendix " in the Reference section of this book.

Your application’s virtual directory must be configured in IIS for anonymous access.

▸ To configure IIS for anonymous access

A sample configuration is shown below.

<authentication mode="Forms">
  <forms name="MyAppFormsAuth"
       loginUrl="login.aspx"
       protection="Encryption"
       timeout="20"
       path="/" >
  </forms>
</authentication>

Validate credentials against a SQL Server database, or Active Directory.

Obtain roles from a table within a SQL Server database, or groups/distribution lists configured within Active Directory. Refer to the preceding resources for details.

Store the retrieved roles in the ticket. This is illustrated in the following code.

// This event handler executes when the user clicks the Logon button
// having supplied a set of credentials
private void Logon_Click(object sender, System.EventArgs e)
{
  // Validate credentials against either a SQL Server database
  // or Active Directory
  bool isAuthenticated = IsAuthenticated( txtUserName.Text,
                                          txtPassword.Text );
  if (isAuthenticated == true )
  {
    // Retrieve the set of roles for this user from the SQL Server
    // database or Active Directory. The roles are returned as a
    // string that contains pipe separated role names
    // for example "Manager|Employee|Sales|"
    // This makes it easy to store them in the authentication ticket

    string roles = RetrieveRoles( txtUserName.Text, txtPassword.Text );

    // Create the authentication ticket and store the roles in the
    // custom UserData property of the authentication ticket
    FormsAuthenticationTicket authTicket = new
       FormsAuthenticationTicket(
                    1,                          // version
                    txtUserName.Text,           // user name
                    DateTime.Now,               // creation
                    DateTime.Now.AddMinutes(20),// Expiration
                    false,                      // Persistent
                    roles );                    // User data
    // Encrypt the ticket.
    string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
    // Create a cookie and add the encrypted ticket to the
    // cookie as data.
    HttpCookie authCookie =
              new HttpCookie(FormsAuthentication.FormsCookieName,
                             encryptedTicket);

    // Add the cookie to the outgoing cookies collection.
    Response.Cookies.Add(authCookie);
    // Redirect the user to the originally requested page
    Response.Redirect( FormsAuthentication.GetRedirectUrl(
                       txtUserName.Text,
                       false ));
  }
}

Create the IPrincipal object in the Application_AuthenticationRequest event handler in Global.asax. Use the GenericPrincipal class, unless you need extended role-based functionality. In this case create a custom class that implements IPrincipal.

The creation of a GenericPrincipal object is shown below.

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
  // Extract the forms authentication cookie
  string cookieName = FormsAuthentication.FormsCookieName;
  HttpCookie authCookie = Context.Request.Cookies[cookieName];
  if(null == authCookie)
  {
    // There is no authentication cookie.
    return;
  }
  FormsAuthenticationTicket authTicket = null;
  try
  {
    authTicket = FormsAuthentication.Decrypt(authCookie.Value);
  }
  catch(Exception ex)
  {
    // Log exception details (omitted for simplicity)
    return;
  }
  if (null == authTicket)
  {
    // Cookie failed to decrypt.
    return;
  }
  // When the ticket was created, the UserData property was assigned a
  // pipe delimited string of role names.
  string[] roles = authTicket.UserData.Split(new char[]{'|'});

  // Create an Identity object
  FormsIdentity id = new FormsIdentity( authTicket );
  // This principal will flow throughout the request.
  GenericPrincipal principal = new GenericPrincipal(id, roles);
  // Attach the new principal object to the current HttpContext object
  Context.User = principal;
}

Use declarative principal permission demands to restrict access to methods. Use imperative principal permission demands and/or explicit role checks (IPrincipal.IsInRole) to perform fine-grained authorization within methods.

For more information about this issue, and for resolution techniques, see the following Knowledge Base articles:

For more information about Mobile Forms Authentication, see article Q311568, "INFO: How To Use Mobile Forms Authentication with Microsoft Mobile Internet Toolkit," in the Microsoft Knowledge Base.

For more information about the "Act as part of the operating system" privilege, see the Microsoft Systems Journal August 1999 Security Briefs column.

In general, it is not advisable to run your Web server on a domain controller, because a compromise of the server is a compromise of the domain. If you need to run ASP.NET on a domain controller, you need to give the ASP.NET process account appropriate privileges as outlined in article Q315158, "BUG: ASP.NET Does Not Work with the Default ASPNET Account on a Domain Controller," in the Microsoft Knowledge Base.

The <processModel> element in the Machine.config file contains the userName and password attributes which specify the account that should be used to run the ASP.NET worker process (Aspnet_wp.exe).

You have a number of options for configuring the <processModel> userName attribute. For example:

If you use custom credentials, use the aspnet_setreg.exe utility to store encrypted credentials in the registry. Avoid storing plain text credentials in machine.config.

For details about this utility and to download it, see article Q329290, "HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" in the Microsoft Knowledge Base.

The following sample shows the format of the userName and password attributes before and after using this utility. Notice how the attribute values point to the secured registry key and named values that contain the encrypted credentials.

<!--Before -->
<processModel userName="SomeCustomAccount"
              password="ClearTextPassword" . . ./>

<!-- After -->
<processModel
         userName="registry:HKLMSOFTWAREYourSecureAppprocessModel
                   ASPNET_SETREG,userName"
         password="registry:HKLMSOFTWAREYourSecureAppprocessModel
                   ASPNET_SETREG,password" . . ./>

For more information about how to configure Kerberos delegation, see:

For more information about installer classes and the InstallUtil.exe utility, see the ".NET Framework Tools" section of the .NET Framework SDK on MSDN.

By default, ASP.NET uses MTA threads to process requests. This results in a thread-switch when an Apartment model object is called from ASP.NET, because the Apartment model object can’t be accessed directly by MTA threads (COM would use an STA thread).

Specifying AspCompat causes the page to be processed by an STA thread. This avoids a thread switch from MTA to STA. This is important from a security perspective if your Web application is impersonating because a thread switch results in a lost impersonation token. The new thread would not have the impersonation token associated with it.

The AspCompat directive is not supported for ASP.NET Web services. This means that when you call Apartment model objects from Web service code, a thread switch does occur and you lose the thread impersonation token. This typically results in an Access Denied exception.

Don’t create COM object outside of specific Page event handlers. The following code fragment illustrates what not to do.

<%@ Page Language="C#" AspCompat="True" %>
<script runat="server">
  // COM object created outside of Page events
  YourComObject obj = new apartmentObject();
  public void Page_Load()
  {
    obj.Foo()
  }
</script>

When you use Apartment model objects, it is important to create the object within specific Page events such as Page_Load, as shown below.

<%@ Page Language="C#" AspCompat="True" %>
<script runat="server">
public void Page_Load()
{
  YourComObject obj = new apartmentObject();
  obj.Foo()
}
</script>

Microsoft C#® development tool and Microsoft Visual Basic® .NET development system support all threading models (Free-threaded, Neutral, Both, and Apartment). By default, when hosted in COM+, C# and Visual Basic .NET objects are marked as Both. As a result, when they are called by ASP.NET, access is direct and you do not incur a thread switch.

For more information about configuring an ASP.NET process account, see "Appendix " in the Reference section of this book.

You can use a separate anonymous Internet user account for each virtual root within your Web site. In a hosted environment, this allows you to separately authorize, track, and audit requests that originate from separate Web applications. This approach is shown in Figure 8.7.

Figure 8.7. Impersonating separate anonymous Internet user accounts per application (v-dir)

▸ To configure the anonymous Internet user account for a specific virtual directory

For more information, see the entry for Cryptography, CryptoAPI and CAPICOM in the Platform SDK on MSDN.

If you use SQL authentication to connect to the server, the connection string specified on the sqlConnectionString attribute contains a user name and password. Use the aspnet_setreg.exe utility to store an encrypted connection string in the registry. The following example shows the <sessionState> element before and after using aspnet_setreg.exe.

<!-- Before -->
<sessionState
    mode="SQLServer",
    sqlConnectionString="data source=Server;user id=userID;password=pwd" . . . />
<!-- After -->
<sessionState mode="SQLServer"
              sqlConnectionString="registry:HKLMSOFTWAREYourSecureApp
              sessionStateASPNET_SETREG,sqlConnectionString" />

If possible, you should use Windows authentication to the SQL Server state database. This has the added advantages that the connection string doesn't contain credentials and credentials are not passed over the network to the database server.

▸ To use Windows authentication, you can use the ASP.NET process identity (typically ASPNET)

You can then change the connection string to use a trusted connection, as shown below:

sqlConnectionString="server=127.0.0.1;
                     database=StateDatabase;
                     Integrated Security=SSPI;"

You may need to protect the session state as it crosses the network to the SQL Server database. This depends on how secure the network hosting the Web server and data servers is. If the database is physically secured in a trusted environment, you may be able to do without this extra security measure.

You can use IPSec to protect all IP traffic between the Web servers and SQL Server, or alternatively, you can use SSL to secure the link to SQL Server. With this approach, you have the option of encrypting just the connection used for the session state, and not all traffic that passes between the computers.

For more information about DPAPI, see Chapter 12.

The value of the validationKey attribute is used to create and validate MAC codes for view state and Forms authentication tickets. The validation attribute signifies what algorithm to use when performing the MAC generation. Note the following:

The value of the decryptionKey attribute is used to encrypt and decrypt Forms authentication tickets and view state. The DES or Triple DES (3DES) algorithms are used. The precise algorithm depends on whether or not the Windows 2000 High Encryption Pack is installed on the server. If it is installed 3DES is used, otherwise DES is used. Note the following:

This attribute dictates what algorithm to use when validating, encrypting, or decrypting. It can take the values SHA1, MD5, or 3DES. The following describes these values: