Microsoft Identity and Access Management - Developing Identity-Aware ASP.NET Applications

Chapter 1: Introduction to the Developing Identity-Aware ASP.NET Applications Paper

Executive Summary

Organizations today are looking for guidance on how to avoid introducing new directories and authentication schemes that increase complexity and undermine the goals of a successful identity and access management strategy.

This paper provides guidelines for developing applications that use the directory and security services of the Microsoft® Windows® platform. Specifically, the paper discusses identity considerations and guidelines when developing Microsoft ASP.NET multitier extranet and intranet Web applications. You can develop these applications using Microsoft Visual Studio® .NET and Microsoft Windows Server™ 2003 directory and security services.

The Business Challenge

Most organizations accumulate legacy applications that do not integrate well with each other or with enterprise directory services. The challenge for these organizations is to create an architectural model that will better integrate their applications. The goals of this model could include one or more of the following:

• The ability to develop line-of-business (LOB) applications more rapidly.
• Achieve greater security.
• Capitalize on a consistent authorization policy model and data.
• Effectively use existing provisioning mechanisms.
• Provide secure access for different types of users.
• Meet the authentication, authorization, and audit requirements of new industry and government regulations.

The Business Benefits

A strategy and architecture for developing identity-aware applications helps organizations achieve the following benefits:

• Reduce application development costs for faster time to market.
• Develop more robust applications.
• Confront fewer vulnerabilities.
• Reuse existing mechanisms and solutions.
• Obtain more secure access control.
• Comply with regulatory requirements.

Who Should Read This Paper

The intended audience for this paper includes architects, developers, technical decision makers, and consultants involved in identity and access management efforts.

Reader Prerequisites

This paper assumes the reader has a moderate knowledge of identity and access management concepts and technologies, as described in the "Fundamental Concepts" paper in this series.

Understanding and implementing the solutions in this paper requires a good familiarity with the "Intranet Access Management" and "Extranet Access Management" papers in this series — Microsoft strongly recommends reading both papers before continuing with this one.

Readers who wish to use the code samples provided with this paper should be familiar with developing ASP.NET applications in Visual Studio .NET.

Note   This paper does not cover all of the details you should consider for writing secure code and ensuring application security. It only covers topics that are specifically concerned with the use of digital identities in ASP.NET applications within a Windows Server 2003 environment.

For more information about end-to-end application security and writing secure code, see the following resources:

• "Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication" on MSDN®.
• Writing Secure Code, Second Edition.

Paper Overview

This paper consists of the following seven chapters:

Chapter 1: Introduction to the Developing Identity-Aware ASP.NET Applications Paper

This chapter provides an executive summary, the recommended audience for the paper, and an overview of each chapter in the paper. The chapter also introduces the specific solution scenarios that will be discussed in chapters 3 – 7.

Chapter 2: Approaches to Developing Identity-Aware ASP.NET Applications

This chapter provides background information about several authentication approaches for clients using browsers in intranet and extranet applications for business-to-business (B2B), business-to-employee (B2E), and business-to-consumer (B2C) scenarios. It discusses authorization and the various ways that you can flow identity across application tiers, including the pros and cons of each method.

The chapter also discusses auditing, and how to ensure that the appropriate security events are logged for each of the techniques described.

Chapter 3: Issues and Requirements

This chapter introduces the business problems that Contoso Pharmaceuticals (the fictitious company used in this series) faces, and then outlines the business issues, technology issues, and security issues that Contoso has identified for each solution scenario. It then highlights the key requirements of each solution that Contoso will build.

Chapter 4: Designing the Solution

This chapter discusses the solution concept, architecture, necessary prerequisites, and how each of the scenario solutions work.

Chapter 5: Implementing the Solution

This chapter describes the tools and templates that are available for this paper, and provides the prescriptive steps required to implement the solutions that Contoso built for each scenario.

Chapter 6: Testing the Solution

This chapter describes how to validate the implemented solution scenarios and includes some troubleshooting steps and testing techniques to help you with common implementation challenges.

Chapter 7: Deployment Considerations

This chapter discusses several topics for consideration specific to deploying identity-aware ASP.NET solutions, such as using setup applications and custom installers.

Solution Scenarios

The scenarios in this paper are based on Contoso Pharmaceuticals, the fictitious company introduced in this series in the "Platform and Infrastructure" paper.

In addition to a general discussion of identity-aware development approaches, this paper also provides detailed prescriptive guidance for implementing intranet and extranet ASP.NET applications that are integrated with Active Directory.

The scenarios were compiled to illustrate the typical challenges organizations face, and include guidance on how you can use Microsoft technologies to address them. Chapters 3 through 7 focus entirely on the ASP.NET intranet and extranet solution scenarios.

ASP.NET Intranet Applications

This solution scenario discusses the solution template that Contoso Pharmaceuticals built to ensure that all of the company's intranet ASP.NET applications properly use Windows Server 2003 directory and security services.

This scenario discusses Contoso employees who need to access Contoso applications using a Web browser and Windows-integrated authentication. The sample code for this scenario shows two ways to pass identity information between tiers, how to implement different types of authorization, and how to access back-end resources. The Windows platform provides security event logging for auditing purposes.

ASP.NET Extranet Applications

This solution scenario discusses the solution template that Contoso Pharmaceuticals built to ensure that all of the company's extranet ASP.NET applications properly use Windows Server 2003 directory and security services.

This scenario discusses client authentication mechanisms for the following types of extranet access for users who must access the same application:

• B2B. Partners access the extranet application using a Web-browser and Forms-based authentication.
• B2E. Employees access the extranet application using Microsoft Internet Explorer and X.509 certificates.
• B2C. Customers access the extranet application using a Web-browser and Microsoft Passport authentication.

Note   See the "Identity Aggregation and Synchronization" paper in this series for more information about how Contoso provisions employee certificates.

The sample code for this scenario shows two ways to pass identity information between tiers, how to implement different types of authorization, and how to access back-end resources.

Security event logging for auditing purposes is provided by the Windows platform in the B2E and B2C scenarios for both authentication and authorization. The B2B scenario uses custom Forms-based authentication, and the application provides auditing for authentication. Authorization auditing is provided by the Windows platform.

Chapter 2: Approaches to Developing Identity-Aware ASP.NET Applications

There are four fundamental areas that application architects and developers need to consider when developing identity-aware ASP.NET applications. These areas are:

• Approaches for authentication. These approaches focus on determining which authentication method is appropriate. These methods are described later in this chapter and in the "Intranet Access Management" and "Extranet Access Management" papers in this series.
• Approaches for authorization. These approaches focus on determining which of the two fundamental models for authorization is appropriate for your organization, or whether they can be combined. These models are described later in this chapter.
• Approaches for passing identity information between application tiers. These approaches focus on determining which of the three identity flow models are appropriate, or whether they can be combined. These models are described later in this chapter.
• Approaches for security auditing. These approaches focus on determining where and how to implement security auditing.

The choices you make in these areas also affect testing and deployment of the identity-aware code. On the Microsoft® Windows® platform, well-integrated applications require implementation of little or no identity-aware code. This paper provides information about what application developers need to write by providing common scenarios to illustrate how they and application architects can integrate applications with your infrastructure.

Considerations and Best Practices

The application developer and architect have the greatest potential to directly influence how applications integrate with the organization's identity and access management infrastructure. In general, applications that rely on either platform or widely-deployed middleware security services integrate well with the larger infrastructure. Applications that integrate well also are:

• Easier to manage because they do not introduce additional user identity stores.
• More secure than one-off application developer-designed security mechanisms.
• Easier to integrate with other software systems; because it is easier to find a common ground for interoperability.

For these reasons, this paper will focus on integrating applications with Windows security services for both authentication and authorization. Because Windows security services operate by default with the Microsoft Active Directory® directory service, it is a derivative best practice to authenticate users against Active Directory. Although you could use other types of identity stores in certain scenarios, for example Active Directory Application Mode (ADAM) or Microsoft SQL Server™, these are not recommended in general because they offer less flexibility in how you can perform user authentication.

The application architect should, as a rule, design systems that are robust and modular. Application changes should not be required to take advantage of new ways to authenticate or authorize users. The security services provided by the Windows platform were designed with exactly this requirement in mind, and these services will evolve over time to support and integrate seamlessly with emerging industry standards, such as Web Services-Security and Security Assertion Markup Language (SAML).

Authentication

The Windows platform supports many different authentication mechanisms. The general characteristics of these mechanisms are described in Chapter 6, "Access Management," of the "Fundamental Concepts" paper in this series. The "Intranet Access Management" paper in this series also describes how the Kerberos version 5 authentication protocol works on the Windows platform, as well as how Windows-integrated authentication works between Microsoft Internet Explorer and Microsoft Internet Information Services (IIS). This chapter also introduces a few additional authentication considerations that are specific to ASP.NET applications.

When designing an ASP.NET application, it is important to understand that authentication occurs at many levels. For example, authentication happens when each of the following events take place:

• A browser client authenticates to a Web server.
• The Web server authenticates to an application server.
• The application server authenticates to a back-end resource server.

Figure 2.1. Relationships in the role-based access control (RBAC) model

It is equally important for the application architect to understand the differences between intranet and extranet environments. For example:

• Some authentication mechanisms cannot be used in the extranet environment due to network and firewall configuration.
• Intranet and extranet environments are connected through different means. The "Extranet Access Management" paper in this series discusses approaches for connecting these environments using domain trust, PKI trust, and shadow accounts.

Because of these constraints and differences, application architects need to carefully choose, and sometimes combine, authentication mechanisms for their applications.

Windows-Integrated Authentication

For most intranet scenarios the recommended approach is to choose Windows-integrated authentication and the Kerberos authentication protocol as an end-to-end solution. This approach works well on the Windows platform, and when you are integrating with other platforms that support the Kerberos version 5 protocol. The "Intranet Access Management" paper in this series describes this type of integration with third-party applications and platforms, such as UNIX, SAP R/3 Application Server, mainframes, J2EE, and so on.

For applications hosted in the extranet there are several "integrated" authentication mechanisms that you can use other then the Kerberos protocol or NTLM. The available authentication protocols include Microsoft Passport, Secure Sockets Layer (SSL) client authentication, Basic, and Digest authentication. These mechanisms are fully described in the "Extranet Access Management" paper in this series. This paper will describe in more detail how ASP.NET applications in particular can take advantage of the authentication mechanisms that are implemented in and integrated with IIS.

The important aspect of IIS-integrated authentication mechanisms for developers is that the ASP.NET application does not need any additional code in order to perform authentication. The IIS host provides all authentication. This is a tremendous advantage when an organization is trying to standardize the development process. Because all authentication is controlled by configuration on the Web server, there is no code in the application to standardize.

An additional important aspect of IIS-integrated authentication mechanisms is that a Windows security context (in the form of an "impersonation token") is created as a result of every successful authentication. Depending on the configuration of the ASP.NET application, IIS will attach the impersonation token to the current request before invoking the ASP.NET application. Generally, this approach provides a simple and efficient way to make authorization decisions using a variety of mechanisms.

Forms-based Authentication

Another authentication option that is especially suitable and appealing for the extranet is Forms-based authentication, which is conceptually straightforward. The Web application presents a "form" to the user that asks for credentials, most often a user name and password. After this information is collected, the application is then responsible for validating that the credentials provided match the user object in some identity store.

Forms-based authentication differs from IIS-integrated authentication in that the application implements the collection and verification of credentials. This approach gives the application more flexibility in how to validate the credentials themselves, as well as the opportunity to handle authentication failures more gracefully by providing additional information to the user.

Although it is possible to validate credentials (passwords) collected through Forms-based authentication by using an identity store other than Active Directory, this approach will not be discussed in this paper. When authenticating against Active Directory, there are two basic approaches to validating user credentials that apply:

• Credential validation using Lightweight Directory Access Protocol (LDAP).
• Credential validation using Windows security services.

Credential Validation Using LDAP

One approach is to authenticate the user using LDAP bind. Within the context of ASP.NET applications, this approach offers a couple of advantages:

• The application is not bound to Active Directory because other LDAP v3-compliant directories support this method.
• The application programming interface (API) used to validate credentials through this mechanism is part of a managed class called System.DirectoryServices.

The disadvantages of the LDAP bind approach include:

• If the application requires access to local resources using the security context of the user (impersonation), then the application must be given extensive local privileges ("Act as Part of the Operating System") in order to generate an impersonation token for the authenticated user using the LsaLogonUser() API.

  Note   The application could use the LogonUser() API to generate an impersonation token if it saved the password in memory or shared state (if the application runs in a Web farm) and if it was running on Windows Server 2003 or later. If both of these conditions are met, then elevated privileges would not be required. However, it is strongly recommended that applications do not persist passwords in application memory or shared state. Because it is assumed that a password is not available, then only the Protocol Transition approach (described later in this chapter) can be used. This approach requires elevated privileges for the application.

• "One-hop" delegation (described in the "Identity Flow" section of this paper) will not be possible because there are no credentials associated with the authenticated user context.

There are two additional points to consider when discussing credential validation using LDAP bind:

• The .NET Framework System.DirectoryServices class implements LDAP bind in the most secure manner. If the application developer uses another interface for LDAP bind, such as the native Win32 API, then they must ensure that plaintext passwords are not transmitted over the network. See the "Intranet Access Management" paper in this series for more information about security considerations when using LDAP bind.
• The recommended mechanism in this paper for acquiring and using authorization information related to the authenticated user is Windows Authorization Manager. While this is discussed in detail below, the reader should note that Windows Authorization Manager takes advantage of Windows platform services in order to generate and cache authorization information from Active Directory in a very efficient and carefully designed manner regardless of how authentication is accomplished.

If the application developer chooses to use some other authorization approach, then the developer will likely need to revisit how authentication is implemented by the application in order to ensure that the application does not overload the domain controller by repeated authentication and authorization data requests.

Credential Validation Using Windows Security Services

Another approach to consider is the use of Windows security services. Specifically, the native Win32 LogonUser() API, to validate the credentials. On the Windows platform, this approach has several advantages:

• The application does not require any additional privileges in order to create an impersonation token that can be used to access local server resources in the user's context.

  Note   This represents a modification between Microsoft Windows 2000 Professional and Windows Server™ 2003. On the Windows 2000 platform, applications require the Act as part of the operating system privilege to be enabled in order to call the LogonUser() API.

• One-hop delegation (described in the "Identity Flow" section of this paper) works by default.
• Application authorization code often depends on the authentication mechanism. By using LogonUser(), the starting point for authorization is identical for Forms-based authenticated users, and users who are authenticated using Windows Integrated Authentication in IIS.

The disadvantage of the Win32 API LogonUser() approach is:

• ASP.NET applications need to invoke the Windows native code since there is no managed class that provides this functionality.

Finally, the application developer should consider the performance characteristics of the different credential validation models. If you follow the authentication and authorization recommendations in this paper, then the overall performance characteristics of either credential validation method are approximately equal. However, detailed performance analysis will show that the LogonUser() approach introduces performance loading at the front-end of the authentication authorization cycle for each user. The LDAP bind-Authorization Manager approach will distribute the load across a greater period of time.

After users are authenticated in your environment, they need to be authorized. The following sections discuss models for authorization, and models for flowing identity between the application tiers to provide authentication and authorization on downstream servers.

For more information about using Forms-based authentication with Active Directory, see the MSDN Article "How To: Use Forms Authentication with Active Directory in ASP.NET 1.1".

Authorization

There are two fundamental models for authorization that application developers can use separately or combine:

• The access control list (ACL) model.
• The role-based access control (RBAC) model.

The Access Control List Model

Microsoft Windows operating systems have supported the use of ACLs for access control to applications since the introduction of the Private Object Security application programming interface (API) in Microsoft Windows NT® Server 4.0. In the ACL model, you can attach discretionary access control lists (DACL) to a securable object and make access decisions by calling the Windows AccessCheck API. This API compares a user's group membership information in an impersonation token, and then compares it to the contents of the ACL to determine if the user has the requested access rights.

Note   The AccessCheck API mentioned here refers to the Win32 API named AccessCheck, and should not be confused with the AccessCheck method of an object provided by the Authorization Manager API used for role-based authorization.

The ACL model is ideal for many types of applications. Resource managers who have well-defined persistent objects use the ACL model appropriately to provide object-level access control. Examples of well-defined persistent objects include:

• Files
• Printers
• Directory objects
• Registry keys and data

In resource manager applications, access control decisions can always be made in terms of a user requesting access to an existing object. In the future, applications that use the ACL model should use AuthzAPI, which was introduced in Microsoft Windows XP Professional and Windows Server 2003. It provides enhanced performance and flexibility over the Windows NT Private Object Security APIs. For more information about AuthzAPI, download the Windows Server 2003 SP1 Platform SDK Web Install from the Microsoft Download Center.

A distinct authorization problem exists for some line-of-business (LOB) applications, such as Web expense reporting applications or shopping applications. For these applications, the authorization decisions do not determine access to well-defined persistent objects. Instead, they verify a workflow or perform multiple distinct operations, such as querying a database and sending e-mail.

In LOB applications, access decisions are often based on complex business logic, such as the amount submitted in an expense application or verification of workflow completion. These decisions are not based only on relatively static information such as token group membership. Applications that do not have well-defined persistent objects have no place to put an ACL, so the ACL model can be harder to apply in these applications.

The Role-Based Access Control Model

Traditional access control administration models are based on objects. In these models, access control is specified by an ACL attached to the object or object container and the administrator must access the object to query and specify access control rights. These models require administrators to translate the organizational authorization policy into permissions on objects. Each object has a list of access permissions that is granted to various users and groups within an organization. Role-based access control (RBAC) simplifies access control administration so that you can manage enterprise environments more effectively using permissions related to user job roles.

You can also use groups to accomplish some RBAC goals for the organization. A group corresponds to an employee role, and application administrators can specify the permissions that the role needs by granting the group permission in a DACL for the object. As object collections grow, the number of places where administrators need to manage permissions grows. Diligent use of resource groups and user groups can help minimize this effort, but this approach requires consistent practice and coordination among administrators, and precise definitions for resource groups. Because these processes slow down the administrative process, administrators often avoid them.

In addition, querying users granted access to a particular group or role across an application becomes more difficult as the number of objects grows. To determine accurately what permissions are granted to a user or group, administrators must examine the permissions on every object. While inheritance appears to simplify this, the ability of each object to avoid inheriting permissions still makes it necessary to look at each object to fully understand the authorization policy. As the number of objects becomes too many to effectively query, the state of access control with respect to a particular group or user becomes harder to verify.

On the other hand, RBAC enables administrators to specify access control in terms of the organizational structure of a company. RBAC does this by creating a new object called a role. You assign a user to a role to perform a job function. However, unlike groups, a role defines the authorization permissions on a set of resources. In the RBAC model, the administrator uses the role to manage permissions and assignments.

For example, a company may create a role called Sales Manager with permissions needed by sales managers to perform their jobs. When sales managers are hired, they are assigned the Sales Manager role and instantly have all of the required permissions that they need. When a sales manager leaves or takes another position, the person is removed from the Sales Manager role and no longer has access to resources available to other managers in this role. Since the role allows access to be granted in terms of a company's organizational model, it is more intuitive and natural for administrators to specify access control. The following figure identifies the relationship between the role, users, and permissions. In this model, the role is the object to which permissions are granted, and the users are assigned to the role.

Figure 2.2. Relationships in the role-based access control (RBAC) model

RBAC maps user job roles to application permissions so that access control administration can be accomplished in terms of a user's job role. Since the permissions are granted at the role level, they can be queried and changed for the role without examining the specific resources. In most environments, after the role permissions are established there will be little need to change them, especially when compared to changes in assignments to the role. This factor means that administrators will have to set up roles, such as Employee, Manager, and Administrator. However, after the roles are created, administrators will manage membership in the roles, not the permissions on the objects.

The RBAC system allows you to define roles in terms of application permissions, which are then assigned to users to grant them the permissions associated with the role without incurring the management overhead of object-based administration.

There are two main technologies available for implementing RBAC from ASP.NET applications. You can use each of these technologies to implement URL authorization for IIS 6.0, and role-based security for ASP.NET applications as follows:

• Use .NET Framework roles for:
  • URL Authorization
  • Role-based security
• Use Windows Authorization Manager for:
  • URL Authorization
  • Role-based security

You can use both technologies for the same purposes. In general, Windows Authorization Manager is the preferred mechanism for implementing RBAC in ASP.NET applications. The following sections explain the pros and cons of each approach.

.NET Framework Roles

The built-in capabilities of ASP.NET provide two ways of implementing role-based authorization:

• URL authorization
• Role-based security

ASP.NET URL Authorization

ASP.NET provides URL authorization, which applies to file types mapped by IIS to the ASP.NET Internet Server Application Programming Interface (ISAPI) extension. URL authorization determines whether a user or role can issue specific HTTP verbs (for example, GET, HEAD, and POST) to a specific URL. To configure URL authorization, you add an <authorization> element to your application's Web.config file, and then restrict access to users and roles by using allow and deny attributes. The following example shows how you can allow Bob and Mary access but deny everyone else:

<authorization>
  <allow users="DomainName\Bob" />
  <allow users="DomainName\Mary" />
  <deny users="*" />
</authorization>

ASP.NET URL authorization also allows for access based on role, as demonstrated by the following example:

<authorization>
  <allow roles="BUILTIN\Administrators" />
  <deny users="*" />
</authorization>

Note   When you use Windows authentication, user names take the form DomainName\UserName, and roles map on a one-to-one basis with Windows security groups.

Although ASP.NET URL authorization provides basic role-based access at the URL level, the manual configuration it requires through the Web.config files makes it somewhat unwieldy for an enterprise environment.

.NET Role-Based Security

ASP.NET applications can use the IsInRole method of the Windows Principal class (System.Security.Principal namespace) to make run-time, role-based authorization decisions. The following code sample shows how easy this mechanism is to use:

if (User.IsInRole("BUILTIN\\Administrators"))
   ExecutePrivilegedOperation();

In .NET role-based security, roles are derived directly from server local groups or Active Directory groups. The application is coded during development to require certain roles for certain operations.

.NET role-based security directly uses the authorization information (in the form of Windows groups) that is included in the Windows impersonation token. This token is created automatically when using Windows or IIS-integrated authentication mechanisms.

When using form-based authentication against Active Directory, the token can be created by constructing a WindowsIdentity object and passing a User Principal Name (UPN) to the constructor as shown in the following code sample:

if(HttpContext.Current.User.Identity is FormsIdentity ) 
{
    WindowsIdentity formsUser = new 
        WindowsIdentity(HttpContext.Current.User.Identity.Name);
    if(formsUser.IsInRole("BUILTIN\\Administartors"))
        ExecutePrivilegedOperation();
}

However, when using Forms-based authentication against identity stores other than Active Directory, the developer needs to do much more work.

This includes manually calling the other identity stores and requesting a list of roles associated with the user, manually creating a new GenericPrincipal object based on these roles, and assigning the new GenericPrincipal object to the ASP.NET User object as displayed in the following code sample:

public void Application_AuthenticateRequest(Object s, EventArgs e)      
{
   if (HttpContext.Current.User != null)
   {
      if(HttpContext.Current.User.Identity is FormsIdentity ) 
      {
         System.Web.Security.FormsIdentity id = HttpContext.Current.User.Identity;
         String[] myRoles;
         myRoles = GetArrayOfRolesFromIdentityStore(id.Name); //TODO:Implement this!
         HttpContext.Current.User = new 
System.Security.Principal.GenericPrincipal(id, myRoles);
      }
   }
}

Because roles are assigned automatically during authentication, it should be obvious that the developer has to do less work for .NET role-based authorization when using Windows-integrated authentication.

Another issue to consider is the definition of the roles needed to access certain application functionality, which will be hard-coded into the application. An example of a potential issue with this approach is that if a new role (group) needs to be added to the list of users who can access a particular function, then the application code will likely need to be updated to reflect this change in authorization policy. Other authorization mechanisms discussed later in this chapter do a better job of abstracting roles from the application and isolating authorization policy changes from the application code.

Windows Authorization Manager

Windows Server 2003 introduced Windows Authorization Manager. You also can download Windows Authorization Manager for the Windows 2000 platform on microsoft.com. This role-based authorization mechanism is an attractive option to the basic authorization functionality of .NET for the enterprise developer because it offers the following:

• Centralized authorization policy for multiple applications.
• Security groups that you can create outside of Active Directory that an application administrator can manage.
• Groups that you can create based on the result of an LDAP query.

Windows Authorization Manager relies on a policy store that holds authorization policy for one or more applications. The policy store is a somewhat hierarchical supporting policy that contains application group definitions. Management of application policy can be delegated to application administrators as long as you choose Active Directory as the policy store location. XML is the other possibility for storing the authorization policy but this is not a recommended option for enterprise-scale deployments.

Unlike .NET Framework roles, Windows Authorization Manager requires that the user being authorized to perform an action is represented as an actual account on the Web server or a user account in Active Directory. For the developer who is integrating their application with an identity and access management infrastructure, this is not an issue because the goal is to use existing accounts and not create a new application-specific identity store.

Windows Authorization Manager takes advantage of the identity infrastructure by establishing user role assignments through three powerful mechanisms:

• Membership in Active Directory, local server, or Windows Authorization Manager groups
• LDAP query groups
• BizRules

Since group membership and LDAP attributes are pieces of information that can be managed across the organization by identity management processes and technology, application authorization through Windows Authorization Manager can also be centrally managed without managing individual Web.config files or changing application code. This capability is a huge advantage for this approach.

For more information about Windows Authorization Manager, see the following articles:

• "Role-Based Access Control for Multitier Applications Using Authorization Manager".
• "Dynamic Groups in Windows Server 2003 Authorization Manager".

IIS 6.0 URL Authorization

IIS 6.0 URL authorization provides the same functionality as ASP.NET URL authorization except that it is based on Windows Authorization Manager policy instead of individual application policy in the Web.config files on each Web server. For applications such as Web Services or static content such as .htm Web pages, IIS 6.0 URL authorization is a great option because it uses the same centralized authorization policy store as applications that use the authorization manager runtime for precise access control.

Authorization Manager Role-based Security

Authorization Manager provides a robust tool to the ASP.NET developer for implementing detailed business logic authorization. The previous section described how easy it is to use .NET roles for application business logic authorization. However, Windows Authorization Manager is equally easy to implement in an ASP.NET application, and has the added advantage of being easier to manage in the enterprise environment.

Identity Flow

As an application authenticates users, the entitlements associated with the users' identities can be used to authorize access to local resources and perform privileged operations provided by the application. For applications with multiple tiers, user identities can also be passed to other servers, applications, services, and resources where additional authorization decisions are made and auditing occurs. This process is referred to in this paper as identity flow.

You can use the following three basic models to enable identity flow in your applications (combinations of the models can also be used):

• The Delegation Model
• The Trusted Subsystem Model
• The Credential Mapping Model

The Delegation Model and the Trusted Subsystem Model are commonly used for building Web applications with Web-based technologies, such as ASP.NET. Application architects designing a multitier Web application usually choose one or another of these two models. However, in cases involving more complex applications, the developers can mix the models to support any combination of them.

The Credential Mapping Model is described in the "Intranet Access Management" paper in this series. The following sections explain the other two models, their characteristics, the pros and cons for each model, and the related technologies in various Microsoft products. Links to additional information are also provided.

The Delegation Model

Delegation of authentication is a difficult topic, because delegation is often described within the context of a particular authentication protocol. Since every authentication protocol has different characteristics, delegation often means something different for each protocol. However, in general delegation is the notion that a network resource or service (such as a Web application) can "flow" the identity of a user who originally authenticated to the service to some other service on the network. When this happens, the service is said to delegate the user context or credentials.

Flowing the User's Password

The most basic method of delegation simply passes the plaintext user password around from application component to application component or network resource. The disadvantage of this approach in the enterprise environment is that most applications should not be trusted with this sensitive piece of data.

Even when an application is trusted with user password information, this method of delegation still introduces risks because password-user context management in applications can be tricky to implement correctly. There also is the risk of password exposure if an application server is successfully attacked and penetrated. For these reasons, Microsoft recommends using other types of delegation when possible.

One-Hop Delegation

Another method of delegation that is commonly used on the Windows platform is made possible whenever the application or application server receives the user name and plaintext password during authentication. Such is the case with Forms-based authentication (but only when using the LogonUser() method of validating credentials), and Basic authentication. When either Forms-based auth-LogonUser() or Basic authentication is used, credentials are cached by the Local Security Authority (LSA) on the application server and associated with the client context.

When a connection is made to a back-end service while impersonating the authenticated user, the LSA cache of the user credentials are used to complete either an NTLM or Kerberos authentication with the back-end service. This approach, while having some limitations, is better then managing plaintext passwords at the application level for the purpose of subsequent authentication.

This type of delegation is typically referred to as one-hop delegation. This delegation mechanism is so easy to use that many application developers require Forms-based or Basic authentication just to ensure that they can use it even when more secure authentication mechanisms are available. It is also important to note that one-hop delegation is limited to a single hop as the name implies. If the application uses a three tier architecture design, for example a presentation layer, a business logic and a back-end database, then one-hop delegation will not allow the application to access the back-end database as the user.

The problem of delegation becomes more difficult when an authentication protocol such one of those used for Kerberos, NTLM, or Digest is used for client authentication to the application server. These protocols are specifically designed to hide the actual user credentials from network resources and applications. Since the credentials are hidden, there is no way for an application (or the application server) to use the client credentials to access a different network resource on behalf of the user.

For this reason, when NTLM or Digest authentication is used, delegation is not normally possible except for the opportunity to use Constrained Delegation in Windows Server 2003. This capability is described in more detail in the following section. Unlike NTLM and Digest, the Kerberos authentication protocol has a mechanism for secure delegation built into the protocol itself.

Kerberos Protocol Delegation

With the introduction of Microsoft Windows 2000, the Kerberos version 5 authentication protocol became the default authentication mechanism for the Windows platform. Because the Kerberos protocol has built-in delegation capabilities, it is particularly relevant in this paper to explore how Kerberos protocol delegation works so that ASP.NET application developers can effectively use this functionality when required or desired.

The following sections provide a brief introduction to Kerberos protocol delegation and related concepts:

• Unconstrained Delegation
• Constrained Delegation
• Protocol Transition

Using Unconstrained Delegation with the Kerberos Protocol

With Kerberos version 5 protocol authentication, the browser user (say Alice) requests a service ticket from the key distribution center (KDC) on the domain controller to access resources on the Web server. To get a service ticket for the Web server, Alice proves her identity to the KDC using her password or, in the case of a smart card logon, her private key. The Web server relies on the KDC as the central authentication authority, accepts the service ticket, and constructs a local security context to represent and impersonate Alice.

The Kerberos protocol provides a standard mechanism for delivering additional information during the authentication process. Using this mechanism, the KDC embeds a copy of Alice's ticket-granting-ticket (TGT) inside the service ticket that she presents to the Web server. This copy is a forwarded TGT. With just the service ticket, the Web server can confirm that Alice really does possess her password and construct a local security context for her. However, a copy of Alice's TGT enables the Web server to request service tickets on her behalf to any other service on the network.

In Windows 2000, unconstrained delegation is either enabled or disabled on a per-service basis. Two requirements must be met for Windows 2000 Kerberos protocol-based delegation to work: the Web server must be specifically Trusted for Delegation and Alice's account must not be marked as Sensitive. You can set these properties for user and computer objects using the Active Directory Users and Computers MMC (or Microsoft Management Console) snap-in.

Unconstrained delegation does not match real application deployment models very well because applications are rarely trusted to access any other network resource as the user. For example, there's no valid reason for a customer resource management (CRM) application to authenticate as the user to the organization's Human Resources system. In order to address this security concern, Microsoft created a new delegation mechanism in the Kerberos protocol that does not involve delegation of the user's TGT. Therefore, this new delegation mechanism is more compatible with accepted application security models.

Using Constrained Delegation with the Kerberos Protocol

Windows Server 2003 introduced a new Kerberos protocol delegation mechanism: Constrained Delegation. This new mechanism is constrained because it does not require a forwarded TGT. Instead, a service can use any regular service ticket to obtain additional service tickets to access other resources for the same user.

In the constrained delegation model there is never a concern about a service accessing another service as the user because Active Directory contains a specific list of all services to which delegation can occur. For example, if a CRM application needs to delegate authentication to a SQL Server database, then the database service is listed as a resource to which the CRM application can delegate.

Use of this delegation mechanism requires that the first application server (the Web server for ASP.NET applications) and all domain controllers must be running the Windows Server 2003 operating system. In addition, you must elevate the functional level of the domain to the Windows Server 2003 level. You can host the back-end resource that is being delegated to on Windows 2000 or even a non-Microsoft server that is enabled to use the Kerberos protocol.

Protocol Transition

Since the Kerberos protocol is not appropriate for use on the Internet, Kerberos protocol-based delegation from the client to back-end resources is typically only seen in intranet scenarios. However, a feature called Protocol Transition in Windows Server 2003 allows you to use one authentication model between the client and the Web server, and then transition to Kerberos protocol-based delegation between the Web server and the back-end resource. This features enables Kerberos protocol delegation to work in Internet scenarios.

For more information about constrained delegation and protocol transition, see the article on Kerberos Protocol Transition and Constrained Delegation on the Microsoft TechNet Web site.

Implementing Constrained Delegation

A typical three-tier intranet Web application using the Delegation Model uses the following process flow (as shown in the following figure):

1. The user directs Internet Explorer to request a page that requires authenticated access from IIS 6.0. To require authenticated access, the page or its containing directory must not be configured for Anonymous access within IIS.
2. Internet Explorer and IIS 6.0 negotiate an authentication protocol. In an intranet scenario, Internet Explorer will use the Kerberos protocol logon credentials to request a service ticket for the Web application.
3. The ASP.NET worker process identity is configured as an Active Directory domain account or a built-in account such as Network Service. Configured this way, the ASP.NET worker process can decrypt the Kerberos protocol service ticket and create a Windows impersonation token. With impersonation enabled in the Web.config file, the user's impersonation token is attached to the ASP.NET thread that processes the request.
4. The ASP.NET application can then determine that some data is needed from a back-end resource. If the ASP.NET account has been configured for constrained delegation to the back-end service, the ASP.NET application simply makes a call to the back-end service using Open Database Connectivity (ODBC), DCOM, remote procedure call (RPC), or some other mechanism with the default impersonation credentials. The Kerberos authentication protocol will determine whether constrained delegation is possible.

Figure 2.3. Impersonation and delegation in an intranet multitier Web application

Delegation Advantages and Disadvantages

The Delegation Model provides the following advantages:

• The resource is always accessed as the user. More specific security is enabled at a resource level rather than at the task level. Resource level security is also useful if the resource is accessed from outside the application (such as through a report generator).
• System level access auditing. Since all resources are accessed as the real user on all tiers of the system, you can enable system level access auditing on all tiers. This level of auditing can be very helpful when trying to meet new regulatory requirements for auditing and access reporting.

However, you must weigh these advantages against the following disadvantages:

• No connection pooling. If the remote resource is a database, this method creates connections for each user. This method prevents effective connection pooling and reduces scalability and performance.
• Direct user access available to resources. In some cases users may be able to directly access back-end resources using their normal credentials without going through the preferred application. For example, a user might use a SQL client to run commands directly against the database tier instead of through a business application.
• Not all tiers support the impersonation model for every scenario. A typical example is the back-end service that is hosted on a mainframe or other non-Microsoft server that does not support Kerberos protocol authentication.

These factors make the Delegation Model normally only an option for intranet Web applications.

Support for Delegation in Microsoft Products

Different versions of Microsoft operating systems and applications support delegation to varying degrees. Delegation requires the application to support the Kerberos version 5 authentication protocol. The following tables show the level of operating system and application support for delegation in Microsoft products.

Table 2.1. Delegation Support in Microsoft Operating Systems

Table 2.2. Delegation Support in Microsoft Applications

Important   Use Windows authentication when connecting to SQL Server. SQL Server authentication is not recommended because it means your application has to store connection strings with user names and passwords. You need to take explicit steps to secure credentials passed over the network to SQL Server, and SQL Server authentication introduces a separate set of user accounts to maintain and administer. Also, you cannot apply the same password rules to SQL Server accounts as you can to Windows accounts.

See the following articles for more information about delegation:

• "Planning and Implementing Multitier Applications Using Windows Server 2003 Security Services" available from the Microsoft Download Center.
• "Enable computer and user accounts to be trusted for delegation" on Microsoft TechNet.
• Knowledge Base article "How to Implement Impersonation in an ASP.NET Application".

The Trusted Subsystem Model

In the Trusted Subsystem Model, all authentication and authorization for back-end resources occurs on the Web application server. Typically, this model is used in conjunction with a role-based access control system (such as .NET role-based security or Windows Authorization Manager) that authorizes access to application-defined operations based on the user's role. After successfully authenticating and authorizing the user, the Web application server carries out the requested operation on behalf of the user by using a predefined service account, often the Web application process account.

Implementing this model on a typical three-tier application involves the following tasks:

1. Configuring the ASP.NET application pool to use a domain account that has all the permissions required by the application to the back-end resources. You must ensure that ASP.NET impersonation is disabled in the Web.config file as shown in the following code example, or remove the identity element (impersonation is disabled by default).

   <identity impersonate="false" />

2. Retrieving the authenticated user's token from IIS 6.0 and using Windows Authorization Manager to verify the user's role membership and permissions.
3. Accessing the back-end resource on behalf of the user, using the application pool's domain account.

Note   It is not recommended to use SQL Server authentication with a specific SQL Server account or to use shadow accounts (mirrored local Windows accounts) when the Web application server is separated from the database server by a firewall. Microsoft recommends using Windows-integrated authentication with SQL Server and to configure the firewall to allow authentication traffic.

The following figure shows the Trusted Subsystem model:

Figure 2.4. Accessing back-end resources using the Trusted Subsystem Model

If downstream systems require the original user's identity, possibly for auditing purposes, you can pass the user's identity at the application level from the Web server to downstream systems by using method or stored procedure parameters.

Trusted Subsystem Advantages and Disadvantages

The Trusted Subsystem Model provides the following advantages:

• Simplified permissions management using roles and tasks. Applications using the Trusted Subsystem Model typically use Windows Authorization Manager before accessing back-end resources, which simplifies permissions management by linking permissions to roles and tasks instead of placing ACLs on back-end resources.
• Connection pooling. Because all connections are defined in the context of the service account, SQL Server connection pooling is effective and provides significant scalability and performance improvements for your application. This pooling is only an advantage. However, better performance means that the application will require fewer hardware resources. Performance testing should be conducted in any scenario where scalability will be the determining factor in choosing an identity flow model.
• Access only through the application. Suitable resource configuration will allow access only through the application, not directly through APIs or tools. Note that this restriction might be a disadvantage in certain scenarios.

Important   Microsoft strongly recommends not granting service accounts Full Access or defining them as local administrator accounts. Grant service accounts only enough permission to perform the required operations.

However, you must weigh these advantages against the following disadvantages:

• The service account must be well protected. The service account has access to all back-end data. If the account, the application, or the server host is compromised, all data in the back-end resource will likely be compromised as well.
• No support for system level access audits on resources. Windows Authorization Manager can audit at the application tier before executing the resource access call, but there is no support for system level access audits on downstream tiers because all connections use the service account.

Choosing a Model for Identity Flow and Authorization

There are a number of issues to consider when selecting an appropriate model for identity flow and authorization. The following table lists the key decision criteria.

Table 2.3. Identity Flow and Authorization Model Considerations

Legend:

    Meets requirement

º    May meet requirement — need to confirm for your specific application.

    Does not meet requirement

Combining the Models

Architects and developers can choose to combine the Trusted Subsystem, Delegation, and Credential Mapping models as appropriate for the resources that their applications need to access. The following describes a complex scenario that combines the models.

With Web servers and application servers on separate physical tiers, an architect could choose to use the Delegation Model between Web servers and the application servers. The application servers could then:

• Use the Delegation Model to access a Kerberos version 5 enabled SAP R/3 Application Server.
• Use the Delegation Model to access a Microsoft SQL Server database configured for Windows authentication.
• Use the Trusted Subsystem Model to participate in services providing high transaction throughput.
• Use the Credential Mapping Model to access mainframe resources using RACF user accounts for each user.

Note   All Microsoft products that support the Credential Mapping Model require the request to run under the context of the user that initiated it because credentials can only be retrieved for the current authenticated user. The credential mapping system would have failed if the architect had chosen to use the Trusted Subsystem Model instead of the Delegation Model between the Web server(s) and the application server(s).

Security Auditing

As part of an integrated security framework, the ability to maintain logs that record authentication activity is an essential part of developing identity-aware applications. By monitoring the Security Event Log, it is possible to identify logon attempt records that possibly represent unauthorized access attempts (for example, large numbers of failed authentications). Applications such as Microsoft Operations Manager (MOM) significantly ease the task of monitoring and consolidating event logs located on multiple computers in an enterprise environment.

The responsibility for updating the Security Event Log is handled by the authentication and authorization systems, which automatically create logs of their activity. Applications that use Windows Authorization Manager automatically generate these logs without the developer needing to put specific auditing code in place.

It is often useful to create application-specific audit trails — particularly when Windows Credential Manager and authorization managers are not being used — to record user activity and allow security audits to proceed. If you use the Trusted Subsystem Model, you can pass the original user's identity for auditing purposes to downstream systems by using method and stored procedure parameters.

When using application-specific log files, it is also possible to record additional audit information (beyond simple authentication information) and to create log entries for trusted subsystems that record application-specific information. For example, you can maintain an activity audit trail that keeps track of the changes that a user has made to a resource.

For more information about how to log and capture activity from ASP.NET Web applications, and Web services using the Microsoft Enterprise Instrumentation Framework (EIF), see the Logging and Instrumentation Application Block on MSDN.

Chapter 3: Issues and Requirements

The developers of this series chose the following two types of applications to explain considerations for developing and deploying identity-aware applications using Microsoft® ASP.NET:

• ASP.NET Intranet applications
• ASP.NET Extranet applications

The developers chose these applications because they represent the differences in infrastructure, access patterns, and user types that most organizations must deal with in the intranet versus the extranet environment. However, the biggest advantage for the reader to gain in this paper will be to recognize that the development activities for these two very different application environments are not that different. The Microsoft Identity and Access Management infrastructure that was established in other papers of this series is easy to interact with in order to implement application-level access management.

In the environment for Contoso Pharmaceuticals (the fictitious company used in this series), the Microsoft Windows® operating system provides part of the single sign on (SSO) capability for users to access files, printers, Web sites, and applications.

The following sections in this chapter provides some background on each type of application, as well as business issues, technical issues, security issues, and solution requirements.

ASP.NET Intranet Applications

This section presents a number of issues to consider when developing identity-aware ASP.NET applications that your organization will deploy on in an intranet environment.

Background

Contoso has a large number of intranet applications that provide a range of sensitive and business critical services across a number of different hardware and software platforms. Among these applications, there is no common approach to implementing authentication and authorization in applications. This has led to a proliferation of application-specific identity repositories and authentication solutions.

The resulting complexity and high number of separate accounts has caused user account management to consume a significant portion of the overall administrative budget, and created a security situation in which the number of accounts required has encouraged users to select weak passwords that they do not frequently change.

The company's goal is to introduce a standard approach for developing identity-aware applications that will improve network security and reduce the total cost of ownership (TCO). For these reasons, Contoso decided to standardize application development using Microsoft Internet Information Services (IIS) and ASP.NET because these developer applications offered the best overall value, highest security, and the greatest degree of integration with the organization's identity and access management infrastructure.

Business Issues

Contoso faces the following business issues in the intranet scenario:

• Existing and planned applications use different methods and directories for authentication, which increases development and maintenance costs.
• Applications that use different directories decrease productivity, because users are prompted for different credentials to access each application.
• Existing applications all use their own custom approaches to authorization, which creates many islands of authorization policy that have to be administered separately at great cost.

Technical Issues

Contoso also identified the following technical issue for the intranet scenario:

• Data resources exist on different hardware and software platforms, and the intranet application solution needs to operate across the entire Contoso environment.
• Developers in the organization are confused by the multiple options for access management in ASP.NET.
• Developers in the organization do not all understand how to consistently develop applications that will integrate with the Microsoft Active Directory® directory service.
• Developers in the organization currently implement and maintain significant amounts of custom code for access management purposes.

Security Issues

In addition to the business and technical issues, Contoso also faces the following intranet security issues:

• The existence of multiple application-specific directories in the organization has created a large attack surface.
• In order to provide SSO, many application identity stores in the organization use Active Directory to synchronize credentials . However, the identity stores do not have the same level of security.
• Many applications require plaintext user names and passwords for authentication. This creates the potential for rogue application administrators to compromise passwords or a successful attack that could compromise the application server.
• Many applications pass plaintext credentials over communication channels that are not secure, making the credentials easy to capture with readily available tools.
• Existing applications rely on access control lists (ACL) and groups for "all or nothing" access control to Web applications.
• Applications inconsistently implement security auditing or not at all.

Solution Requirements

The issues listed in the previous sections led Contoso to the following solution requirements:

• Applications will directly integrate with Microsoft Windows Server™ 2003 directory and security services.
• Users will log on to the Windows-based domain from their client computers and experience SSO when accessing Web applications in the intranet.
• To ensure strong authentication and eliminate the storage of plaintext passwords, the Kerberos version 5 authentication protocol will be used from the client through all application tiers that support Kerberos authentication.
• Applications will perform role-based access control (RBAC) using Windows Authorization Manager to provide specific access controls to application functionality.
• Contoso will implement centralized authorization policy and use RBAC in multiple applications.
• Applications must provide security logging for authentication and authorization events across all application tiers to enable security audit capabilities.
• Applications will use Windows platform services for authentication, authorization, and security event logging so that developers will achieve security auditing with minimal effort.

ASP.NET Extranet Applications

This section presents a number of issues to consider when developing identity-aware ASP.NET applications that your organization will deploy in an extranet environment.

Background

The Contoso extranet application environment has many of the same issues as its intranet application environment. In addition, the extranet applications must be able to deal with many different types of users, including employees, customers, and partners. These different users will likely require different types of authentication mechanisms, and the underlying application server will not implement all of them.

The company's goal is to describe a single application architecture that will meet the needs of its different users with the least amount of specialized code.

Business Issues

Contoso faces the following business issues related to the company's business-to-business (B2B) extranet application:

• Existing and planned applications use different methods and directories for authentication, which increases development and maintenance costs.
• Applications that use different identity stores have prompted many complaints from customers and partners because users are prompted for different credentials to access each application.
• Contoso wishes to be viewed as a technology leader in order to bolster the company's image.
• Existing applications all use their own custom approaches to authorization. This creates many islands of authorization policy that have to be administered separately at great cost.

Technical Issues

Contoso has identified the following technical issues for its extranet scenario:

• Most existing extranet applications use Basic or custom authentication mechanisms.
• Basic authentication provides a poor user experience if partners forget their passwords. Contoso would prefer to provide additional information to users in the event of failed logon attempts.
• Data resources exist on different hardware and software platforms, and the extranet application solution needs to operate across the entire Contoso environment.
• Developers in the organization are confused by the multiple options for access management in ASP.NET.
• Developers in the organization do not all understand how to consistently develop applications that will integrate with Active Directory.
• Developers in the organization currently implement and maintain significant amounts of custom code for access management purposes.

Security Issues

In addition to the business and technical issues, Contoso also faces the following extranet security issues:

• The existence of multiple application-specific directories creates a large attack surface.
• In order to provide SSO, many application identity stores in the organization use Active Directory to synchronize credentials. However, the identity stores do not have the same level of security.
• Many applications require plaintext user names and passwords for authentication This creates the potential for rogue application administrators to compromise passwords or a successful attack that could compromise the application server.
• Many applications pass plaintext credentials over communication channels that are not secure, making the credentials easy to capture with readily available tools.
• Existing applications rely on ACLs and groups for "all or nothing" access control to Web applications.
• Applications and identity stores inconsistently implement security auditing or not at all.

Solution Requirements

The issues listed in the previous sections led Contoso to the following solution requirements:

• Extranet applications will use Active Directory as the only identity and authentication directory in order to create a more streamlined provisioning model.
• Contoso will support several secure authentication mechanisms in the extranet, depending on the class of user (employee, customer, and partner).
• Contoso will use delegation between the Web servers and other application tiers in order to track resource access on each tier on a user-by-user basis.
• Contoso will implement centralized authorization policy and use RBAC in multiple applications.
• Applications will perform RBAC using Windows Authorization Manager to provide specific access controls to application functionality.
• Applications using the Trusted Subsystem Model will perform RBAC using Windows Authorization Manager before accessing server-based resources.
• Applications will provide logon functionality as an integral part of the Web site they access. The applications will use pop-up dialogs to prompt users for credentials that will immediately and reliably associate them with the extranet application.
• Applications will use Windows platform services for authentication, authorization, and security event logging so that developers will achieve security auditing with minimal effort.

Chapter 4: Designing the Solution

Chapter 3 considered the business, technical, and security issues for the intranet and extranet applications that Contoso uses, and also listed the solution requirements for these applications. Designing the appropriate platform is the next part of the process.

The following sections present conceptual information, prerequisites, and descriptions of how both the intranet and extranet applications will work in each Contoso scenario. After the design is complete, the solution is ready for implementation.

ASP.NET Intranet Applications

The following sections define the architecture for the Contoso intranet application solution.

Solution Concept

Contoso has decided to create a sample application integrated with the Microsoft® Active Directory® directory service that all of the company's developers can use when starting their own projects.

The application is a simple Microsoft ASP.NET Web application on a server running Microsoft Windows Server™ 2003. The application uses a Microsoft SQL Server™ 2000 database on another computer that also runs Windows Server 2003. The sample code and implementation details in Chapter 5, "Implementing the Solution," describe how to implement either the Trusted Subsystem Model or Delegation Model to pass identity across the tiers. The solution is a sample that Contoso developers can reuse and learn from, because it shows how to implement both models. Contoso developers will need to choose the appropriate model when developing a new application.

Windows Authorization Manager provides role-based authorization, and access control lists (ACL) protect resources. The ACLs are set for trusted service access or for delegation of end user credentials. Contoso chose to use Windows Authorization Manager instead of .NET roles in order to meet the requirement to develop a central authorization policy for all Contoso Web applications.

Clients in the intranet scenario will use Microsoft Internet Explorer 6 on computers that are running either the Microsoft Windows® 2000 Professional or Windows XP Professional operating system. The clients also must belong to the Windows Server 2003 domain for Contoso.

For intranet Web applications, Contoso has chosen to use Windows-integrated authentication in order to provide a single sign on (SSO) experience for users between the Windows logon and the intranet Web application.

Solution Prerequisites

Before you implement this solution, you must have the following infrastructure in place:

• A client computer running Windows XP and Internet Explorer 6. The computer also must be a member of the Active Directory domain.
• A server running Microsoft Internet Information Services (IIS) 6.0 and Microsoft .NET Framework 1.1. The server also must be a member of the Active Directory domain. This server will act as the Web and application server for the sample application.
• A database server running SQL Server 2000 and Windows Server 2003 joined to the Active Directory domain, and that has the Northwind sample database installed on it. The sample application uses SQL Server 2000 and the Northwind database as a back-end resource example.
• Active Directory on a computer running Windows Server 2003 with the domain and forest functional level set to Windows Server 2003. This is required in order to store Windows Authorization Manager policies centrally in Active Directory, and to perform constrained delegation using the Kerberos version 5 authentication protocol.

Solution Architecture

The sample application is a simple one-page application that displays employee information from the Northwind database. The application is designed to show how to implement the Trusted Subsystem Model and the Delegation Model in an ASP.NET application. To show what is going on, the sample application also displays identity related information.

The following diagram shows the most important classes of the sample. There is only one page in the sample (named default), and it displays a databound DataGrid control with employee information and a user control with identity information. The Employee class gets its data from a SQL Server table by using the SqlData helper class after performing an access check using the Authorization Manager or AzMan helper class. The AllowAccess method of the AzMan class always returns the value true when the sample is configured to use the Delegation Model. When the sample is configured to use the Trusted Subsystem Model, the AllowAccess method initializes a Windows Authorization Manager client context, and then calls AccessCheck.

Figure 4.1. UML diagram of the ASP.NET intranet scenario page and classes

How the Solution Works

This section details how the Contoso sample application works after it has been implemented and validated as described in Chapter 5, "Implementing the Solution," and Chapter 6, "Testing the Solution."

The sample code in this scenario implements both the Trusted Subsystem Model and the Delegation Model. The following two figures illustrate the authentication and authorization flow in the scenario using the two different authorization models. The following section describes both models. The Delegation Model uses ACLs for authorization, while the Trusted Subsystem Model uses a combination of ACLs and role-based access control (RBAC) for authorization.

Figure 4.2. Sample intranet ASP.NET application using the Trusted Subsystem Model (the numbers in the figure refer to the steps described below)

Figure 4.3. Sample intranet ASP.NET application using the Delegation Model (the numbers in the figure refer to the steps described below)

Step 1: Users Log On to the Windows Domain

When the Contoso employees arrive at work, they log on to the Windows domain from their Windows-based workstations. Since all Contoso workstations are running Windows 2000 Professional or Windows XP Professional in a Windows Server 2003 domain, the logon process uses the Kerberos version 5 authentication protocol. This step is identical for both the Trusted Subsystem Model and the Delegation Model.

Step 2: The Platform Uses Windows-Integrated Authentication

When Contoso employees browse to the intranet application, Internet Explorer and IIS 6.0 negotiate and agree to use the Kerberos version 5 protocol. Using the Kerberos protocol, Internet Explorer requests a service ticket from the Key Distribution Center (KDC) for the Web server. The Web server then validates this service ticket against the same KDC. This step is identical for both the Trusted Subsystem Model and the Delegation Model. The platform performs this step and no code is required.

Step 3: Access Control Occurs

Each model uses a different process for access control that is described in this step.

Role-Based Access Control (Trusted Subsystem Model)

When using the Trusted Subsystem Model, the class that retrieves the Contoso employee information performs an access control check against Windows Authorization Manager before executing the request in the context of the trusted account. The classes in AzMan.<lang> wrap this access check, and then all that has to occur in the Employee class is a simple call to the AzMan class as shown in the following code sample:

Note   The Windows Authorization Manager Interface that AzMan.<lang> wraps is documented in the Platform SDK article "Authorization Interfaces" on MSDN.

AzMan authorizationManager = new AzMan();
if (authorizationManager.AllowAccess("Employee","All", ReadEmployeeOperation))
{
  ...
}

The AzMan class accesses the Windows Authorization Manager store in the context of the ASP.NET process account, and then initializes the Windows Authorization Manager client context from the Windows impersonation token that IIS 6.0 created.

Since IIS 6.0 does the impersonation, the IIS token is retrieved in ASP.NET by using the ASP.NET User object as shown in the following code sample:

    HandleRef token = new HandleRef(this,
        ((WindowsIdentity)HttpContext.Current.User.Identity).Token);

After the token is retrieved, it is used as a parameter to the InitializeClientContextFromToken method as follows:

AzAuthorizationStoreClass store = new AzAuthorizationStoreClass();
store.Initialize(AZ_AZSTORE_FLAG_ACCESS_CHECK, AzPolicyURL, null);
IAzApplication app = store.OpenApplication(applicationName, null);
IAzClientContext clientContext = 
            app.InitializeClientContextFromToken ((UInt64)token.Handle,0);

Verify Delegation (Delegation Model)

In the Delegation Model, the Web server will attempt to access the back-end resources using the client's credentials. The Windows platform will validate that delegation is properly configured in Active Directory. This processing happens automatically behind the scenes, and no code is required.

Step 4: SQL Server and Other Back-end Resources Are Accessed

When using the Trusted Subsystem Model, the ASP.NET process account is used to access the SQL Server database. When using the Delegation Model, the client's Kerberos protocol service ticket is forwarded by the Web server to the SQL Server. To forward a ticket, the account that runs the application on the Web server must be allowed to delegate. You must configure this process in Active Directory.

For both models, the underlying platform impersonates the user, accesses the resource on behalf of the user, and so on; the Contoso developer only needs to ensure that Windows-integrated authentication should be used. Windows-integrated authentication is supported by most .NET Framework classes, including those used to access the following resources:

• SQL Server (using the System.Data.SqlClient namespace).
• Web services (using the System.Web.Services namespace).
• Active Directory (using the System.DirectoryServices namespace).

To use Windows-integrated authentication to access SQL Server 2000

Use the ConnectionString property on the System.Data.SqlClient.SqlConnection class or the connectionString parameter in the constructor of the same class. Set "Integrated Security=SSPI" in the connection string as shown in the following code sample instead of providing a SQL user name and password. Using this technique frees you from trying to hide and protect such sensitive information. The SQL Server must also be configured for Windows-integrated authentication.

Rather than hard coding your connection string, store it in your application's Web.config file as shown in the following code sample.

<configuration>
  <appSettings>
    <!-- GOOD practice -->
    <add key="SQLConnectionString" value="Persist Security Info=False; Integrated
    Security=SSPI;database=northwind;server=<SQL Server Name>;Connect Timeout=30" />
    <!-- BAD practice
    <add key="SQLConnectionString" value="Persist Security Info=False;
    uid=UserName;pwd=Password;
    database=northwind;server=<SQL Server Name>;Connect Timeout=30" />
    -->
  </appSettings>
</configuration>

The following code sample shows how to retrieve and use the connection string to establish a connection to SQL Server.

using System.Data.SqlClient; 
public void GetSqlData () 
{
  String myConnectString =
            ConfigurationSettings.AppSettings["SQLConnectionString"];
  SqlConnection myConnection = new SqlConnection(myConnectString);
  try
  {
    myConnection.Open();
    // Execute queries against the database
  }
  finally
  {
    myConnection.Close();
  }
}

More information about how to perform data access from .NET Framework applications is available in the following documents:

• The .NET Data Access Architecture Guide on MSDN.
• The article "Data Access Application Block".

The remainder of this section provides some common examples of how to connect to server-based resources. The Contoso sample application uses only a back-end resource running SQL Server.

To access a Web service, Web page, or WebDAV server using the current account and Windows-integrated authentication

1. Use the Credentials property on the HttpWebRequest class.
2. Set the Credentials property to the DefaultCredentials property of the CredentialCache class as shown in the following code sample.

Do this instead of using a new instance of a NetworkCredential class with a user name and password. This technique frees you from needing to hide and protect such sensitive information.

using System.Net;
public void GetHttpData () 
{
  HttpWebRequest myReq =
    (HttpWebRequest)WebRequest.Create("http://www.contoso.com/");
  //GOOD practice to use code that do not require secrets
  myReq.Credentials = CredentialCache.DefaultCredentials;
  /*
  //BAD practice to try to hide secrets
  myReq.Credentials = new NetworkCredential(
  SecurelyStoredUserName, SecurelyStoredPassword,SecurelyStoredDomain);
  */
}

To access a directory service such as Active Directory using Windows-integrated authentication

1. Use the Username, Password, and AuthenticationType properties on the DirectoryEntry class.

   You can also use the username, password, and authenticationType parameters in the constructor of the same class.

2. Set the username and password to null (Nothing in VB.NET) and the AuthenticationType to AuthenticationType.Secure as shown in the following code sample.

Do this rather than providing a user name and password credentials. This technique frees you from needing to hide and protect such sensitive information.

public void GetDirectoryData() 
{
  DirectoryEntry rootDSE = new DirectoryEntry("LDAP://rootDSE");
  DirectoryEntry root = new DirectoryEntry("LDAP://" + 
    (string)rootDSE.Properties["defaultNamingContext"].Value);
  DirectoryEntry myDirectoryEntry = 
     new DirectoryEntry(root.Path, null, null,AuthenticationTypes.Secure);
}

Note   When setting AuthenticationType to AuthenticationType.Secure it is also possible to have the data encrypted and signed or verified by setting AuthenticationType to AuthenticationType.Signed and AuthenticationType.Sealed.

Step 5: ACL-Based Access Control Can Occur

When using the Trusted Subsystem Model, the ASP.NET process account is used to access the SQL Server database. When using the Delegation Model, the client's Kerberos-based service ticket is forwarded by the Web server to the SQL Server.

For both models, the SQL Server configured for Windows-integrated authentication will perform an ACL-based access control check to verify that the user (service account or end user account) has access to the requested table, can view stored procedures, and so on. First, the service or user account must be granted the ability to log on to SQL Server.

Normally, a Windows group would be granted the logon permission and the user account would be added to the group. Then the logon must be mapped to a database user and specific permissions should be allocated to the user (a typical permission is Execute access on selected stored procedures).

In the provided sample code, the database is queried with a simple SELECT statement against the Employees table in the Northwind database. The user (service account or end user account) must be granted the ability to log on to SQL Server and have the SELECT permissions statement enabled in the Employees table. This information is detailed in Chapter 5, "Implementing the Solution."

ASP.NET Extranet Applications

The following sections define the architecture for the Contoso extranet application solution.

Solution Concept

The Contoso sample application for the extranet is again a simple ASP.NET Web application that runs on an application server running Windows Server 2003. The application uses a SQL Server database on another computer that also runs Windows Server 2003. In this scenario, the sample code passes identity across the tiers using the Trusted Subsystem Model.

Windows Authorization Manager provides role-based authorization, and ACLs protect resources. The ACLs are set for trusted service access.

Clients in the extranet scenario will use Microsoft Internet Explorer 6 on computers that are running either the Microsoft Windows 2000 Professional or Windows XP Professional operating system. For partners and customers who will access applications in the business-to-business (B2B) and business-to-consumer B2C scenarios, Contoso must support many of the commonly used Web browsers. Contoso has chosen to authenticate these users using the following technologies:

• Microsoft Passport. Primarily for customers in the B2C scenario.
• X.509 client certificates. Primarily for employees in the B2E scenario.
• Forms-based authentication with Secure Sockets Layer (SSL). Primarily for partners in the B2B scenario.

Solution Prerequisites

Before implementing the solution you must have the following infrastructure in place:

• Active Directory on a computer running Windows Server 2003 with the domain and forest functional level set to Windows Server 2003.
• A Web application server running Windows Server 2003 and .NET Framework 1.1 joined to the Active Directory domain.
• A database server running SQL Server 2000 and Windows Server 2003 joined to the Active Directory domain with the Northwind sample database installed.

Solution Architecture

The solution architecture for the extranet scenario is identical to the architecture for the intranet scenario; the only difference is in how client authentication is performed. Three different authentication mechanisms are supported:

• B2B using ASP.NET Forms-based authentication
• B2E using X.509 client certificates
• B2C using Microsoft Passport

These methods are described in detail in the client authentication section below.

How the Solution Works

This section provides an overview of how the Contoso sample application works. Chapter 5, "Implementing the Solution," provides step-by-step prescriptive implementation guidance for the sample application.

The following figure illustrates the authentication and authorization flow as it is implemented in the scenario.

Figure 4.4. Sample extranet ASP.NET application

Step 1: Users Authenticate to the System

The following applies to each of the Contoso scenarios.

General

In IIS, you can configure only one of the three authentication mechanisms used by Contoso in their extranet for a given virtual directory or file. In order to support the three authentication mechanisms in the B2B, B2E, and B2C scenarios, Contoso chose to configure three virtual directories — one for each authentication mechanism. To simplify the application administration, Contoso decided to install the actual application files in one physical directory, and then have all three virtual directories point to this one physical directory.

Typically, ASP.NET automatically constructs the User object based on the settings in the Web.config file. The problem with this approach is that there is only one Web.config file since there is only one physical directory. To make all three authentication mechanisms work, Contoso decided to omit authentication and authorization information from the application's Web.config file and instead configure authentication and authorization in the machine.config file using location directives.

The Contoso machine.config settings can be found in the Tools and Templates for this paper in the machine.config.txt file.

For more information about machine.config, see the "ASP.NET Configuration" article.

Step 1a: B2B Using ASP.NET Forms-based Authentication

When a Contoso partner accesses the Web site, ASP.NET redirects them to a logon page where the partner then types in a user name and a password. The partner's credentials are validated against Active Directory by establishing a Lightweight Directory Access Protocol (LDAP) connection. After the partner is authenticated, ASP.NET creates a session cookie with the partner's user principal name (UPN). Then, ASP.NET encrypts and signs the cookie using the Web server's machine key.

At each request, the browser sends the cookie and ASP.NET then decrypts and validates it. As long as the cookie is valid, the user will not be redirected to the logon page again.

In the Trusted Subsystem Model the identity is not being used for resource access, so impersonation should not be done.

In the Delegation Model, S4U logon and impersonation is required to transition the protocol from ASP.NET Forms-based authentication to Kerberos authentication, and then to access the back-end resource in the context of the user. S4U logon and impersonation is implemented in Application_AuthenticateRequest in global.asax.

Note   S4U is a new (with Windows Server 2003) overload of the LogonUser Win32 application programming interface (API). An S4U logon does not require a password. However, without special privileges, the returned Windows security token can only be used to enumerate the user's groups. If the caller has been granted the Act as part of the operating system permission, the returned token can also be used for constrained delegation.

The new overloaded version of the LogonUser Win32 API is also "wrapped" in version 1.1 of the .NET Framework in a new constructor of the WindowsIdentity class. In .NET Framework version 1.0 there are five overloads that all take an IntPtr parameter to a Windows token, and you must explicitly call LogonUser to get this token. In .NET Framework 1.1 there are seven overloads. The two new ones take the UPN as a string. A call to LogonUser is not required.

Forms-based authentication sends the user credentials from the browser to the Web server in plaintext. Therefore, Contoso decided that the logon page must run under SSL.

Note   By default, ASP.NET protects the cookie by encrypting and signing it, and then assigning it only a 30-minute lifetime. However, this does not protect the cookie from being stolen or overtaken. Contoso had the choice of running all application pages under SSL to protect the authentication cookie, but chose to protect the credentials by using SSL only on the logon page. Contoso decided that the performance issues involved in using SSL on all pages (Contoso does not have hardware to manage SSL) would be significant, and that protecting the cookie from being intercepted was not worth the expense of the additional hardware.

Step 1b: B2E Using X.509 Client Certificates

For more information about how X.509 certificate authentication works, see the "Extranet Access Management" paper in this series.

Step 1c: B2C Using Microsoft Passport

For more information about how Passport authentication works, see the "Extranet Access Management" paper in this series.

Step 2: Microsoft Passport Accounts and X.509 Certificates Are Mapped to Active Directory Users

After a user authenticates through X.509 or .NET Passport, IIS 6.0 maps the user's X.509 certificate or Passport identity to an Active Directory account, which IIS 6.0 impersonates for authorization purposes. See the "Extranet Access Management" paper in this series for more information about how this works. In the B2B scenario, IIS is configured to allow anonymous requests, and this mapping must take place using the forms authentication code as described earlier in this chapter.

Steps 3 – 5: Back-end Resources Are Accessed

When ASP.NET forms authentication is used with the Trusted Subsystem Model, Contoso chose to perform a S4U logon (wrapped by the WindowsIdentity constructor as described previously) for the client user without impersonating the client user. This approach allows Contoso to be consistent when initializing the client context for role-based access control (RBAC) using a Windows token. All other authentication mechanisms impersonate the client user, and the RBAC client context can be initialized very efficiently using the IIS-provided Windows token for the client user. The following code sample from the AzMan class shows how this initialization is done:

HandleRef token;
if(HttpContext.Current.User.Identity is FormsIdentity ) 
{
    WindowsIdentity formsUser = new
         WindowsIdentity(HttpContext.Current.User.Identity.Name);
    token = new HandleRef(this, formsUser.Token);
}
else
{
    token = new HandleRef(this,
         ((WindowsIdentity)HttpContext.Current.User.Identity).Token);
}
AzAuthorizationStoreClass store = new AzAuthorizationStoreClass();
store.Initialize(AZ_AZSTORE_FLAG_ACCESS_CHECK, AzPolicyURL, null);
IAzApplication app = store.OpenApplication(applicationName, null);
IAzClientContext clientContext = app.InitializeClientContextFromToken( 
    (UInt64)token.Handle, 0);

Except for the initialization of the RBAC client context for ASP.NET forms authentication in the Trusted Subsystem Model, steps 3-5 in the extranet sample application is identical to the intranet sample.

Chapter 5: Implementing the Solution

The previous chapters in this paper provided you with the information you need to understand the business, technical, and security requirements for the solution in this paper. The specifications for designing a solution that will address the two Contoso scenarios focused on configuring clients and servers for user access to applications in the company's intranet and extranet. This chapter provides prescriptive guidance on how to implement the solution for these scenarios. It also shows you how to implement the provided sample code that is included in the Tools and Templates folder that downloads with this paper.

Tools and Templates

The Identity and Access Management download package includes Identity and Access Management Tools and Templates.msi, which is the Tools and Templates installer file. The Tools and Templates that are part of this download include text-based scripts, code samples, and configuration files that are related to identity and access management, but do not include any executable programs or compiled code.

Note   These samples are provided as examples only. Be sure to review, customize, and test these tools and templates before you use them in a production environment.

When you run the installer file, the resulting folder structure (depending where you install it) will look similar to the one displayed in the following figure.

Figure 5.1. The Tools and Templates folder structure

This guide assumes you have installed the Tools and Templates into the default location of %UserProfile%\My Documents\Identity and Access Management Tools and Templates. If you use a different installation location, ensure that you use the same path in all the steps in this document.

Note   The Tools and Templates MSI package can sometimes produce an error during the installation process. See the Identity and Access Management Series Readme.htm file for more information.

The samples are available in both Microsoft® Visual C#® and Visual Basic® .NET in the CS and VB folders respectively under the Developing Identity-Aware ASP.NET Applications folder. The following tables list all the files in the CS and VB folders. The C# files are defined with "cs" in the file name, and the Visual Basic .NET files are defined with "vb" in the file name. The following tables use <lang> as a placeholder in the lists of file names.

Folders: CS and VB

There are two main folders in the Developing Identity-Aware ASP.NET Applications Tools and Templates folder structure: the CS folder for C# samples, and the VB folder for the Visual Basic .NET samples.

Table 5.1. Files in the CS and VB Folders

Subfolder: AppDevASPExtranet

This folder contains files for the extranet sample project. You must create a virtual directory pointing to this directory named AppDevASPExtranet in IIS before opening the AppDevASPExtranet solution file.

Table 5.2. Files in the AppDevASPExtranet Subfolder

Subfolder: Template

This folder contains reusable user control templates for the Contoso scenarios.

Table 5.3. Files in the AppDevASPExtranet/Template Subfolder

Subfolder: AppDevASPExtranetSetup

This folder contains the installer project for the extranet sample project.

Table 5.4. The File in the AppDevASPExtranetSetup Subfolder

Subfolder: AppDevASPIntranet

This folder contains the following files for the intranet sample project. You must create a virtual directory pointing to this directory named AppDevASPIntranet in IIS before opening the AppDevASPIntranet solution file.

Table 5.5. Files in the AppDevASPIntranet Subfolder

Subfolder: Template

This folder contains reusable user controls for intranet sample project.

Table 5.6. Files in the AppDevASPIntranet/Template Subfolder

Subfolder: AppDevASPIntranetSetup

This folder contains the installer project for the intranet sample project.

Table 5.7. Files in the AppDevASPIntranetSetup Subfolder

Subfolder: AppDevASPLib

This folder contains common files for the intranet and extranet sample applications.

Table 5.8. Files in the AppDevASPLib Subfolder

Note   Before implementing the intranet and extranet sample applications, it is a good idea to validate the solution prerequisites by using the tasks in the "Validating the Implementation Prerequisites" section in Chapter 6, "Testing the Solution."

ASP.NET Intranet Applications

The application for the intranet scenario provides a Delegation Model example and a Trusted Subsystem Model example to use when accessing server resources.

When using the Trusted Subsystem Model, the developers for this paper used Windows Authorization Manager for authorization and the IIS 6.0 worker process account to access back-end resources that have access control lists (ACL).

The application shows which model is currently being used and information about how to switch between the models. The application also shows key information, such as the identity of the user, the identity of the Win32 thread, and the identity of the .NET thread.

Note   The .NET Common Language Runtime (CLR) exposes managed .NET threads, which are distinct from Win32 threads. You use the WindowsIdentity.GetCurrent method to obtain the identity of the security context of the currently executing Win32 thread. You use Thread.CurrentPrincipal to return the principal object of the currently executing .NET thread. For Web applications this represents the authenticated user.

Implementation Prerequisites

Before implementing the solution you must have the following infrastructure in place:

• The Microsoft Active Directory® directory service on a computer running Microsoft Windows Server™ 2003 with the domain and forest functional level set to Windows Server 2003.
• A Web application server with Windows Server 2003 and Microsoft .NET Framework 1.1 joined to the Active Directory domain.
• A database server with Microsoft SQL Server™ 2000 and Windows Server 2003 joined to the Active Directory domain that also has the Northwind sample database installed on it.

The architecture for the following prescriptive guidance uses a server computer running Microsoft Internet Information Services (IIS) 6.0 to host and run both the sample ASP.NET page and the .NET components.

Most of the work in this scenario involves configuring IIS 6.0, Windows Server 2003, and SQL Server 2000 to use integrated security and the Kerberos version 5 authentication protocol. For Internet Explorer the default settings are used. After it has been properly set up, this scenario is much easier for the developer to implement than other authentication methods because the infrastructure does all the work behind the scenes.

Implementation Overview

The tasks for the ASP.NET intranet application implementation are required to prepare the platform, compile the samples, and install the application. The following tasks are detailed in the remainder of this chapter:

• Task 1: Create the required intranet Active Directory accounts.
• Task 2: Configure the ASP.NET application pool.
• Task 3: Configure SQL Server 2000 to use Windows-integrated authentication.
• Task 4: Configure constrained delegation.
• Task 5: Compile the sample .NET Framework components.
• Task 6: Install the sample application.
• Task 7: Configure the database connection information
• Task 8: Configure Windows Authorization Manager.

Complete the following tasks and procedures to prepare and install the intranet scenario.

Task 1: Create the Required Intranet Active Directory Accounts

In this task, you create a worker process account for IIS 6.0 and to test user accounts.

To create the IIS 6.0 worker process account

1. Log on to the domain controller as a domain administrator.
2. Click the Start menu, point to the Administrative Tools menu, and then click Active Directory Users and Computers.
3. Right-click the Users folder, point to New, and then click User.
4. In the First Name, Full Name and User logon name fields, type the account name as aspnetaccount and then click Next.
5. Enter and confirm the password for the service account. Clear the check box for User must change password at new logon, click Next and then Finish.

To create the test accounts

Repeat the process above to create two test users named Alice and Partner.

Perform the following steps to make the IIS 6.0 worker process account a member of the IIS_WPG group in order to run ASP.NET applications.

To add the worker process account to the IIS_WPG user group

1. Log on to the Web server as a local administrator.
2. Click the Start menu, right-click My Computer, and then click Manage.
3. Expand the Local Users and Groups node.
4. Click the Groups folder to display a list of all groups defined on the computer in the right pane.
5. Right-click IIS_WPG, and then click Add to group.
6. Click Add, and then type aspnetaccount to specify the account to use for the worker process.
7. Click OK twice to close the dialog box.

Complete the following steps so that the ASP.NET worker process account can perform an S4U logon user operation.

Note   Both the intranet and the extranet scenarios use aspnetaccount. This elevated privilege is not required for the intranet scenario or for the Trusted Subsystem Model in the extranet scenario. It is used only by the Forms-based authentication process in the extranet scenario, when this scenario is configured for the Delegation model. This scenario uses this elevated privilege in order to perform an S4U logon, and then perform impersonation and constrained delegation.

Granting the Web application process this elevated privilege introduces a significant reduction in security. This is because the privilege gives more power to any hacker who manages to take control of the Web application process. In a production environment, the extranet and intranet scenarios should have separate accounts in order to minimize the necessary privileges. The account used for the extranet should only be granted this elevated privilege if the extranet solution requires impersonation and delegation.

To assign the IIS 6.0 worker process account the "Act as a part of the operating system" permission

1. Log on to the Web server as a local administrator.
2. Click the Start menu, point to Administrative Tools, and then click Local Security Policy.
3. Expand the Local Policies node by clicking the PLUS SIGN (+).
4. Click the User Rights Assignments folder to display a list of all user rights defined on the computer in the right pane.
5. Right-click the Act as part of the operating system user right and then select Properties.
6. Click Add user or group, type (or use the search dialog box to select) the name of the newly created aspnetaccount, and then click OK twice to complete this procedure.

Figure 5.2. User rights security settings for the intranet ASP.NET application

Complete the following steps so that the user accounts can access the temporary ASP.NET files.

Note   These steps are only needed when the intranet or the extranet scenario is configured for the Delegation model. Granting users this elevated privilege introduces a reduction in security. The users should only be granted this permission if the solution requires using impersonation and delegation.

To grant the users access to the temporary ASP.NET files

1. Log on to the Web server as a local administrator.
2. Right-click the Start menu, and then click Explore.
3. Right-click the Temporary ASP.NET Files folder (typically located in C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files), and then click Properties.
4. On the Security tab, click Add and then in the resulting Select Users and Groups dialog box, type Domain Users and click OK.
5. Select the check boxes for Allow and Full Control, and then click OK.
6. Click Yes in the resulting warning prompt:

   You are about to change the permission settings of system folders, which can result in unexpected access problems and reduce security. Do you want to continue?

Task 2: Configure the ASP.NET Application Pool

Change the application identity of the default application pool to run as the newly created aspnetaccount account, which is now the trusted subsystem account for the sample application.

To set the application pool settings

1. Open the IIS 6.0 management console and expand the Local Computer node.
2. Expand the Application Pools node by clicking the PLUS SIGN (+).
3. Right-click the default application pool, and then click Properties to display the Properties dialog box for the application pool.
4. Click the Identity tab, and select the Configurable option as shown in the following figure.
5. In the Username field, type the <domain>\aspnetaccount or click Browse to select aspnetaccount.
6. In the Password field, type the account password and click OK twice to confirm and save the password.

Figure 5.3. The Identity tab of the application pool properties dialog box

Task 3: Configure SQL Server 2000 to Use Windows-Integrated Authentication

You can configure SQL Server 2000 to use Windows-integrated authentication or a combination of Windows-integrated authentication and SQL Server 2000 authentication. These options are shown in the following figure. Either way, Windows-integrated authentication is always enabled.

Figure 5.4. The Security tab in the properties dialogue box for SQL Server 2000

You must grant access for the test users in the Delegation Model as well as the trusted account in the Trusted Subsystem Model for access to the Employees table.

To grant access to the Employees table

1. Log on to the computer running SQL Server 2000 as a local administrator.
2. Click Start, point to Programs, point to Microsoft SQL Server, and then click Enterprise Manager.
3. Expand the appropriate SQL Server node by clicking the PLUS SIGN (+).
4. Expand the Security node.
5. Right-click the Logins node and select New login.
6. In the name box, type <domain>\alice and select Northwind as the default database, and then click the Database access tab.
7. Select Northwind from the list of databases, select the db_datareader role from the Database Roles for 'Northwind' and then click OK.

Refer to the following figures to confirm these steps, and then repeat this procedure for the aspnetaccount and Partner accounts.

Figure 5.5. The New Login dialog box in SQL Server 2000

Figure 5.6. Specifying the Northwind database in the New Login dialog box in SQL Server 2000

Task 4: Configure Constrained Delegation

In order to configure delegation for an account, the account must have a Service Principal Name (SPN). Complete the following steps to set the SPN, configure constrained delegation, and allow access between the Web server and the SQL Server. Refer to the following two figures to confirm these steps.

To set the SPN for aspnetaccount

1. Log on to the intranet domain controller as a domain administrator.
2. Click the Start menu, and click Run.
3. Type cmd and click OK.
4. At the command prompt type:

   setspn –A HTTP/<internal DNS Web server name> aspnetaccount,

   and then press the ENTER key.

To configure constrained delegation

1. Log on to the intranet domain controller as a domain administrator.
2. Click the Start menu, point to Administrative Tools, and then click Active Directory Users and Computers.
3. Click the Users folder to display a list of all users in the domain in the right pane.
4. Right-click the aspnetaccount and select Properties.
5. Click the Delegation tab, select the option for Trust this user for delegation to specified services only, select the option for Use any authentication protocol, and then click Add.

   Note   For the intranet solution the client is authenticated using the Kerberos protocol, which makes using the Use Kerberos Only option a possibility. However, for the extranet solution in which three different authentication protocols are used, you must select the Use any authentication protocol option. Because the same authentication settings for used in both intranet and extranet solutions, you must use the Use any authentication protocol option. In a production environment, the Use Kerberos Only option should be used whenever possible.

6. Click Users or computers, type in the name or browse to and select the SQL Server computer, and then click OK.
7. Select MSSQLSvc from the list of service types, and then click OK twice to complete this procedure.

Refer to the following two figures to confirm these steps.

Figure 5.7. The Delegation tab of the Properties dialogue box in Windows Server 2003

Figure 5.8. The Add Services properties dialogue box in SQL Server 2000

Task 5: Compile the Sample .NET Framework Components

The Tools and Templates folder that downloads with this paper is available in both C# (in a folder named CS) and Visual Basic.NET (in a folder named VB). Each of these folders contains two Microsoft Visual Studio® solution files (.sln files) and five subdirectories containing the two sample projects, corresponding installer projects, and a shared directory.

To compile the intranet sample application

1. In Windows Explorer, right-click the AppDevASPIntranet folder and then click Sharing and Security.
2. Click the Web Sharing tab and select Share this folder.
3. Leave the default values unchanged, and then click OK twice.
4. Double-click the AppDevASPIntranet.sln file to open the solution in Visual Studio.
5. On the Build menu, select Configuration Manager.
6. Select all three projects for build, and then click Close.
7. When the sample is copied to a new computer, the reference to Microsoft.Interop.Security.AzRoles is broken. To fix the reference, repeat the following steps a through d for both the AppDevASPIntranet and AppDevASPLib projects:
   1. Right-click the reference to Microsoft.Interop.Security.AzRoles in the References node of the Solution Explorer, and then click Remove.
   2. Right-click the References node of the Solution Explorer and click Add Reference.
   3. Click Browse and navigate to the Microsoft.Interop.Security.AzRoles.dll (typically located in C:\Windows\Microsoft.NET\AuthMan) and click Open.
   4. Click OK to close the Add Reference dialog box.
8. Because both the Windows Authorization Manager-managed wrapper (Microsoft.Interop.Security.AzRoles.dll) and the underlying COM object (azroles.dll) are protected operating system files, you should not include them in a setup application. To exclude these files from the MSI package:
   1. Right-click the azroles.dll file in the expanded Detected Dependencies node in the Setup project.
   2. Click Exclude.
   3. Repeat the process for the Microsoft.Interop.Security.AzRoles.dll file.
9. On the Build menu, select Build Solution.

Refer to the following three figures to confirm the procedures in Task 5.

Figure 5.9. The caution icon defining a broken reference to the Microsoft.Interop.Security.AzRoles.dll

Figure 5.10. Adding a reference to the Microsoft.Interop.Security.AzRoles.dll

Figure 5.11. Excluding protected files from redistribution

Task 6: Install the Sample Application

After the sample application is compiled and the Microsoft Installer MSI file has been generated, you need to install the MSI file on the Web server. When the installer for the sample applications runs, virtual directories are created and a sample Windows Authorization Manager policy is installed in an XML file.

Note   If the computer where the sample application was compiled is the same computer as the Web server, you need to disable Web sharing for the AppDevASPIntranet folder before running the MSI file.

Perform the following procedures to complete this task.

To disable the Web sharing option

1. In Windows Explorer, right-click the AppDevASPIntranet folder and select Sharing and Security.
2. Click the Web Sharing tab and select the Do not share this folder option, and then click Yes in the confirmation prompt.
3. Click OK to close the dialog box.

To install the sample application

1. In Windows Explorer, double-click the AppDevASPIntranetSetup.msi installer you built in a previous task. The installer is located in the Debug subdirectory of the AppDevASPIntranetSetup project folder.
2. Click through the wizard for the installer, leaving the default values in place.

Task 7: Configure the Database Connection Information

Edit the server name in the SQL Server 2000 connection string (underscored in the following code sample) in the Web.config file for the intranet sample application. The location of the Web.config file is: <systemdrive:>\inetpub\wwwroot\AppDevASPIntranet.

<configuration>
  <appSettings>
    <add key="SQLConnectionString" value="Persist Security Info=False;
Integrated Security=SSPI;database=northwind;
server=<full SQL Server DNS name>;Connect Timeout=30" />
  </appSettings>
…
</configuration>

Task 8: Configure Windows Authorization Manager

The application authenticates to Windows Authorization Manager using an account named aspnetaccount. This account must have permissions to access the location where the Windows Authorization Manager policy is stored. If the policy is stored in an XML file, the account needs NTFS permissions.

The sample intranet application uses an XML file (C:\AppDevASPIntranet.xml). If the policy is stored in Active Directory, the account needs access to the appropriate locations in Active Directory.

To simplify the management of these permissions, Windows Authorization Manager uses two roles (reader and administrator). When selecting roles from the Windows Authorization Manager management console, access permissions are managed automatically on the store that holds the policy.

At runtime, the access checks are performed and test users Alice and Partner accounts need to be added to the Users application role in order to be able to access the ReadEmployeeData task.

To grant aspnetaccount Windows Authorization Manager permissions

1. Click the Start menu, click Run, and then at the command prompt, type azman.msc and click OK.
2. Right-click the Authorization Manager node and select Open Authorization Store.
3. Make sure XML file is selected, type C:\AppDevASPIntranet.xml in the field and then click OK.
4. Right-click the new AppDevASPIntranet.xml node and select Properties.
5. On the Security tab, make sure the Authorization Manager user role is set to Reader as shown in the following figure.
6. Click Add and then in the resulting Select Users and Groups dialog box, type aspnetaccount and click OK twice.

Figure 5.12. Assigning Authorization Manager permissions to the service account

To add Alice and Partner accounts to the Users role

1. Make sure the AppDevASPIntranet application is open as described in the previous step.
2. Select the Role Assignments node of the application scope named All in the AppDevASPIntranet application.
3. Right-click the Users role and select Assign Windows Users and Groups.
4. In the resulting Select Users and Groups dialog box, type Alice and click OK.

Repeat steps 2-4 for the Partner account.

Launching the Sample Intranet ASP.NET Application

To run the sample intranet ASP.NET application, open Internet Explorer and type http://<Web Server host name or IP address>/AppDevASPIntranet in the browser's address box.

Note   Chapter 6, "Testing the Solution" in this paper provides information about testing and troubleshooting the sample application.

ASP.NET Extranet Applications

The sample ASP.NET application for the extranet scenario is included in the Tools and Templates folder that downloads with this paper.

The sample application demonstrates three different authentication mechanisms between the browser and Web server. Contoso employees authenticate using X.509, Contoso business partners authenticate using ASP.NET Forms-based authentication with a combination of user name and password, and Contoso customers authenticate using Microsoft Passport.

This application provides a Delegation Model example and a Trusted Subsystem Model example to use when accessing server resources. With the Trusted Subsystem Model, the developers for this paper used Windows Authorization Manager for authorization and the IIS 6.0 worker process account to access back-end resources that have ACLs.

The application shows which model is currently being used and information about how to switch between the models. The application also shows key information such as the identity of the user, the identity of the Win32 thread, and the identity of the .NET thread.

Implementation Prerequisites

Before implementing the solution you must have the following infrastructure in place:

• Active Directory on a computer running Windows Server 2003 with the domain and forest functional level set to Windows 2003.
• A Web application server with Windows Server 2003 and .NET Framework 1.1 joined to the Active Directory domain.
• A database server with SQL Server 2000 and Windows Server 2003 joined to the Active Directory domain with the Northwind sample database installed on it.

The architecture for the following prescriptive guidance uses the server running IIS 6.0 to host and run both the sample ASP.NET page and the .NET components. For your implementation these can be different systems if you choose.

Most of the work in this scenario involves implementing Forms-based authentication.

Implementation Overview

The tasks for the ASP.NET extranet application are required to prepare the platform, compile the samples, and install the application. The following tasks are detailed in the remainder of this chapter. Some of the task listed in this overview are documented in the "ASP.NET Intranet Applications" section.

• Task 1: Create the required intranet Active Directory accounts.
• Task 2: Configure the ASP.NET application pool.
• Task 3: Configure SQL Server 2000 to use Windows-integrated authentication.
• Task 4: Configure constrained delegation.
• Task 5: Compile the sample .NET components.
• Task 6: Install the sample application.
• Task 7: Configure the database connection information.
• Task 8: Edit the LDAP binding information.
• Task 9: Configure Windows Authorization Manager.
• Task 10: Configure SSL and install a server certificate.
• Task 11: Add a virtual directory for B2E X.509 client certificate authentication.
• Task 12: Add a virtual directory for B2C Microsoft Passport authentication.
• Task 13: Configure authentication and authorization in the machine.config file.

The following tasks and procedures prepare and install the extranet scenario.

Tasks 1 – 4: Previously Documented

Preparation tasks 1 through 4 for this section are documented in the "ASP.NET Intranet Applications" section of this chapter. Complete the following tasks after first completing these preparation tasks.

Task 5: Compile the Sample .NET Components

The Tools and Templates folder that downloads with this paper is available both in C# (in a folder named CS) and Visual Basic.NET (in a folder named VB). Each of these folders contains two Visual Studio solution files (.sln files) and five subdirectories with the two sample projects, corresponding installer projects, and a shared directory.

Note   Many of the preparation activities that are needed for the extranet scenario are also needed for the intranet scenario. Therefore, it is highly recommended to validate the intranet solution before proceeding with this extranet solution. Validation tests are described in the "Validating the Intranet Application Scenario" section of Chapter 6, "Testing the Solution."

To compile the sample .NET components

1. In Windows Explorer, right-click the AppDevASPExtranet folder and select Sharing and Security.
2. Click the Web Sharing tab and select Share this folder.
3. Leave the default values, click OK, and then click OK again.
4. Double-click the AppDevASPExtranet.sln file to open the solution in Visual Studio.
5. On the Build menu, select Configuration Manager.
6. Select all three projects for build, and then click Close.
7. When the sample application is copied on to a new computer, the reference to Microsoft.Interop.Security.AzRoles is broken. To fix the reference:
   1. Right-click the reference to Microsoft.Interop.Security.AzRoles in the References node of the Solution Explorer and click Remove.
   2. Right-click the References node of the Solution Explorer and select Add Reference.
   3. Click Browse, and navigate to the Microsoft.Interop.Security.AzRoles.dll file (typically located in C:\Windows\Microsoft.NET\AuthMan), and click Open.
   4. Click OK to close the Add Reference dialog box.
8. Because both the Windows Authorization Manager-managed wrapper (Microsoft.Interop.Security.AzRoles.dll) and the underlying COM object (azroles.dll) are protected operating system files, you should not include them in a setup application. To exclude these files from the MSI package:
   1. Right-click the azroles.dll file in the Detected Dependencies node in the setup project.
   2. Click Exclude.
   3. Repeat this process for the Microsoft.Interop.Security.AzRoles.dll file.
9. On the Build menu, select Build Solution.

Task 6: Install the Sample Application

After the sample is compiled and the MSI file has been generated, you must install the MSI file on the Web server. When the installer for the sample applications runs, virtual directories are created and a sample Windows Authorization Manager policy is installed in an XML file.

Note   If the computer where the sample application was compiled is the same computer as the Web server, you need to disable Web sharing for the AppDevASPExtranet folder before running the MSI file.

Perform the following procedures to complete this task.

To disable the Web sharing option

1. In Windows Explorer, right-click the AppDevASPExtranet folder and select Sharing and Security.
2. Click the Web Sharing tab and select the Do not share this folder option, and click Yes in the confirmation dialog box.
3. Click OK to close the dialog box.

To install the sample application

1. In Windows Explorer, double-click the AppDevASPExtranetSetup.msi installer you built in a previous task. The installer is located in the Debug subdirectory of the AppDevASPExtranetSetup project folder.
2. Click through the wizard for the installer, leaving the default values in place.

Task 7: Configure the Database Connection Information

Edit the server name in the SQL Server 2000 connection string (underscored in the following code sample) in the Web.config file for the extranet sample application. The location of the file is <systemdrive:>\inetpub\wwwroot\AppDevASPExtranet.

<configuration>
  <appSettings>
  <add key="SQLConnectionString" value="Persist Security Info=False;
Integrated Security=SSPI;database=northwind;
server=<full SQL Server DNS name>;Connect Timeout=30" />
  </appSettings>
…
</configuration>

Task 8: Edit the LDAP Binding Information

Edit the LDAP binding information in the Web.config file for the extranet sample application. The location of the file is: <systemdrive:>\inetpub\wwwroot\AppDevASPExtranet.

<configuration>
  <appSettings>
…
    <add key="LDAPBindingString" value="LDAP://DC=na,DC=corp,DC=contoso,DC=com" />
…
  </appSettings>
…
</configuration>

Task 9: Configure Windows Authorization Manager

The application authenticates to Windows Authorization Manager using an account named aspnetaccount. This account must have permissions to access the location where the Windows Authorization Manager policy is stored. If the policy is stored in an XML file, the account needs NTFS permissions.

The sample extranet application uses an XML file (C:\AppDevASPExtranet.xml). If the policy is stored in Active Directory, the account needs access to the appropriate locations in Active Directory. To simplify the management of these permissions, Windows Authorization Manager uses to roles (reader and administrator). When selecting roles from the Windows Authorization Manager management console, access permissions are managed automatically on the store that holds the policy.

At runtime, the access checks are performed and test users Alice and Partner accounts need to be added to the Users application role in order to be able to access the ReadEmployeeData task.

To grant aspnetaccount Windows Authorization Manager permissions

1. Click Start, Run, and then at the command prompt, type azman.msc and click OK.
2. Right-click the Authorization Manager node and select Open Authorization Store.
3. Make sure XML file is selected, then type C:\AppDevASPExtranet.xml and click OK.
4. Right-click the new AppDevASPExtranet.xml node and select Properties.
5. On the Security tab, make sure the Windows Authorization Manager user role is set to Reader.
6. Click Add and then in the resulting Select Users and Groups dialog box, type aspnetaccount and click OK twice.

To add Alice and Partner accounts to the Users role

1. Make sure the AppDevASPExtranet application is open as described in the previous step.
2. Select the Role Assignments node of the application scope named All in the AppDevASPExtranet application
3. Right-click the Users role and select Assign Windows Users and Groups.
4. In the resulting Select Users and Groups dialog box, type Alice and click OK.

Repeat steps 2-4 for the Partner account.

Task 10: Configure SSL and Install a Server Certificate

The AppDevASPExtranet virtual directory uses ASP.NET Forms-based authentication. SSL is used to authenticate the server to the client and encrypt information such as user names and passwords.

Configure the AppDevASPExtranet virtual directory on the extranet server running IIS according to the information in the following Microsoft Knowledge Base articles:

• "Installing a New Certificate with Certificate Wizard for Use in SSL/TLS".
• "How To Set Up an HTTPS Service in IIS".

When you configure SSL as described in the Knowledge Base articles, make sure that in the Secure Communications dialog box, under Client certificates, the option for Ignore client certificates is selected, and that the check box for Enable client certificate mapping is not selected.

Figure 5.13. Enabling SSL for server authentication and encryption

Task 11: Add a Virtual Directory for B2E X.509 Client Certificate Authentication

To enable Contoso employees to authenticate using X.509 client certificates, a new virtual directory is created that is configured for X.509 client certificate authentication. You need to configure the virtual directory to point to the same physical directory as in the B2B scenario in order to only install the actual application once.

To add a virtual directory for X.509 client certificate authentication

1. Log on to the Web server as a local administrator.
2. At the command prompt, type inetmgr.msc and press ENTER to open the Internet Information Services management console.
3. Navigate to the Default Web Site node under Web Sites.
4. Right-click the Default Web Site node, select New and click Virtual Directory.
5. In the Virtual Directory Creation Wizard, click Next.
6. In the alias field, type AppDevASPExtranetB2E and click Next.
7. In the path field, type the same physical path as the one used for the AppDevASPExtranet virtual directory and click Next.
8. Click Next and then Finish to close the wizard.
9. Configure the virtual directory according to the information in the Microsoft Knowledge Base articles referenced in the previous task. When configuring SSL as described in the referenced articles, make sure that the options for Require client certificates and Enable client certificate mapping are selected.

Figure 5.14. Pointing the B2E virtual directory to the application installed in the AppDevASPExtranet AppDevASPExtranet folder

Figure 5.15. Enabling SSL for both client and server authentication as well as encryption

Task 12: Add a Virtual Directory for B2C Microsoft Passport Authentication

To enable Contoso customers to authenticate using Microsoft Passport, a new virtual directory is created and configured for Microsoft Passport authentication. Name the virtual directory AppDevASPExtranetB2C and configure it to point to the same physical directory as in the B2B and B2E scenarios in order to only install the actual application once.

For the complete details on configuring Microsoft Passport for the B2C scenario, see the "Extranet Access Management" paper in this series.

Task 13: Configure Authentication and Authorization in the machine.config File

To enable Contoso to support three authentication mechanisms and only maintain one physical copy of the application server, you must configure the authentication and authorization requirements in the machine.config file using three location directives.

To configure authentication and authorization

1. Log on to the Web server as a local administrator.
2. At a command prompt, type notepad and press ENTER.
3. From the file menu, select Open, navigate to the machine.config file (typically in C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG) and click Open.
4. Copy and paste the XML text from the machine.config.txt file in the included Tools and Templates to somewhere between the <configuration> element and the </configuration> element of your machine.config file.
5. From the File menu, click Save and close Notepad.

Launching the Sample Extranet ASP.NET Application

To run the sample extranet ASP.NET application, access the following URLs using Internet Explorer:

• Test the B2B scenario using ASP.NET Forms-based authentication by typing https://<Web Server host name or IP address>/AppDevASPExtranet in the browser's address box.
• Test the B2E scenario using X.509 client certificates by typing https://<Web Server host name or IP address>/AppDevASPExtranetB2E in the browser's address box.
• Test the B2C scenario using Microsoft Passport by typing https://<Web Server host name or IP address>/AppDevASPExtranetB2C in the browser's address box.

Note   The application should be accessed over SSL (https). Attempting to access the site without using this protocol should result in the following error: HTTP 403.4 - Forbidden: SSL required. Chapter 6, "Testing the Solution" in this paper provides information about testing and troubleshooting the sample extranet ASP.NET application.

Chapter 6: Testing the Solution

This chapter describes how to validate the implemented solution scenarios from the previous chapter. It also provides some troubleshooting steps to help with common implementation challenges. Comprehensive guidance for testing the end-to-end user and administrator experience is not provided.

There are a number of steps required to test the platform for the solution scenarios in this paper, starting with the process of validating the prerequisites to ensure that the underlying platform is correctly installed and configured. Use these tests in your environment before implementing the sample applications.

Tests to validate the implementation are then carried out to ensure that the key features of the identity-aware Microsoft ASP.NET sample applications work correctly for both of the intranet and the extranet scenarios. In addition, some troubleshooting procedures are included to help you debug issues that might appear during testing. Before starting the validation procedures for the scenarios, ensure that you have completed the setup guidance in Chapter 5, "Implementing the Solution," in your environment.

Caution   Failure to test the implementation guidance in Chapter 5, "Implementing the Solution," according to the tests and procedures in this chapter may cause these solutions to not work in your environment.

Validating the Implementation Prerequisites

Before you test the implementation guidance in this paper, there are a few basic verification tests that you should perform to ensure that you have correctly configured the required infrastructure. These basic tests are designed to provide you with a means to quickly check that your network setup is ready to undergo the implementation testing.

Tests to validate the prerequisites include:

• Basic Test 1: Verify your domain controller functionality.
• Basic Test 2: Verify your Web server functionality.
• Basic Test 3: Verify your SQL Server 2000 functionality.
• Basic Test 4: Verify your network connectivity.

Basic Test 1: Verify Your Domain Controller Functionality

Complete the following procedures to verify that the domain controller is working properly and not generating any errors.

To verify that your domain controller is working properly

1. Log on to the domain controller with administrative privileges.
2. At a command prompt, type dcdiag.exe and press ENTER.

The dcdiag utility executes a series of tests. All tests should pass.

To check the domain controller's event log errors

1. Log on to the domain controller with administrative privileges.
2. At the command prompt, type eventvwr.msc and press ENTER to open the Event Viewer management console.
3. Select the Directory Service node.

There should not be any errors in the Directory Service Event log file.

Basic Test 2: Verify Your Web Server Functionality

Complete the following steps to ensure the Web server is working properly.

To verify IIS 6.0 is running on the Web server

1. Log on to the Web server with administrative privileges.
2. At a command prompt, type inetmgr.msc and press ENTER to open the Internet Information Services (IIS) 6.0 management console.
3. Navigate to the Default Web Site node under Web Sites.
4. Right-click the Default Web Site node and click Browse.

The Welcome page for IIS 6.0 should appear in the right pane.

Note   If the Web server is set to a different page, ensure that the page is visible. Alternatively, you can verify this by typing http://localhost in the browser's address box.

Basic Test 3: Verify Your SQL Server Functionality

Complete the following steps to ensure SQL Server 2000 is working properly.

To verify SQL Server is running and the Northwind Employee table is populated

1. Log on with administrative privileges to the computer running SQL Server 2000.
2. At the command prompt, type SQL Server Enterprise Manager.msc and press ENTER to open the SQL Server Enterprise Manager management console.
3. Double-click the (local) (Windows NT) node.
4. Expand the node for Databases, and then Northwind.
5. Click Tables and then in the right pane, right-click Employees, select Open table, and then click Return all rows.

The local server node will expand to confirm that SQL Server 2000 is running. After selecting Open table and Return all rows, nine records in the table will appear to confirm that the Northwind Employee table is populated.

Basic Test 4: Verify Your Network Connectivity

Complete the following procedures to ensure that the network setup is properly working.

To verify that domain users can log on to client workstations

• Log on to a client workstation with the credentials of a domain user.

A domain user should be able to log on to the client workstation and a local profile should be created for that user.

To verify connectivity between the Web server and the database server

1. Log on to the Web server.
2. At the command prompt type ping <Database server host name or IP address> and press ENTER.

The ping test should generate a successful response from the database server.

To verify connectivity between the client workstation and the Web server

1. Log on to a client workstation as a domain user.
2. At the command prompt, type ping <Web server host name or IP address> and press ENTER.

The ping test should generate a successful response from the Web server.

ASP.NET Intranet Applications

After the identity-aware ASP.NET intranet application scenario implementation is complete, you are ready to validate the implementation to ensure that the application meets the Contoso requirements.

Validating the Intranet Application Scenario

Complete the following procedures to verify that the intranet application is correctly implemented.

To verify Windows-integrated authentication

1. Log on to the client workstation with the credentials of a domain user.
2. Open Internet Explorer and browse to the Web server by typing http://<Web server host name or IP address> in the browser's address box.

The Web server's default page should load and then appear in the browser.

To verify the Trusted Subsystem Model

1. Log on to the Web server with administrative privileges.
2. Edit the Web.config file (its default location is C:\inetpub\wwwroot\AppDevASPIntranet) and set the impersonate attribute of the identity element to false and save the file.
3. Log on with administrative privileges to the computer running SQL Server 2000.
4. At a command prompt, type SQL Server Enterprise Manager.msc and press ENTER to open the SQL Server Enterprise Manager management console.
5. Double-click the (local) (Windows NT) node.
6. Navigate to the Security node and then the Logins node.
7. Ensure that only the account used to run your ASP.NET Web application (aspnetaccount) has permission for the Northwind database.
8. Log on to the client computer with the credentials of a domain user.
9. Open Internet Explorer and type http://<Web Server host name or IP address>/AppDevASPIntranet in the browser's address box.

The Northwind Employee table data should display.

Note   This test ensures that the records are retrieved using the Trusted Subsystem Model with the credentials of the account under which the ASP.NET worker process is running.

To verify the Delegation Model

1. Log on to the Web server with administrative privileges.
2. Edit the Web.config file (its default location is C:\inetpub\wwwroot\AppDevASPIntranet).

   To edit the Web.config file:

• Set the impersonate attribute of the identity element to true and save this change to the file.

1. Log on with administrative privileges to the computer running SQL Server.
2. At the command prompt, type SQL Server Enterprise Manager.msc and press ENTER to open the SQL Server Enterprise Manager management console.
3. Double click the (local) (Windows NT) node.
4. Navigate to the Security node and then to the Logins node.
5. Ensure that only the domain user (for example, alice) has permissions on the Northwind database.
6. Log on to a client computer with the credentials of the domain user (alice).
7. Open Internet Explorer and type http://<Web Server host name or IP address>/AppDevASPIntranet in the browser's address box.

The Northwind Employee table data should display.

Note   This test ensures that the records are retrieved using the Delegation Model with the credentials of the logged on user.

Troubleshooting the Intranet Application Scenario

This section provides information about some common errors that you may encounter while testing this scenario and how to most likely resolve them. The information in the following table is not an exhaustive list of errors and troubleshooting procedures.

Table 6.1. Troubleshooting Information for the Intranet Application Scenario

ASP.NET Extranet Applications

After the identity-aware extranet application scenario implementation is complete, you are ready to validate the implementation to ensure that the application meets the Contoso requirements.

Validating the Extranet Application Scenario

Complete the following procedures to verify the implementation of the extranet application.

To verify that Forms-based authentication works

1. Log on to a client workstation.
2. Open Internet Explorer and type http://<Web Server host name or IP address>/AppDevASPExtranet in the browser's address box.
3. When the logon form is displayed, type the credentials of a partner account.

After entering the correct credentials of a partner account, the extranet application should display records from Northwind Employee table.

To verify that the plaintext password is not exchanged in LDAP authentication

1. Log on to the Web server.
2. Open Network Monitor from Administrative tools. If asked for a network, choose the relevant network.
3. Start a capture by pressing F10.
4. Log on to a client workstation.
5. Open Internet Explorer and type http://<Web Server host name or IP address>/AppDevASPExtranet in the browser's address box.
6. When the logon form displays, type the credentials of a partner account into the form.
7. After successfully logging on to the Extranet application, log on to the Web server.
8. Stop and view the Network Monitor capture by pressing SHIFT+F11.

Verify the Lightweight Directory Access Protocol (LDAP) packets to see that they do not contain the plaintext password that you entered in the extranet application Forms logon page.

To verify that the Trusted Subsystem Model works

1. Log on to the Web server with administrative privileges.
2. Edit the Web.config file (its default location is C:\inetpub\wwwroot\AppDevASPExtranet).

   To edit the Web.config file:

   1. Set the impersonate attribute of the identity element to false.
   2. Set the value attribute of the UseImpersonationModel custom application setting to false.
   3. Save these changes in the file.
3. Log on with administrative privileges to the computer running SQL Server 2000.
4. At the command prompt, type SQL Server Enterprise Manager.msc and press ENTER to open the SQL Server Enterprise Manager management console.
5. Double-click the (local) (Windows NT) node.
6. Navigate to the Security node and then to the Logins node.
7. Ensure that only the account used to run your ASP.NET Web application (aspnetaccount) has permissions on the Northwind database.
8. Log on to a client computer with the credentials of a domain user.
9. Open Internet Explorer and type http://<Web Server host name or IP address>/AppDevASPExtranet in the browser's address box.

The Northwind Employee table data should display.

Note   This test ensures that the records are retrieved using the Trusted Subsystem Model with the credentials of the account under which the ASP.NET worker process is running.

To verify that the Delegation Model works

1. Log on to the Web server with administrative privileges.
2. Edit the Web.config file (its default location is C:\inetpub\wwwroot\AppDevASPExtranet).

   To edit the Web.config file:

   1. Set the impersonate attribute of the identity element to false.
   2. Set the value attribute of the UseImpersonationModel custom application setting to true.
   3. Save these changes in the file..
3. Log on with administrative privileges to the computer running SQL Server 2000.
4. At the command prompt, type SQL Server Enterprise Manager.msc and press ENTER to open the SQL Server Enterprise Manager management console.
5. Double-click the (local) (Windows NT) node.
6. Navigate to the Security node and then to the Logins node.
7. Ensure that only the domain user (for example, alice) has permissions on the Northwind database.
8. Log on to a client computer with the credentials of the domain user (alice).
9. Open Internet Explorer and type http://<Web Server host name or IP address>/AppDevASPExtranet in the browser's address box.

The Northwind Employee table data should display.

Note   This test ensures that the records are retrieved using the Delegation Model with the credentials of the logged on user.

Troubleshooting the Extranet Application Scenario

This section provides information about some common errors that you may encounter while testing this scenario and how to most likely resolve them. The information in the following table is not an exhaustive list of errors and troubleshooting procedures.

Table 6.2. Troubleshooting Information for the Extranet Application Scenario

Authentication Configuration Summary

Occasionally, you may encounter difficulties in your testing due to improper configuration of a specific authentication mechanism and model that you have chosen to use for identity flow. The following table summarizes the configuration details for each combination of intranet or extranet sample application, authentication mechanism, and identity-flow model chosen.

There are four columns in the following table:

• Authentication. This column contains information that describes the specific authentication mechanism chosen.
• Authentication mode. This column contains information that specifies the authentication mode setting required in either the machine.config file or the Web.config file.
• Impersonation attribute. This column contains information that specifies the impersonate attribute of the identity element required in the Web.config file.
• Custom appSetting UseImpersonationModel. This column contains information that specifies the UseImpersonationModel key in the appSetting section of the Web.config file. The application reads this key in the extranet Forms-based authentication scenario to implement custom impersonation.

Table 6.3. Authentication Configuration Summary

Stress and Unit Testing

The following sections provide information about identity-related topics in conjunction with stress and unit testing.

The Trusted Subsystem Model

In a Trusted Subsystem Model for server-based resource access, the following general characteristics apply:

• The database server is accessed using a trusted system account, so connection pooling is effective.
• Resources will be accessed using only the trusted service account. Access Control Lists (ACL) need to be configured accordingly.
• For unit testing, you can run the test harness as the trusted system account.
• The Trusted Subsystem Model is typically used in conjunction with Windows Authorization Manager, which is accessed in the context of the trusted service account.

The Delegation Model

In a Delegation Model for server-based resource access, the following general characteristics apply:

• The server is accessed using the client account, so connection pooling is ineffective.
• Resources are accessed using only the client accounts, and ACLs are configured accordingly.
• The impersonation process attaches a token to the operating system thread. For unit testing, you must do the same thing in the test harness or run the test harness using a different client account in different roles. For a stress/load test where you send an HTTP request to IIS 6.0, you can send the credentials with the request. If properly configured, IIS 6.0 will perform the impersonation for you.

Unit Testing

When using the Trusted Subsystem Model, perform unit testing with the account that will be used to run the IIS 6.0 application pool.

To perform a unit test with impersonation, you will need to impersonate each user for each test. For example, you can impersonate UserA and run all tests, then impersonate UserB and rerun all tests, and so on.

NUnit is a great tool for unit testing, but it does not include impersonation features. Two workarounds for this limitation are:

• Run NUnit several times under different accounts. The advantage of this approach is that no coding is required, but you must type a password for each test you run (there is no password parameter for the runas command), which makes it difficult to automate. You can execute test runs with commands like the following examples:
• runas /noprofile /user:myDomain\userA nunit-console.exe <nunitparams>
• runas /noprofile /user:myDomain\userB nunit-console.exe <nunitparams>
• Include impersonation code in the test scripts. One advantage of this approach is that it is possible to build an XML file containing information about test users and then design specific test cases for each type of user.

Stress and Load Tests

Application Center Test (ACT), which is included with Visual Studio.NET, is designed to stress test Web servers and analyze performance and scalability problems with Web applications, including ASP and ASP.NET, as well as the components they use. ACT simulates a large group of users by opening multiple connections to the server and rapidly sending HTTP requests.

When using the Delegation Model, it is possible to make ACT simulate users on the client side and make IIS 6.0 and ASP.NET impersonate the users on the server side. ACT can simulate different users and authenticate them using Basic Authentication, NTLM, Digest, and the Kerberos authentication protocol. When using Microsoft Passport and ASP.NET Forms-based authentication, it is not possible to use ACT user simulation without writing custom code.

To create an Application Center Test

1. Right-click the Tests folder and select New Test.

   The wizard will start collecting information about the type of test you want to create.

2. Select the Record new test option, and then click Next.
3. Click Start recording when you are ready to begin browsing with Internet Explorer.
4. Click Stop recording to stop recording. The recording can be stopped and restarted multiple times to avoid recording specific portions of the browsing session. When you have finished recording, click Next.
5. In the Test options dialog box, type a name in the Test name box and then click Next.
6. Click Finish to create the test with the settings you specified.

To add an existing user group to a test

1. Right-click the test's name and select Properties.
2. Click the Users tab.
3. Select the Specify users option and then select the user group from the list. The group(s) you select will be used in the next test run.

Figure 6.1 shows the referenced Users tab.

Figure 6.1. The Users tab in the Form data Properties dialog box for an Application Center Test

You can obtain more information about creating user groups and editing cookies in the ACT Help files.

Chapter 7: Deployment Considerations

After you have implemented and validated the solution scenarios, there are a number of ongoing operational activities that must happen to ensure that they will continue to run successfully. The "Platform and Infrastructure" paper in this series provides information and references on how the IT staff in your organization should operate each service in the infrastructure. This chapter introduces a few additional deployment considerations for the specific solution scenarios in this paper.

Deploying the Intranet and Extranet Applications

One of the deliverables in the development phase is a setup program that installs the sample intranet and extranet applications on your computers. This section highlights the techniques used in the custom installers of the sample applications. Information is provided about how to use the custom installers to programmatically configure directory security for the virtual directories, as well as programmatically configure Windows Authorization Manager stores, applications, roles, tasks, and operations.

For more information about setup applications and custom installers, see:

• The MSDN article "Visual Basic and Visual C# Concepts: Introduction to Installation Components".
• The MSDN article "Modifying Internet Information Services During Deployment with Custom Actions".

Configure Anonymous Access

A Web setup installation project inherits the security settings of the parent virtual directory or site when you install it. This means that if you install the project on the default Web site and this site allows for anonymous access, your application will allow anonymous access as well.

For the delegation model to work when you use Internet Information Services (IIS) 6.0-integrated security with the Kerberos version 5 authentication protocol, you must ensure that anonymous access is disabled. On the other hand, if you use ASP.NET Forms-based authentication, you must ensure anonymous access is enabled. To allow multiple authentication schemes for the same application, you will need to create more than one virtual directory.

The property for anonymous access is unfortunately not available through Web setup projects. For this reason, you must:

1. Write a custom installer to enable or disable anonymous access.
2. Pass the necessary parameters from the setup wizard to the installer at run time.

The actual code to set the MD_AUTH_ANONYMOUS bit is just a few lines inside the AllowAnonymous method as shown in the following sample:

//Change the MD_AUTH_ANONYMOUS bit if set to something else
//than allow parameter specifies
if (Convert.ToBoolean(IISVdir.Properties["AuthAnonymous"].Value) != allow)
{
  IISVdir.Properties["AuthFlags"].Value = 
    Convert.ToInt32(IISVdir.Properties["AuthFlags"].Value) ^ MD_AUTH_ANONYMOUS;
}

While setting the actual bit is easy, the challenging part is to determine where to set it. Because you might have many sites running simultaneously on the same server running IIS 6.0, you need to write some code with skill to determine which installation site the user will attempt to use. See the FindServerNum function in the Tools and Templates sample code that accompanies this paper for a sample of how to accomplish this task. The FindServerNum function is located in the IisInstallerUtil.<lang> file in the AppDevAspLib folder.

Because the sample is available in both Microsoft Visual C#® and Visual Basic® .NET, there is an AppDevAspLib folder under both the CS folder and the VB folder. During the setup, you can type an arbitrary virtual directory name and port number.

To configure the Web setup application to pass these parameters at run time

1. Open one of the sample solution files in Microsoft Visual Studio® .NET
2. Select the AppDevASPIntranetSetup or AppDevASPExtranetSetup project in Solution Explorer, and then open the Custom Actions Editor.
3. In the Custom Actions Editor, select the custom action that you added earlier.
4. In the Properties dialog box, select the CustomActionData property, and then in the property type /VDIR=<TARGETVDIR> /PORT=<TARGETPORT>

Note   You should also override the other methods such as Uninstall, Commit, and Rollback to provide a good installation and uninstallation experience.

Authorization Manager

Windows Authorization Manager is a component included with Microsoft Windows Server™ 2003 that is also available as a download for Windows 2000 Server. On a developer workstation you must have access to the Microsoft.Interop.Security.AzRoles.dll file (typically located in C:\WINDOWS\Microsoft.NET\AuthMan) in order to access the Windows Authorization Manager object model. To run Windows Authorization Manager, the actual COM object that Microsoft.Interop.Security.AzRoles.dll wraps must also be registered on the computer. This COM object is installed and registered automatically with Windows 2003 Server and should not be installed manually.

Create Stores, Applications, Operations, Tasks, and Roles

The Authorization Manager policy store, application, operations, and tasks need to be created as part of the installation program. After you have decided what tasks, operations, and roles are needed for your customized solution, and where you want to store them, you are ready to build an installer for your application that will configure Windows Authorization Manager.

The following sample code creates an empty Windows Authorization Manager store in an XML file:

String AzPolicyURL = @"msxml://C:\AppDevASPIntranet.xml";
AzAuthorizationStoreClass store = new AzAuthorizationStoreClass();
store.Initialize(AzMan.AZ_AZSTORE_FLAG_ACCESS_CHECK, AzPolicyURL, null);

See the AzManInstaller class of the sample application for the Contoso implementation, which also creates an application, operations, tasks, and roles.

---