Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

Intranet Security

J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation

Published: November 2002

Last Revised: January 2006

Applies to:

• ASP.NET 1.1
• .NET Framework 1.1

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Building Secure ASP.NET Applications.

Summary: This chapter describes how to secure common intranet application scenarios. It presents the characteristics of each scenario and describes the steps necessary to secure the scenario. Analysis sections are also included to provide further information. (34 printed pages)

Contents

ASP.NET to SQL Server
ASP.NET to Enterprise Services to SQL Server
ASP.NET to Web Services to SQL Server
Flowing the Original Caller to the Database
Summary

Access to intranet applications is restricted to a limited group of authorized users (such as employees that belong to a domain). While an intranet setting limits the exposure of your application, you may still face several challenges when you develop authentication, authorization, and secure communication strategies. For example, you may have non-trusting domains, which make it difficult to flow a caller's security context and identity through to the back-end resources within your system. You may also be operating within a heterogeneous environment with mixed browser types. This makes it more difficult to use a common authentication mechanism.

If you have a homogenous intranet where all computers run the Microsoft® Windows® 2000 operating system or later and you have a domain where users are trusted for delegation, delegation of the original caller's security context to the back end becomes an option.

You must also consider secure communication. Despite the fact that your application runs in an intranet environment, you cannot consider the data sent over the network secure. It is likely that you will need to secure the data sent between browsers and the Web server in addition to data sent between application servers and databases.

The following common intranet scenarios are used in this chapter to illustrate key authentication, authorization, and secure communication techniques:

• ASP.NET to Microsoft SQL Server™
• ASP.NET to Enterprise Services to SQL Server
• ASP.NET to Web Services to SQL Server

In addition, this chapter describes a delegation scenario (Flowing the Original Caller to the Database), in which the original caller's security context and identity flows at the operating system level from browser to database using intermediate Web and application servers.

ASP.NET to SQL Server

In this scenario, a HR database serves per-user data securely on a homogenous intranet. The application uses a trusted subsystem model and executes calls on behalf of the original callers. The application authenticates callers by using Integrated Windows authentication and makes calls to the database using the ASP.NET process identity. Due to the sensitive nature of the data, SSL is used between the Web server and clients.

The basic model for this application scenario is shown in Figure 5.1.

Figure 5.1. ASP.NET to SQL Server

Characteristics

This scenario has the following characteristics:

• Clients have Internet Explorer.
• User accounts are in Microsoft Active Directory® directory service.
• The application provides sensitive, per-user data.
• Only authenticated clients should access the application.
• The database trusts the application to authenticate users properly (that is, the application makes calls to the database on behalf of the users).
• Microsoft SQL Server is using a single database user role for authorization.

Secure the Scenario

In this scenario, the Web server authenticates the caller and restricts access to local resources by using the caller's identity. You don't have to impersonate within the Web application in order to restrict access to resources against the original caller. The database authenticates against the ASP.NET default process identity, which is a least privileged account (that is, the database trusts the ASP.NET application).

Table 5.1. Security measures

The Result

Figure 5.2 shows the recommended security configuration for this scenario.

Figure 5.2. The recommended security configuration for the ASP.NET to SQL Server intranet scenario

Security Configuration Steps

Before you begin, you'll want to see the following:

• Creating custom ASP.NET accounts (see How To: Create a Custom Account to Run ASP.NET 1.1 in the Reference section of this guide)
• Creating a service account for ASP.NET 2.0 (see How To: Create a Service Account for an ASP.NET 2.0 Application)
• Creating a least privileged database account (see Chapter 12, Data Access Security)
• Configuring SSL on a Web server (see How To: Set Up SSL on a Web Server in the Reference section of this guide)
• Configuring IPSec (see How To: Use IPSec to Provide Secure Communication Between Two Servers in the Reference section of this guide)

Configuring IIS

Configuring ASP.NET

<!-- userName="machine" password="AutoGenerate" 
  --  >

<!-- userName="machine" 
  password="YourNewStrongPassword" --  >

<authentication mode="Windows" />

<identity impersonate="false" />

Configuring SQL Server

Configuring secure communication

Analysis

• Integrated Windows authentication in IIS is ideal in this scenario because all users have Windows accounts and are using Microsoft Internet Explorer. The benefit of Integrated Windows authentication is that the user's password is never sent over the network. Additionally, the logon is transparent for the user because Windows uses the current interactive user's logon session.

• ASP.NET is running as least privileged account, so potential damage from compromise is mitigated.

• You don't need to impersonate in ASP.NET to perform .NET role checks or to secure resources within Windows ACLs against the original caller. To perform .NET role checks against the original caller, the WindowsPrincipal object that represents the original caller is retrieved from the HTTP context as follows:

  WindowsPrincipal wp = (HttpContext.Current.User as 
    WindowsPrincipal);
  if ( wp.IsInRole("Manager") )
  {
    // User is authorized to perform manager-specific functionality
  }
  

Note   Additionally, if you are running ASP.NET 2.0 and have enabled the Role Manager feature, you can use the Roles APIs for role checks. For more information on using the Role Manager feature in ASP.NET 2.0, see "How To: Use Role Manager in ASP.NET 2.0."

The ASP.NET FileAuthorizationModule provides ACL checks against the original caller for ASP.NET file types that are mapped within IIS to the aspnet_isapi.dll. For static file types such as .jpg, .gif and .htm files, IIS acts as the gatekeeper and performs access checks using the original caller's identity, based on the NTFS permissions associated with the file.

• Using Windows authentication to SQL Server means that you avoid storing credentials in files and passing credentials over the network to the database server.

• The use of a duplicated Windows account on the database server (one that matches the ASPNET process identity account) results in increased administration. If a password is changed on one computer, it must be synchronized and updated on the other. In some scenarios, you may be able to use a least-privileged domain account for easier administration. This is not an issue when using a custom Windows domain account for running an ASP.NET process, or when using IIS 6.0 on Windows Server 2003, because the default process identity can be given direct access to the database.

• The duplicated local account approach also works in the presence of a firewall where the ports required for Windows authentication may not be open. The use of Windows authentication and domain accounts may not work in this scenario.

• You'll need to ensure that your Windows groups are as granular as your security needs. Because .NET role-based security is based on Windows group membership this solution relies on Windows groups being set up at the correct level of granularity to match the categories of users (sharing the same security privileges) who access the application. The Windows groups that you use here to manage roles could be local to that computer or domain groups

• SQL Server database user roles are preferred to SQL server application roles to avoid the associated password management and connection pooling issues associated with the use of SQL application roles.

  Applications activate SQL application roles by calling a built-in stored procedure with a role name and a password. Therefore, the password must be stored securely. Database connection pooling must also be disabled when you use SQL application roles, which severely impacts application scalability.

  For more information about SQL Server database user roles and SQL Server application roles, see Chapter 12, Data Access Security.

• The database user is added to a database user role and permissions are assigned for the role so that if the database account changes; you don't have to change the permissions on all database objects.

Q&A

• Why can't I enable impersonation for the Web application, so that I can secure the resources accessed by my Web application using ACLs configured against the original caller?

  If you enable impersonation, the impersonated security context will not have network credentials (assuming delegation is not enabled and you are using Integrated Windows authentication). Therefore, the remote call to SQL Server will use a NULL session, which will result in a failed call. With impersonation disabled, the remote request will use the ASP.NET process identity.

  The preceding scenario uses the ASP.NET FileAuthorizationModule, which performs authorization using Windows ACLs against the original caller identity and does not require impersonation.

  If you use Basic authentication instead of Integrated Windows authentication (NTLM) and you do enable impersonation, each call to the database would use the original caller's security context. Each user account (or the Windows groups to which the user belongs) would require SQL Server logins. Permissions on database objects would need to be secured against the Windows group (or original caller).

• The database doesn't know who the original caller is. How can I create an audit trail?

  Audit end user activity within the Web application or pass the identity of the user explicitly as a parameter of the data access call.

Related Scenarios

Non-Internet Explorer Browsers

Integrated Windows authentication to IIS requires Internet Explorer. In a mixed browser environment, your typical options would include:

• Basic authentication and SSL. Basic authentication is supported by most browsers. Since the user's credentials are passed over the network, you must use SSL to secure the scenario.

• Client certificates. Individual client certificates can either be mapped to a unique Windows account or a single Windows account can be used to represent all clients. The use of client certificates also requires SSL.

• Forms authentication. Forms authentication can validate credentials against a custom data store such as a database or against Active Directory.

  If you authenticate against Active Directory, make sure that you retrieve only the necessary groups that are pertinent to your application. Just like you shouldn't issue queries against a database using SELECT * clauses, you shouldn't blindly retrieve all groups from Active Directory.

  Note   ASP.NET 2.0 provides a Membership feature along with Login controls that help you to easily implement Forms authentication. With ASP.NET, you do not need to write any custom code because the Membership feature does the validation for you. For more information, see "How To: Use Membership in ASP.NET 2.0."

  If you authenticate against a database, you need to carefully parse the input used in SQL commands to protect against SQL injection attacks, and you should store password hashes (with salt) in the database instead of clear text or encrypted passwords.

  Note   Although the built-in membership providers in ASP.NET 2.0 do this automatically, you will need to perform this step when developing the custom membership feature.

  For more information about using SQL Server as a credential store and storing passwords in the database, see Chapter 12, Data Access Security.

Notice that in all cases, if you don't use Integrated Windows authentication, where the platform manages credentials for you, you end up using SSL. However, this benefit pertains strictly to the authentication process. If you are passing security sensitive data over the network, you must still use IPSec or SSL.

SQL authentication to the database

In some scenarios you may be forced to use SQL authentication instead of the preferred Windows authentication. For example, there may be a firewall between the Web application and database, or the Web server may not be a member of your domain for security reasons. This also prevents Windows authentication. In this case, you might use SQL authentication between the database and Web server. To secure this scenario, you should:

• Use the Data Protection API (DPAPI) to secure database connection strings that contain usernames and passwords. For more information, see the following resources:
  • Storing Database Connection Strings Securely, in Chapter 12, "Data Access Security"
  • How To: Use DPAPI (Machine Store) from ASP.NET 1.1 in the Reference section of this guide
  • How To: Use DPAPI (User Store) from ASP.NET 1.1 with Enterprise Services in the Reference section of this guide
  • How To: Create a DPAPI Library in ,NET 1.1 in the Reference section of this guide
• Use IPSec or SSL between the Web server and database server to protect the clear text credentials passed over the network.

Flowing the original caller to the database

In this scenario, calls are made from the Web application to the database using the security context of the original caller. With this approach, it's important to note the following:

• If you choose this approach, you need to use either Kerberos authentication (with accounts configured for delegation) or Basic authentication.

  A delegation scenario is discussed in the "Flowing the Original Caller to the Database" section later in this chapter.

• You must also enable impersonation in ASP.NET. This means that local system resource access is performed using the original caller's security context and as a result, ACLs on local resources such as the registry and event log require appropriate configuration. An alternative to enabling impersonation in ASP.NET is to use programmatic impersonation.

• Database connection pooling is limited because original callers won't be able to share connections. Each connection is associated with the caller's security context.

• An alternate approach to flowing the user's security context is to flow the original caller's identity at the application level (for example, by using method and stored procedure parameters).

ASP.NET to Enterprise Services to SQL Server

In this scenario, ASP.NET pages call business components hosted in an Enterprise Services application that in turn connects to a database. As an example, consider an internal purchase order system that uses transactions over the intranet and allows internal departments to place orders. This scenario is shown in Figure 5.3.

Figure 5.3. ASP.NET calls a component within Enterprise Services, which calls the database.

Characteristics

This scenario has the following characteristics:

• Users have Internet Explorer.
• Components are deployed on the Web server.
• The application handles sensitive data that must be secured while in transit.
• Business components connect to SQL Server using Windows authentication.
• Business functionality within these components is restricted based on the identity of the caller.
• Serviced components are configured as a server application (out-of-process).
• Components connect to the database using the server application's process identity.
• Impersonation is enabled within ASP.NET (to facilitate Enterprise Services role-based security).

Secure the Scenario

In this scenario, the Web server authenticates the original caller and flows the caller's security context to the serviced component. The serviced component authorizes access to business functionality based on the original caller's identity. The database authenticates against the Enterprise Service application's process identity (that is, the database trusts the serviced components within the Enterprise Services application). When the serviced component makes calls to the database, it passes the user's identity at the application level (by using trusted query parameters).

Table 5.2. Security measures

The Result

Figure 5.4 shows the recommended security configuration for this scenario.

Figure 5.4. The recommended security configuration for the ASP.NET to local Enterprise Services to SQL Server intranet scenario

Security Configuration Steps

Before you begin, you'll want to see the following:

• Creating a least privileged database account (see Chapter 12, Data Access Security)
• Configuring SSL on a Web server (see How To: Set Up SSL on a Web Server in the Reference section of this guide)
• Configuring IPSec (see How To: Use IPSec to Provide Secure Communication Between Two Servers in the Reference section of this guide)
• Configuring Enterprise Services security (see How To: Use Role-based Security with Enterprise Services in .NET 1.1 in the Reference section of this guide)

Configuring IIS

Configuring ASP.NET

<authentication mode="Windows" />

<identity impersonate="true" />

<processModel 
    comImpersonationLevel="Impersonate"

Configuring enterprise services

[assembly:
  ApplicationActivation(ActivationOption.
  Server)]

Configuring SQL Server

Configuring secure communication

Analysis

• ASP.NET and Enterprise Services are running as least privileged accounts, so potential damage from compromise is mitigated. If either process identity were compromised, the account's limited privileges reduce the scope of damage. Also, in the case of ASP.NET, if malicious script were injected, potential damage is constrained.
• The ASP.NET application must be configured for impersonation in order to flow the security context of the original caller to the Enterprise Services components (to support Enterprise Services (COM+) role-based authorization). If you do not impersonate, role checks are made against the process identity (that is, the ASP.NET worker process). Impersonation affects who you authorize resources against.
• Without impersonation, system resource checks are against the ASP.NET process identity. With impersonation, system resource checks are made against the original caller. For more information about accessing system resources from ASP.NET, see Accessing System Resources in Chapter 8, "ASP.NET Security."
• By using Enterprise Services (COM+) roles, access checks are pushed to the middle tier, where the business logic is located. In this case, callers are checked at the gate, mapped to roles, and calls to business logic are based on roles. This avoids unnecessary calls to the back end. Another advantage of Enterprise Services (COM+) roles is that you can create and administer roles at deployment rime, using the Component Services Manager.
• Windows authentication to SQL means you avoid storing credentials in files and sending them across the network.
• The use of a local account to run the Enterprise Services application, together with a duplicated account on the database server, also works in the presence of a firewall where the ports required for Windows authentication may not be open. The use of Windows authentication and domain accounts may not work in this scenario.

Pitfalls

• The use of a duplicated Windows account on the database server (one that matches the Enterprise Services process account) results in increased administration. Passwords should be manually updated and synchronized on a periodic basis.
• Because .NET role-based security is based on Windows group membership, this solution relies on Windows groups being set up at the correct level of granularity to match the categories of users (sharing the same security privileges) who access the application.

ASP.NET to Web Services to SQL Server

In this scenario, a Web server that runs ASP.NET pages connects to a Web service on a remote server. This server in turn connects to a remote database server. As an example, consider a HR Web application that provides sensitive data specific to a user. The application relies on the Web service for data retrieval. The basic model for this application scenario is shown in Figure 5.5.

Figure 5.5. ASP.NET to remote Web Service to SQL Server

The Web service exposes a method that allows an individual employee to retrieve his or her own personal details. Details must be provided only to authenticated individuals using the Web application. The Web service also provides a method that supports the retrieval of any employee details. This functionality must be available only to members of the HR or payroll department. In this scenario, employees are categorized into three Windows groups:

• HRDept (members of the HR department)

  Members of this group can retrieve details about any employee.

• PayrollDept (members of the Payroll department)

  Members of this group can retrieve details about any employee.

• Employees (all employees)

  Members of this group can only retrieve their own details.

Due to the sensitive nature of the data, the traffic between all nodes should be secure.

Characteristics

• Users have Internet Explorer 5.x or later.
• All computers run Windows 2000 or later.
• User accounts are in Active Directory within a single forest.
• The application flows the original caller's security context all the way to the database.
• All tiers use Windows authentication.
• The machine account that identifies the ASP.NET default process, or the custom domain-level accounts used for ASP.NET processes, are configured for delegation.
• The database does not support delegation.

Secure the Scenario

In this scenario, the Web server that hosts the ASP.NET Web application authenticates the original caller's identity and flows their security context to the remote server that hosts the Web service. This enables authorization checks to be applied to Web methods to either allow or deny access to the original caller. The database authenticates against the Web service process identity (the database trusts the Web service). The Web service in turn makes calls to the database and passes the user's identity at the application level using stored procedure parameters.

Table 5.3. Security measures

The Result

Figure 5.6 shows the recommended security configuration for this scenario.

Figure 5.6. The recommended security configuration for the ASP.NET to Web Service to SQL Server intranet scenario

Security Configuration Steps

Before you begin, you'll want to see the following:

• Configuring SSL on a Web server (see How To: Set Up SSL on a Web Server in the Reference section of this guide)
• Configuring IPSec (see How To: Use IPSec to Provide Secure Communication Between Two Servers in the Reference section of this guide)

Configuring the Web server (that hosts the Web application)

<authentication mode="Windows" />

<identity impersonate="true" />

Configuring the application server (that hosts the Web service)

<!-- userName="machine" password="AutoGenerate" 
  -- >

<!-- userName="machine" 
  password="YourNewStrongPassword" -- >

<authentication mode="Windows" />

<identity impersonate="false" />

Configure SQL Server

Configuring secure communication

Analysis

• Integrated Windows authentication in IIS is ideal in this scenario because all users are using Windows 2000 or later, Internet Explorer 5.x or later, and have accounts in Active Directory, which makes it possible to use the Kerberos authentication protocol (which supports delegation). This allows you to flow the security context of the user across computer boundaries.

• End user accounts must be NOT marked as "Sensitive and cannot be delegated" in Active Directory. The Web server computer account must be marked as "Trusted for delegation" in Active Directory. For more details, see How To: Implement Kerberos Delegation for Windows 2000 in the Reference section of this guide.

• Because ASP.NET on the Web server and application server runs with a least privileged local account, potential damage from compromise is mitigated.

• The Web service and Web application are both configured for Windows authentication. IIS on both computers is configured for Integrated Windows authentication.

• When making a call to the Web service from the Web application, no credentials are passed by default. They are required in order to respond to the network authentication challenge issued by IIS on the downstream Web server. You must specify this explicitly by setting the Credentials property of the Web service proxy as shown in the following:

  wsproxy.Credentials = CredentialCache.DefaultCredentials;
  

  For more information about calling Web services with credentials, see Chapter 10, Web Services Security.

• The Web application is configured for impersonation. As a result, calls from the Web application to the Web service flow the original caller's security context and allow the Web service to authenticate (and authorize) the original caller.

• .NET roles are used within the Web service to authorize the users based on the Windows group to which they belong (HRDept, PayrollDept and Employees). Members of HRDept and PayrollDept can retrieve employee details for any employee, while members of the Employees group are authorized to retrieve only their own details.

  Web methods can be annotated with the PrincipalPermissionAttribute class to demand specific role membership, as shown in the following code sample. Notice that PrincipalPermission can be used instead of PrincipalPermissionAttribute. This is a common feature of all .NET attribute types.

   [WebMethod]
  [PrincipalPermission(SecurityAction.Demand, 
                    Role=@"DomainName\HRDept)]
  public DataSet RetrieveEmployeeDetails()
  {
  }
  

  The attribute shown in the preceding code means that only members of the DomainName\HRDept Windows group are allowed to call the RetrieveEmployeeDetails method. If any nonmember attempts to call the method, a security exception is thrown.

• ASP.NET File Authorization (within the Web application and Web service) performs ACL checks against the caller for any file type for which a mapping exists in the IIS Metabase that maps the file type to Aspnet_isapi.dll. Static file types (such as .jpg, .gif, .htm, and so on), for which an ISAPI mapping does not exist are checked by IIS (again using the ACL attached to the file).

• Because the Web application is configured for impersonation, resources accessed by the application itself must be configured with an ACL that grants at least read access to the original caller.

• The Web service does not impersonate or delegate; therefore, it accesses local system resources and the database using the ASP.NET process identity. As a result, all calls are made using the single process account. This enables database connection pooling to be used. If the database doesn't support delegations (such as SQL Server 7.0 or earlier), this scenario is a good option.

• Windows authentication to SQL Server means you avoid storing credentials on the Web server and it also means that credentials are not sent across the network to the SQL Server computer.

• SSL between the original caller and Web server protects the data passed to and from the Web application.

• IPSec between the downstream Web server and database protects the data passed to and from the database.

Pitfalls

• The use of a duplicated Windows account on the database server (one that matches the ASP.NET process account) results in increased administration. Passwords should be manually updated and synchronized on a periodic basis.

  As an alternative, consider using least-privileged domain accounts. For more information about choosing an ASP.NET process identity, see Chapter 9, Enterprise Services Security.

  Note   This is not an issue when using a custom Windows domain account for running an ASP.NET process, or when using IIS 6.0 on Windows Server 2003, because the default process identity can be given direct access to the database.

• Because .NET role-based security is based on Windows group membership, this solution relies on Windows groups being set up at the correct level of granularity to match the categories of users (sharing the same security privileges) who will access the application.

• Because Kerberos delegation is unrestricted on Windows 2000 Server, you must carefully control which applications identities run on the Web server. To raise the bar on security, limit the scope of the domain account's reach by removing the account from Domain Users group and provide access only from appropriate computers. For more information, see Default Access Control Settings white paper.

  Note   However, Windows Server 2003 introduces a feature known as constrained delegation. This feature allows administrators to specify exactly which services can be accessed on a downstream server or a domain account when using an impersonated user's security context. For more information see, "How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0."

Q&A

• The database doesn't know who the original caller is. How can I create an audit trail?

Audit end user activity within the Web service or pass the identity of the user explicitly as a parameter of the data access call.

Related scenarios

If you need to connect to non-SQL Server databases, or you currently use SQL authentication, you must pass database account credentials explicitly using the connection string. If you do so, make sure that you securely store the connection string.

For more information, see Storing Database Connection Strings Securely within Chapter 12, "Data Access Security."

Flowing the Original Caller to the Database

The scenarios discussed earlier have used the trusted subsystem model and in all cases the database has trusted the application server or Web server to correctly authenticate and authorize users. While the trusted subsystem model offers many advantages, some scenarios (perhaps for auditing reasons) may require you to use the impersonation/delegation model and flow the original caller's security context across computer boundaries all the way to the database.

Typical reasons why you may need to flow the original caller to the database include:

• You need granular access in the database and permissions are restricted by object. Specific users or groups can read, while others can write to individual objects.

  This is in contrast to less granular task-based authorization, where role membership determines read and write capabilities for specific objects.

• You may want to use the auditing capabilities of the platform, rather than flow identity and perform auditing at the application level.

If you do choose an impersonation/delegation model (or are required to do so due to corporate security policy) and flow the original caller's context through the tiers of your application to the back end, you must design with delegation and network access in mind (which is nontrivial when spanning multiple computers). The pooling of shared resources (such as database connections) also becomes a key issue and can significantly reduce application scalability.

This section shows you how to implement the impersonation/delegation for two of the most common application scenarios:

• ASP.NET to SQL Server
• ASP.NET to Enterprise Services to SQL Server

For more information about the trusted subsystem and impersonation/delegation models and their relative merits, see Chapter 3, Authentication and Authorization.

ASP.NET to SQL Server

In this scenario, calls to the database are made using the security context of the original caller. Authentication options described in this section include Basic and Integrated Windows authentication. A Kerberos delegation scenario is described within the "ASP.NET to Enterprise Services to SQL Server" section.

Using basic authentication at the Web server

The following configuration settings for Basic authentication enable you to flow the original caller all the way to the database.

Table 5.5. Security measures

With this approach, it's important to note the following points:

• Basic authentication prompts the user with a pop-up dialog box into which they can type credentials (user name and password).
• The database must recognize the original caller. If the Web server and database are in different domains, appropriate trust relationships must be enabled to allow it to authenticate the original caller.

Using integrated Windows authentication at the Web server

Integrated Windows authentication results in either NTLM or Kerberos authentication and is dependent upon the client and server computer configurations.

NTLM authentication does not support delegation and as a result does not allow you to flow the original caller's security context from the Web server to a physically remote database. The single network hop allowed for NTLM authentication is used between the browser and Web server. To use NTLM authentication, the SQL Server must be installed on the Web server, which is likely to be appropriate only for very small intranet applications.

ASP.NET to Enterprise Services to SQL Server

• In this scenario, ASP.NET pages call business components hosted in a remote Enterprise Services application that in turn talk to a database. The original caller's security context flows all the way from the browser to the database. This is shown in Figure 5.9.

  

  Figure 5.9. ASP.NET calls a component within Enterprise Services, which calls the database

Characteristics

• Users have Internet Explorer 5.x or later.
• All computers are Windows 2000 or later.
• User accounts are maintained in Active Directory within a single forest.
• The application flows the original caller's security context (at the operating system level) all the way to the database.
• All tiers use Windows authentication.
• Domain user accounts are configured for delegation and the account used to run the Enterprise Services application must be marked as "Trusted for delegation" within Active Directory.

Secure the scenario

In this scenario, the Web server authenticates the caller. You must then configure ASP.NET for impersonation in order to flow the original caller's security context to the remote Enterprise Services application. Within the Enterprise Services application, component code must explicitly impersonate the caller (using CoImpersonateClient) in order to ensure the caller's context flows to the database.

Table 5.6. Security measures

The Result

Figure 5.10 shows the recommended security configuration for this scenario.

Figure 5.10. ASP.NET calls a component within Enterprise Services, which calls the database. The original caller's security context flows to the database.

Security configuration steps

Before you begin, you should be aware of the following configuration issues:

• The Enterprise Services process account must be marked "Trusted for delegation" in Active Directory and end user accounts must not be marked "Sensitive and cannot be delegated." For more information, see How To: Implement Kerberos Delegation for Windows 2000 in the Reference section of this guide.

• Windows 2000 or later is required on all computers. This includes client (browser) computers and all servers.

• All computers must be in the Active Directory and must be part of a single forest.

• The application server that hosts Enterprise Services must be running Windows 2000 SP3 or later.

• If you are using Internet Explorer 6.0 on Windows 2000, it defaults to NTLM authentication instead of the required Kerberos authentication. To enable Kerberos delegation, see article Q299838, "Unable to negotiate Kerberos authentication after upgrading to Internet Explorer 6," in the Microsoft Knowledge Base.

  Important   This applies only to Internet Explorer version 6 or later for Windows 2000; it works correctly on Windows Server 2003.

<authentication mode="Windows" />

<identity impersonate="true" />

<processModel comImpersonationLevel="Delegate"

<processModel 
  comAuthenticationLevel="PktPrivacy"

class COMSec
{
[DllImport("OLE32.DLL", CharSet=CharSet.Auto)]
public static extern long CoImpersonateClient();
[DllImport("OLE32.DLL", CharSet=CharSet.Auto)]
public static extern long CoRevertToSelf();
}

COMSec.CoImpersonateClient();
COMSec.CoRevertToSelf();

[assembly: 
  ApplicationActivation
  (ActivationOption.Server)]

[assembly: ApplicationAccessControl(
             Authentication = 
             AuthenticationOption.Privacy)]

[assembly: 
  ApplicationAccessControl(AccessChecksLevel= 
 AccessChecksLevelOption. ApplicationComponent)]

[ComponentAccessControl(true)]

Analysis

• The key to flowing the original caller's security context is Kerberos authentication, which generates a delegate-level token. After the server process (IIS) receives the delegate-level token, it can pass it to any other process, running under any account on the same computer, without changing its delegation level. It does not matter whether the worker process is running as a local or domain account. It does matter what IIS is running as. If it's running as something other than LocalSystem, the account it is running under needs to be marked as "Trusted for delegation" in Active Directory.

  If IIS is running as LocalSystem, the computer account must be marked as "Trusted for delegation". For more information, see How To: Implement Kerberos Delegation for Windows 2000 in the Reference section of this guide.

• Integrated Windows authentication (with Kerberos) in IIS is ideal in this scenario because all users have Windows accounts and they are using Internet Explorer 5.x or later. The benefit of Integrated Windows authentication is that the user's password is never sent over the wire. Additionally, the logon will be transparent because Windows will use the current interactive user's logon session.

• ASP.NET constructs a WindowsPrincipal object and attaches it to the current Web request context (HttpContext.User). If you need to perform authorization checks within the Web application you can use the following code.

  WindowsPrincipal wp = (HttpContext.Current.User as 
    WindowsPrincipal);
  if ( wp.IsInRole("Manager") )
  {
    // User is authorized to perform manager-specific functionality
  }
  

Note   Additionally, if you are running ASP.NET 2.0 and have enabled the Role Manager feature, you can use the Roles APIs for role checks. For more information on using the Role Manager feature in ASP.NET 2.0, see "How To: Use Role Manager in ASP.NET 2.0."

The ASP.NET FileAuthorizationModule provides ACL checks against the original caller for ASP.NET file types that are mapped within IIS to the Aspnet_isapi.dll. For static file types such as .jpg, .gif and .htm files, IIS acts as the gatekeeper and performs access checks using the original caller's identity.

• By using Windows authentication to SQL, you avoid storing credentials in files on the application server and avoid passing them across the network. For example include the Trusted_Connection attribute in the connection string:

  ConStr="server=YourServer; database=yourdatabase; 
  Trusted_Connection=Yes;"
  

• The original caller's context flows across all tiers, which makes auditing extremely easy. You can use platform-level auditing (for example, auditing features provided by Windows and SQL Server).

Pitfalls

• If you are using Internet Explorer 6.0 on Windows 2000, the default authentication mechanism that is negotiated is NTLM (and not Kerberos). For more information, see article Q299838, Can't Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6, in the Microsoft Knowledge Base.

  Important   This applies only to Internet Explorer version 6 or later for Windows 2000; it works correctly on Windows Server 2003.

• Delegating users across tiers is expensive in terms of performance and application scalability compared to using the trusted subsystem model. You cannot take advantage of connection pooling to the database, because connections to the database are tied to original caller's security context and therefore cannot be efficiently pooled.

• This approach also relies on the granularity of Windows groups matching your application's security needs. That is, Windows groups must be set up at the correct level of granularity to match the categories of users (sharing the same security privileges) who access the application.

Summary

This chapter has described how to secure a set of common intranet application scenarios.

For Extranet and Internet application scenarios, see Chapter 6, Extranet Security and Chapter 7, Internet Security.

© Microsoft Corporation. All rights reserved.