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.

Creating custom ASP.NET accounts (see "Appendix " in the Reference section of this book)

Creating a least privileged database account (see Chapter 12)

Configuring SSL on a Web server (see "Appendix " in the Reference section of this book)

Configuring IPSec (see "Appendix " in the Reference section of this book)

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
}

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 local 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.

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.

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.

Users have Internet Explorer.

Components are deployed on the Web server.

The application handles sensitive data which 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).

Creating a least privileged database account (see Chapter 12)

Configuring SSL on a Web server (see "Appendix " in the Reference section of this book)

Configuring IPSec (see "Appendix " in the Reference section of this book)

Configuring Enterprise Services security (see "Appendix " in the Reference section of this book)

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.

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.

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.

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.

Domain user accounts are configured for delegation.

The database does not support delegation.

Configuring SSL on a Web server (see "Appendix " in the Reference section of this book)

Configuring IPSec (see "Appendix " in the Reference section of this book)

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 "Appendix " in the Reference section of this book.

ASP.NET on the Web server and application server runs with a least privileged local account (the local ASPNET account), so 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.

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=@"DomainNameHRDept)]
public DataSet RetrieveEmployeeDetails()
{
}

The attribute shown in the preceding code means that only members of the DomainNameHRDept 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.

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, "Chapter 8."

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.

Kerberos delegation is unrestricted and as a result 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 the white paper on the Microsoft Web site at http://www.microsoft.com/windows2000/techinfo/planning/security/secdefs.asp.

Users have various types of Web browsers.

The remote component is hosted by ASP.NET.

The Web application communicates with the remote component using the HTTP channel.

The ASP.NET application calls the .NET remote component and passes the original caller’s credentials for authentication. These are available from Basic authentication.

The data is sensitive and therefore must be secured between processes and computers.

Creating a least privileged database account (see Chapter 12)

Configuring SSL on a Web server (see "Appendix " in the Reference section of this book)

Configuring IPSec (see "Appendix " in the Reference section of this book)

ASP.NET on the Web server and application sever is running as a least privileged local account, so potential damage from compromise is mitigated. The default ASPNET account is used in both cases.

Use of the ASPNET local account (duplicated on the SQL Server computer) further reduces the potential security risk. A duplicated Windows account on the database server allows the remote component to run with a least privilege ASP.NET account on the application server.

Basic authentication at the Web server allows the user’s credentials to be used by the Web application to respond to Windows authentication challenges from the application server.

To call the remote component using the caller’s credentials, the Web application configures the remote component proxy as shown in the code fragment on the next page.

string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
IDictionary channelProperties =
                         ChannelServices.GetChannelSinkProperties(proxy);
NetworkCredential credentials;
credentials = new NetworkCredential(uid, pwd);
ObjRef objectReference = RemotingServices.Marshal(proxy);
Uri objectUri = new Uri(objectReference.URI);
CredentialCache credCache = new CredentialCache();
credCache.Add(objectUri, "Negotiate", credentials);
channelProperties["credentials"] = credCache;
channelProperties["preauthenticate"] = true;

For more information about flowing security credentials to a remote component, see Chapter 11.

Impersonation is not enabled within the ASP.NET Web application, because the remoting proxy is specifically configured using the user’s credentials obtained by Basic authentication. Any other resource accessed by the Web application uses the security context provided by the ASP.NET process account.

SSL between the user and Web server protects the data passed to and from the Web server and also protects the Basic credentials passed in clear text during the authentication process.

Integrated Windows authentication at the application server provides .NET role checks against the original caller. The roles correspond to Windows groups.

Role-based checks can be performed, even without impersonation.

ASP.NET File Authorization 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. IIS performs access checks for static files (not mapped to an ISAPI extension within IIS).

Because impersonation is not enabled on the application server, any local or remote resource access performed by the remote component does so using the ASPNET security context. ACLs should be set accordingly.

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

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.

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.

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 "Appendix " in the Reference section of this book.

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
}

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).

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.

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.