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

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

 

Internet 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 Internet 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. (17 printed pages)

Contents

ASP.NET to SQL Server
ASP.NET to Remote Enterprise Services to SQL Server
Summary

Internet applications have large audiences, many potential uses, and varied security requirements. They range from portal applications that require no user authentication, through Web applications that provide content for registered users, to large-scale e-commerce applications that require full authentication, authorization, credit card validation and secure communication of sensitive data over public and internal networks.

As Internet application developers, you face a challenge to ensure that your application uses appropriate defense mechanisms and is designed to be scalable, high performance, and secure. Some of the challenges you face include:

• Choosing an appropriate user credential store, for example, a custom database or Microsoft® Active Directory® service
• Making your application work through firewalls
• Flowing security credentials across the multiple tiers of your application
• Performing authorization
• Ensuring the integrity and privacy of data as it flows across public and internal networks
• Securing your application's state with a database
• Ensuring the integrity of your application's data
• Implementing a solution that can scale to potentially huge numbers of users

The two common Internet application scenarios presented in this chapter, which are used to illustrate recommended authentication, authorization and secure communication techniques are:

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

ASP.NET to SQL Server

In this scenario with two physical tiers, registered users securely log in to the Web-based application using a Web browser. The ASP.NET-based Web application makes secure connections to a Microsoft® SQL Server™ database to manage predominantly data retrieval tasks. An example is a portal application that provides news content to registered subscribers. This is shown in Figure 7.1.

Figure 7.1. An ASP.NET Web application to SQL Server Internet scenario

Characteristics

This scenario has the following characteristics:

• Users have a number of different browser types.
• Anonymous users can browse the application's unrestricted pages.
• Users must register or log on (through an HTML form) before being allowed to view restricted pages.
• User credentials are validated against a SQL Server database.
• All user input (such as user credentials) that is used in database queries is validated to mitigate the threat of SQL injection attacks.
• The front-end Web application is located within a perimeter network (also known as DMZ, demilitarized zone, and screened subnet), with firewalls separating it from the Internet and the internal corporate network (and the SQL Server database).
• The application requires strong security, high levels of scalability, and detailed auditing.
• The database trusts the application to authenticate users properly (that is, the application makes calls to the database on behalf of the users).
• The Web application connects to the database by using the ASP.NET process account.
• A single user-defined database role is used within SQL Server for database authorization.

Secure the Scenario

In this scenario, the Web application presents a logon page to accept credentials. Successfully validated users are allowed to proceed, all others are denied access. 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 7.1. Security summary

Category	Detail
Authentication	IIS is configured to allow anonymous access; the ASP.NET Web application authenticates users with Forms authentication to acquire credentials. Validation is against a SQL Server database. Users' passwords are not stored in the database. Instead password hashes with salt values are stored. The salt mitigates the threat associated with dictionary attacks. Microsoft® Windows® authentication is used to connect to the database using the least privileged Windows account used to run the ASP.NET Web application.
Authorization	The ASP.NET process account is authorized to access system resources on the Web server. Resources are protected with Windows ACLs. Access to the database is authorized using the ASP.NET application identity.
Secure Communication	Secure sensitive data sent between the users and the Web application by using SSL. Secure sensitive data sent between the Web server and the database server by using IPSec.

The Result

Figure 7.2 shows the recommended security configuration for this scenario.

Figure 7.2. The recommended security configuration for the ASP.NET to SQL Server Internet 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)

  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)

Configure the Web server

Configure IIS
Step	More Information
Enable Anonymous access for your Web application's virtual root directory.	To work with IIS authentication settings, use the IIS MMC snap-in. Right-click your application's virtual directory, and then click Properties. Click the DirectorySecurity tab, and then click Edit within the Anonymous access and authentication control group. Note   In IIS 6.0, the Edit button is located within the Authentication and access control group.

Configure ASP.NET
Step	More Information
Reset the password of the ASPNET account (used to run ASP.NET) to a known strong password.	This allows you to create a duplicate local account (with the same user name and password) on the database server. This is required to allow the ASPNET account to respond to network authentication challenges from the database server when it connects using Windows authentication. Note   If you are running IIS 6.0 on Windows Server 2003, the default ASP.NET Process account is identified on the network as DomainName\WebServerName$. You can use this account to give the ASP.NET process identity access to the database. Therefore this step can be skipped. An alternative here is to use a least privileged domain account (if Windows authentication is permitted through the firewall). For more information, see Process Identity for ASP.NET in Chapter 8, "ASP.NET Security." Edit Machine.config located in %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG Set your custom account user name and password attributes on the <processModel> element Default <!-- userName="machine" password="AutoGenerate" -- > Becomes <!-- userName="machine" password="YourStrongPassword" -- > Note   With IIS 6.0 running on Windows Server 2003 in process isolation mode, the processModel setting is not used. For more information on using a custom least privileged account, see How To: Create a Service Account for an ASP.NET 2.0 Application.
Configure your ASP.NET Web application to use Forms authentication (with SSL)	Edit Web.config in your application's virtual directory root Set the <authentication> element to: <authentication mode="Forms" > <forms name="MyAppFormsAuth" loginUrl="login.aspx" protection="All" timeout="20" path="/" > </forms> </authentication> For more information about using Forms authentication against a SQL Server database, see How To: Use Forms Authentication with SQL Server in ASP.NET 1.1 in the Reference section of this guide. If you are running ASP.NET 2.0, see How To: Use Forms Authentication with SQL Server in ASP.NET 2.0.

Configuring SQL Server

Step	More Information
Create a Windows account on your SQL Server computer that matches the ASP.NET process account	The user name and password must match your custom ASP.NET application account or must be ASPNET if you are using the default account. Note   If you are running IIS 6.0 on Windows Server 2003, the default ASP.NET Process account is identified on the network as DomainName\WebServerName$. You can use this account to give the ASP.NET process identity access to the database. Therefore this step can be skipped.
Configure SQL Server for Windows authentication
Create a SQL Server Login for newly created account Note   If you are running IIS 6.0 on Windows Server 2003, create a SQL Server login for the ASP.NET process identity directly by using the DomainName\WebServerName$ identifier	This grants access to SQL Server.
Create a new database user and map the login name to the database user	This grants access to the specified database.
Create a new user-defined database role within the database and place the database user into the role
Establish database permissions for the database role	Grant minimum permissions. For more information, see Chapter 12, Data Access Security.

Configuring Secure Communication

Step	More Information
Configure the Web site for SSL	See How To: Setup SSL on a Web Server in the Reference section of this guide.
Configure IPSec between application server and database server	See How To: Use IPSec to Provide Secure Communication Between Two Servers in the Reference section of this guide.

Analysis

• Forms authentication is ideal in this scenario because the users do not have Windows accounts. The Forms login page is used to acquire user credentials. Credential validation must be performed by application code. Any data store can be used. A SQL Server database is the most common solution, although Active Directory provides an alternate credential store.

• With Forms authentication, you must protect the initial logon credentials with SSL. The Forms authentication ticket (passed as a cookie on subsequent Web requests from the authenticated client) must also be protected. You could use SSL for all secured pages in order to protect the ticket. You can also encrypt the Forms authentication ticket by configuring the protection attribute of the <forms> element (to All or Encrypt), and by using the Encrypt method of the FormsAuthentication class to encrypt the ticket.

  The protection="All" attribute specifies that when the application calls FormsAuthentication.Encrypt, the ticket should be validated (integrity checked) and encrypted. Call this method when you create the authentication ticket, typically within the application's Login button event handler.

  string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
  

  Note   If you are running ASP.NET 2.0, it is recommended that you use the Membership feature which simplifies Forms Authentication implementation. For more information, see "How To: Use Membership in ASP.NET 2.0."

  For more information about Forms authentication and ticket encryption, see Chapter 8, ASP.NET Security.

  Note   If you are running ASP.NET 2.0, see How To: Use Forms Authentication with Active Directory in ASP.NET 2.0, How To: Use Forms Authentication with Active Directory in Multiple Domains in ASP.NET 2.0, and How To: Use Forms Authentication with SQL Server in ASP.NET 2.0.

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

• URL authorization on the Web server allows unauthenticated users to browse unrestricted Web pages and forces authentication for restricted pages.

• Because impersonation is not enabled, any local or remote resource access performed by the Web-based application is performed using the ASPNET process identity's security context. Windows ACLs on secure resources should be set accordingly.

• User credentials are validated against a custom SQL Server database. Password hashes (with salt) are stored within the database. For more information, see Authenticating Users against a Database in Chapter 12, "Data Access Security."

• By using Windows authentication to SQL Server, you avoid storing credentials in files on the Web server and also passing them over the network.

• If your application currently uses SQL authentication, you must securely store the database connection string as it contains user names and passwords. Consider using DPAPI. For more details, see Storing Database Connection Strings Securely, in Chapter 12, "Data Access Security."

• The use of a duplicated Windows account on the database server (one that matches the ASP.NET process account) results in increased administration. If a password is changed on one computer, it must be synchronized and updated on all computers. In some scenarios, you may be able to use a least-privileged domain account for easier administration.

• IPSec between the Web server and database server ensures the privacy of the data sent to and from the database.

• SSL between browser and Web server protects credentials and any other security sensitive data such as credit card numbers.

• If you use a Web farm, ensure that the encryption and validation keys —for example, those used to encrypt and validate the Forms authentication ticket (and specified by the <machineKey> element in Machine.config) —are consistent across all servers in the farm. See Chapter 8, ASP.NET Security, for further details about using ASP.NET in a Web farm scenario.

Pitfalls

The application must flow the original caller's identity to the database to support auditing requirements. Caller identity may be passed using stored procedure parameters.

Related Scenarios

Forms authentication against Active Directory

The user credentials that are accepted from the Forms login page can be authenticated against various stores. Active Directory is an alternate to using a SQL Server database.

More information

For more information, see How To: Use Forms Authentication with Active Directory in ASP.NET 1.1 in the Reference section of this guide.

For more information on using Forms authentication with ASP.NET 2.0, see How To: Use Forms Authentication with Active Directory in ASP.NET 2.0.

.NET roles for authorization

The preceding scenario doesn't take into consideration the different types of users accessing the application. For example, a portal server could have different subscription levels such as Standard, Premier, and Enterprise.

If role information is maintained in the user store (SQL Server database), the application can create a GenericPrincipal object in which role and identity information can be stored. After the GenericPrincipal is created and added to the Web request context (using HttpContext.User), you can add programmatic role checks to method code or you can decorate methods and pages with PrincipalPermission attributes to demand role membership.

Note   For ASP.NET 2.0, you can use the Role Manager feature to check the role membership using Roles APIs. For more information, see "How To: Use Role Manager in ASP.NET 2.0."

More information

• For more information about creating GenericPrincipal objects that contain role lists, see How To: Create GenericPrincipal Objects with Forms Authentication in ASP.NET 1.1 in the Reference section of this guide.
• For more information about PrincipalPermission demands and programmatic role checks, see Chapter 8, ASP.NET Security.
• 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.

Using a domain anonymous account at the Web server

In this scenario variation, the default anonymous Internet user account (a local account called IUSR_MACHINE) is replaced by a domain account. The domain account is configured with the minimum privileges necessary to run the application (you can start with no privilege and incrementally add privileges). If you have multiple Web-based applications, you can use different domain accounts (one for each Web-based application or virtual directory).

In order to flow the security context of the anonymous domain account from IIS to ASP.NET, turn on impersonation for the Web-based application by using the following web.config file setting:

<identity impersonate="true" />

If the Web-based application communicates with a remote resource such as a database, the domain account must be granted the necessary permissions to the resource. For example, if the application accesses a remote file system, ACLs must be configured appropriately to give (at minimum) read access to the domain account. If the application accesses a SQL Server database, the domain account must be mapped using a SQL login to a database login.

As the security context that flows through the application is that of the anonymous account, the original caller's identity (captured through Forms authentication) must be passed at the application level from tier to tier; for example, through method and stored procedure parameters.

More information

• For more information regarding this approach, see Using the Anonymous Internet User Account within Chapter 8, "ASP.NET Security."
• Before implementing this scenario, see article Q259353, Must Enter Password Manually After You Set Password Synchronization in the Microsoft Knowledge Base.

ASP.NET to Remote Enterprise Services to SQL Server

In this scenario, a Web server running ASP.NET pages makes secure connections to serviced components, located on a remote application server that in turn connects to a SQL Server database. In common with many Internet application infrastructures, the Web server and application server are separated by a firewall (and the Web server is located within a perimeter network). Serviced components make secure connections to SQL Server.

As an example, consider an Internet banking application that provides sensitive data, (for example, private financial details) to users. All banking transactions from the client to the database must be secured and data integrity is critical. Not only does the traffic to and from the user need to be secured but the traffic to and from the database needs to be secured as well. This is shown in Figure 7.3.

Figure 7.3. An ASP.NET to remote Enterprise Services to SQL Server Internet scenario

Characteristics

• Users have a number of different browser types.
• Anonymous users can browse the application's unrestricted pages.
• Users must register or log on (through an HTML form) before being allowed to view restricted pages.
• The front-end Web-based application is located within a perimeter network, with firewalls separating it from the Internet and the internal corporate network (and the application server).
• The application requires strong security, high levels of scalability, and detailed auditing.
• The Web-based application uses SOAP to connect to a Web services layer, which provides an interface to the serviced components that run within an Enterprise Services application on the application server. SOAP is preferred to DCOM due to firewall restrictions.
• SQL Server is using a single user-defined database role for authorization.
• Data is security sensitive and integrity and privacy must be secured over the network and in all persistent data stores.
• Enterprise Services (COM+) transactions are used to enforce data integrity.

Secure the Scenario

In this scenario, the Web service accepts credentials from a Forms login page and then authenticates the caller against a SQL Server database. The login page uses SSL to protect the user's credentials passed over the Internet.

The Web-based application communicates with a Web service, which provides an interface to the business services implemented within serviced components. The Web service trusts the Web-based application (inside the perimeter network) and authenticates the ASP.NET process identity. The user's identity is passed through all tiers at the application level using method and stored procedure parameters. This information is used for auditing the users' actions across the tiers.

Table 7.2. Security measures

Category	Detail
Authentication	Provide strong authentication at the Web server. IIS is configured for anonymous access and the Web-based application authenticates users with Forms authentication (against a SQL Server database). The Web service's virtual directory is configured for Integrated Windows authentication. Web services authenticate the Web-based application's process identity. Windows authentication is used to connect to the database. The database authenticates the least privileged Windows account used to run the Enterprise Services application.
Authorization	The trusted subsystem model is used and per-user authorization occurs only within the Web application. User access to pages on the Web server is controlled with URL authorization. The ASP.NET process account is authorized to access system resources on the Web server. Resources are protected with ACLs. Permissions within the database are controlled by a user-defined role. The Enterprise Services application identity is a member of the role. The Enterprise Services process account is authorized to access system resources on the application server. Resources are protected ACLs.
Secure Communication	Sensitive data sent between the users and the Web-based application is secured with SSL. Sensitive data sent between the Web server and Web service is secured with SSL. Sensitive data sent between serviced components and the database is secured with IPSec.

The Result

Figure 7.4 shows the recommended security configuration for this scenario.

Figure 7.4. The recommended security configuration for the ASP.NET to remote Enterprise Services to SQL Server Internet 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)

Configure the Web server

Configure IIS
Step	More Information
Enable Anonymous access for your Web-based application's virtual root directory

Configure ASP.NET
Step	More Information
Reset the password of the ASPNET account (used to run ASP.NET) to a known strong password.	This allows you to create a duplicate local account (with the same user name and password) on the application server. This is required to enable the ASPNET account to respond to network authentication challenges from the application server. Note   If you are running IIS 6.0 on Windows Server 2003, the default ASP.NET Process account is identified on the network as DomainName\WebServerName$. You can use this account to give the ASP.NET process identity access to the network resources. Therefore this step can be skipped. An alternative is to use a least privileged domain account (if Windows authentication is permitted through the firewall). For more information, see Process Identity for ASP.NET in Chapter 8, "ASP.NET Security." Edit Machine.config located in %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG Set your custom account username and password attributes on the <processModel> element. Default <!-- userName="machine" password="AutoGenerate" -- > Becomes <!-- userName="machine" password="YourStrongPassword" -- > Note   If you are running IIS 6.0 on Windows Server 2003 in process isolation mode, the processModel setting is not used. For more information on using a custom least privileged account, see How To: Create a Service Account for an ASP.NET 2.0 Application.
Configure your Web-based application to use Forms authentication (with SSL)	Edit Web.config in your application's virtual directory root Set the <authentication> element to: <authentication mode="Forms" > <forms name="MyAppFormsAuth" loginUrl="login.aspx" protection="All" timeout="20" path="/" > </forms> </authentication> For more information about using Forms authentication against a SQL Server database, see How To: Use Forms Authentication with SQL Server in ASP.NET 1.1 in the Reference section of this guide.

Configure the application server

Configure IIS
Step	More Information
Disable anonymous access
Configure Integrated Windows authentication	IIS authenticates the ASP.NET process identity from the Web-based application on the Web server.

Configure ASP.NET
Step	More Information
Use Windows authentication	Edit Web.config in your Web service's virtual directory root. Set the <authentication> element to: <authentication mode="Windows" />

Configure Enterprise Services
Step	More Information
Create a least privileged custom account for running the Enterprise Services server application	Note   If you use a local account, you must also create a duplicate account on the database server computer.
Configure the Enterprise Services application to use the custom account	Refer to Configuring Security within Chapter 9, "Enterprise Services Security."
Enable role-based access checking	Refer to Configuring Security within Chapter 9, "Enterprise Services Security."
Add a single Enterprise Services (COM+) role to the application called (for example Trusted Web Service)	Full end-user authorization is performed by the Web-based application. The Web service (and serviced components) only allows access to members of the Trusted Web Service role.
Add the local ASP.NET process identity account to the Trusted Web Service role	Refer to Configuring Security within Chapter 9, "Enterprise Services Security."

Configuring SQL Server

Step	More Information
Create a Windows account on your SQL Server computer that matches the Enterprise Services application account	The user name and password must match your custom Enterprise Services account.
Configure SQL Server for Windows authentication
Create a SQL Server Login for your newly created account	This grants access to the SQL Server.
Create a new database user and map the login name to the database user	This grants access to the specified database.
Create a new user-defined database role and add the database user to the role
Establish database permissions for the database role	Grant minimum permissions For details, see Chapter 12, Data Access Security.

Configuring secure communication

Step	More Information
Configure the Web site for SSL	See How To: Setup SSL on a Web Server in the Reference section of this guide.
Configure SSL between the Web server and application server.	See How To: Call a Web Service Using SSL from ASP.NET 1.1 in the Reference section of this guide.
Configure IPSec between application server and database server	See How To: Use IPSec to Provide Secure Communication Between Two Servers in the Reference section of this guide.

Analysis

• Forms authentication is ideal in this scenario because the users do not have Windows accounts. The Forms login page is used to acquire user credentials. Credential validation must be performed by application code. Any data store can be used. A SQL Server database is the most common solution, although Active Directory provides an alternate credential store.

• The Web-based application is running as the least privileged local account, so potential damage from compromise is mitigated.

• URL authorization on the Web server allows unauthenticated users to browse unrestricted Web pages and forces authentication for restricted pages.

• Because impersonation is not enabled, any local or remote resource access performed by the Web-based application does so using the ASP.NET process identity's security context. ACLs should be configured accordingly.

• User credentials are validated against a custom SQL Server database. Password hashes (with salt) are stored within the database. For more information, see Authenticating Users against a Database in Chapter 12, "Data Access Security."

• Windows authentication to SQL Server means you avoid storing credentials in files on the application server and avoid passing them across the network.

• The use of a duplicated Windows account on the database server (one that matches the Enterprise Services process account) results in increased administration. If a password is changed on one computer, it must be synchronized and updated on all computers. In some scenarios, you may be able to use a least-privileged domain account for easier administration.

• When the Web application calls the Web service, it must configure the Web service proxy using DefaultCredentials (that is, the ASP.NET process account).

  proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
  

  For more information, see Passing Credentials For Authentication to Web Services in Chapter 10, "Web Services Security."

• SSL between the Web server and Web service layer (that fronts the serviced components on the application server) ensures the privacy of the data sent between the two servers.

• The Enterprise Services application is configured for application-level role-based security. The configuration permits only the local ASP.NET process identity (used to run the Web service) to access the serviced components.

• IPSec between the application server and database server ensures the privacy of the data sent to and from the database.

• SSL between browser and Web server protects credentials and bank account details.

Pitfalls

The application must flow the original caller's identity to the database to support auditing requirements. Caller identity may be passed using stored procedure parameters.

Related Scenarios

Forms authentication against Active Directory

The user credentials that are accepted from the Forms login page can be authenticated against various stores. Active Directory is an alternate to using a SQL Server database.

More information

For more information, see How To: Use Forms Authentication with Active Directory in ASP.NET 1.1 in the Reference section of this guide.

For ASP.NET 2.0, see How To: Use Forms Authentication with Active Directory in ASP.NET 2.0.

Using DCOM

Windows 2000 (SP3 or SP2 with QFE 18.1) or Windows Server 2003 allows you to configure Enterprise Services applications to use a static endpoint. If a firewall separates the client from the server, this means that you need to open only two ports in the firewall. Specifically, you must open port 135 for RPC and a port for your Enterprise Services application.

This enhancement to DCOM makes it a valid choice of communication protocol between Web server and application server and removes the requirement to have a Web services layer.

Important   If your application requires distributed transactions to flow between the two servers, DCOM must be used. Transactions cannot flow over SOAP. In the SOAP scenario, transactions must be initiated by the serviced components on the application server.

More information

For more information, see Chapter 9, Enterprise Services Security.

Using .NET Remoting

Remoting can be a valid choice when you don't need services provided by Enterprise Services such as transactions, queued components, object pooling, and so on. .NET Remoting solutions also support network load balancing at the middle tier. Note the following when you use .NET Remoting:

• For ultimate performance, use the TCP channel and host in a Windows service. Note that this channel provides no authentication and authorization mechanism by default. The TCP channel is designed for trusted subsystem scenarios. You can use an IPSec policy to establish a secure channel and to ensure that only the Web server communicates with the application server.
• If you need authentication and authorization checks using IPrincipal objects, you should host the remote objects in ASP.NET and use the HTTP channel. This allows you use the IIS and ASP.NET security features.
• The remote object can connect to the database using Windows authentication and can use the host process identity (either ASP.NET or a Windows service identity).

More information

For more information about .NET Remoting security, see Chapter 11, .NET Remoting Security.

Summary

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

For Intranet and extranet application scenarios, see Chapter 5, "Intranet Security," and Chapter 6, Extranet Security.

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.