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

Makale
07/14/2010

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.

Extranet 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 extranet 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. (14 printed pages)

Exposing a Web Service
Exposing a Web Application
Summary

Extranet applications are those that share resources or applications across two different companies or divisions. The applications and resources are exposed over the Internet. One of the main challenges associated with extranet applications is developing an authentication approach that both parties agree to. Your choices may be limited in this respect because you may need to interoperate with existing authentication mechanisms.

Extranet applications generally share some common characteristics:

You have tighter control over user accounts, compared to Internet scenarios.
You may have a higher level of trust for the user accounts, compared to applications that have Internet users.

The scenarios presented in this chapter that are used to illustrate recommended authentication, authorization, and secure communication techniques include:

Exposing a Web Service
Exposing a Web Application

Exposing a Web Service

Consider a business-to-business partner exchange scenario where a publisher company publishes and sells its services over the Internet. It exposes information to selected partner companies using a Web service. Users within each partner company access the Web service using an Intranet-based internal Web application. This scenario is shown in Figure 6.1.

Ff649347.f06sn01(en-us,PandP.10).gif

Figure 6.1. Extranet Web service business-to-business partner exchange

Characteristics

This scenario has the following characteristics:

The publisher company exposes a Web service over the Internet.
Partner company (not individual user) credentials (X.509 client certificates) are validated by the publisher to authorize access to resources. The publisher does not need to know about the user's individual logins in the partner company.
Client certificates are mapped to Active Directory® directory service accounts within the publisher company.
The extranet contains a separate Active Directory from the (internal) corporate Active Directory. The extranet Active Directory is in a separate forest, which provides a separate trust boundary.
Web service authorization is based on the mapped Active Directory account. You can use separate authorization decisions based on partner company identity (represented by separate Active Directory accounts per company).
The database is accessed by a single trusted connection that corresponds to the ASP.NET Web service process identity.
The data retrieved from the Web service is sensitive and must be secured while in transit (internally within the publisher company and externally while flowing over the Internet).

Secure the Scenario

In this scenario, each partner company's internal Web application retrieves data from the publisher company through the Web service and then presents the retrieved data to its users. The publisher requires a secure mechanism to authenticate partner companies, although the identity of individual users within partner companies is not relevant.

Due to the sensitive nature of the data sent between the two companies over the Internet, it must be secured using SSL while in transit.

A firewall that permits only inbound connections from the IP address of extranet partner companies is used to prevent other unauthorized Internet users from opening network connections to the Web service server.

Table 6.1. Security measures

Category	Detail
Authentication	Partner applications use client certificates with each request to the Web service. Client certificates from partner companies are mapped to individual Active Directory accounts. Microsoft® Windows® authentication is used at the database. The ASP.NET Web service process identity is used to connect. The database trusts the Web service.
Authorization	The Web service uses .NET role-based authorization to check that authenticated Active Directory accounts are members of a Partner group.
Secure Communication	SSL is used to secure the communication between the partner Web application and publisher's Web service. IPSec is used to secure all communication between the Web service and the database.

Authentication

Partner applications use client certificates with each request to the Web service.

Client certificates from partner companies are mapped to individual Active Directory accounts.

Microsoft® Windows® authentication is used at the database. The ASP.NET Web service process identity is used to connect. The database trusts the Web service.

Authorization

The Web service uses .NET role-based authorization to check that authenticated Active Directory accounts are members of a Partner group.

Secure Communication

SSL is used to secure the communication between the partner Web application and publisher's Web service.

IPSec is used to secure all communication between the Web service and the database.

The Result

Figure 6.2 shows the recommended security configuration for this scenario.

Ff649347.f06sn02(en-us,PandP.10).gif

Figure 6.2. The recommended security configuration for the Web service business-to-business partner exchange 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 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 IPSec through firewalls (see article Q233256, How to Enable IPSec Traffic Through a Firewall, in the Microsoft Knowledge Base).
Calling a Web service using SSL (see How To: Call a Web Service Using SSL in ASP.NET 1.1 in the Reference section of this guide); this solution technique is required within the partner company
The discussion of certificate management and the infrastructure is beyond the scope of this topic, for more information search for Certificates and Authenticode on Microsoft TechNet.

Configuring the partner application

This chapter does not go into details about the partner application and its security configuration. However, the following points needs to be considered to facilitate communication between the partner application and Web service:

The partner company's Web application can choose an authentication mechanism that allows it to authenticate and authorize its internal users. Those users are not passed to the Web service for further authentication.
The partner company's Web application makes calls on behalf of its user to the Web service. Users cannot directly call the Web service.
The partner company's Web application uses a client certificate to prove its identity to the Web service.
If the partner application is an ASP.NET Web application, then it must use an intermediate out of process component (an Enterprise Services application or Windows service) to load the certificate and forward it to the Web service.

For more information about why this is necessary and the steps to achieve this, see How To Call a Web Service Using Client Certificates from ASP.NET in the Reference section of this guide.

Configuring the extranet Web server

Step

More Information

Disable Anonymous access for the Web service's virtual root directory.

Enable certificate Authentication for your Web application's and Web service's virtual root.

To work with Internet Information Services (IIS) authentication settings, use the IIS Microsoft Management Console (MMC) snap-in. Select your application's virtual directory, right-click, 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.

See How To: Set Up SSL on a Web Server in the Reference section of this guide.

See How To: Call a Web Service Using Client Certificates from ASP.NET in the Reference section of this guide.

Configure Active Directory (Extranet)
Step	More Information
Set up Active Directory accounts to represent partner companies.	A separate extranet Active Directory is used. This is located in its own forest, and is completely separate from the corporate Active Directory.
Configure certificate mapping.	See the Step-by-Step Guide to Mapping Certificates to User Accounts on Microsoft TechNet. Also see article Q313070, HOW TO: Configure Client Certificate Mappings in Internet Information Services (IIS) 5.0, in the Microsoft Knowledge Base.

Configure ASP.NET (Web service)

Step More Information

Configure the ASP.NET Web service to use Windows authentication.

Edit Web.config in the Web service's virtual root directory
Set the <authentication> element to:

<authentication mode="Windows" />

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 username 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 username and password attributes on the <processModel> element

Default

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

Becomes

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

Note When 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.

Configuring SQL Server

Step	More Information
Create a Windows account on the computer running Microsoft SQL Server™ that matches the ASP.NET process account used to run the Web service (by default, this is ASPNET.)	The user name and password must match your ASP.NET process account. Give the account the following privileges: Access this computer from the network Deny logon locally Log on as a batch job 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 the newly created Windows 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 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 within the database and place the database user into the role.
Establish database permissions for the database role.	Grant minimum permissions See Chapter 12, Data Access Security.

Configuring secure communication

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

Analysis

Because ASP.NET on the Web server is running as a least privileged local account, potential damage from compromise is mitigated.
The ASP.NET Web applications within the partner companies use Windows Integrated authentication and perform authorization to determine who can access the Web service.
The ASP.NET Web application within the partner company uses an intermediate Enterprise Services application to retrieve client certificates and make calls to the Web service.
The publisher company uses the partner organization name (contained in the certificate) to perform certificate mapping within IIS.
The Web service uses the mapped Active Directory account to perform authorization, using PrincipalPermission demands and .NET role checks.

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

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 internal network to the SQL Server computer. If you use SQL authentication, it is important to secure the connection string (containing a user name and password) within the application and as it is passed across the network. Use DPAPI or one of the alternative secure storage strategies discussed in Chapter 12, Data Access Security, to store connection strings and use IPSec to protect the connection string (and sensitive application data) as it is passed between the Web service and database.
SSL between partner companies and Web service protects the data passed across the Internet.
IPSec between the Web service and database protects the data passed to and from the database on the corporate network. In some scenarios where the partner and publisher communicate over a private network, it may be possible to use IPSec for machine authentication in addition to secure communication.

Pitfalls

The use of a duplicated local Windows account on the database server (one that matches the ASP.NET process account local to IIS) results in increased administration. Passwords must 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. In this scenario, Active Directory accounts must be a member of a Partner group.

Q&A

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

Audit end user (partner company) activity within the Web service. Pass the partner company identity at the application level to the database using stored procedure parameters.

The publisher company might publish non-sensitive data such as soft copies of magazines, newspapers, and so on. In this scenario, the publisher can provide a unique username and password for each partner to connect with to retrieve the data from the Web service.

In this related scenario, the publisher's Web site is configured to authenticate users with Basic authentication. The partner application uses the username and password to explicitly set the credentials for the Web service proxy.

More information

For more information about configuring Web service proxies, see Chapter 10, Web Services Security.

Exposing a Web Application

In this scenario the publisher company gives its partners exclusive access to its application over the Internet and provides a partner-portal application; for example, to sell services, keep partners updated with product information, and provide online collaboration and so on. This scenario is shown in Figure 6.3.

Ff649347.f06sn03(en-us,PandP.10).gif

Figure 6.3. Partner portal scenario

Scenario Characteristics

This scenario has the following characteristics:

The partner Web application accepts credentials either by using a Forms login page or it presents a login dialog using Basic authentication in IIS.
The credentials are validated against a separate Active Directory within the extranet perimeter network (also known as DMZ, demilitarized zone, and screened subnet). The extranet Active Directory is in a separate forest, which provides a separate trust boundary.
The database is accessed by a single trusted connection that corresponds to the ASP.NET Web application process identity.
Web application authorization is based on either a GenericPrincipal object (created as part of the Forms authentication process) or a WindowsPrincipal object (if Basic authentication is used).
The data retrieved from the Web application is sensitive and must be secured while in transit (internally within the publisher company and externally while flowing over the Internet).

Secure the Scenario

Due to the sensitive nature of the data sent between the two companies over the Internet, it must be secured using SSL while in transit.

A firewall that permits only inbound connections from the IP address of extranet partner companies is used to prevent other unauthorized Internet users from opening network connections to the Web server.

Table 6.2. Security measures

Category	Detail
Authentication	Users within partner companies are authenticated by the Web application using either Basic or Forms authentication against the extranet Active Directory. Windows authentication is used at the database. The ASP.NET Web application process identity is used to connect. The database trusts the Web application.
Authorization	The Web application uses .NET role-based authorization to verify that the authenticated user is a member of a Partner group.
Secure Communication	SSL is used to secure the communication between the partner Web browser and publisher's Web application. IPSec is used to secure all communication between the Web application and the database.

The Result

Figure 6.4 shows the recommended security configuration for this scenario.

Ff649347.f06sn04(en-us,PandP.10).gif

Figure 6.4. The recommended security configuration for the partner portal scenario

Configuring the extranet Web server

Configure IIS
Step	More Information
To use Forms authentication, enable Anonymous access for the Web application's virtual root directory —or— To use Basic authentication, disable Anonymous access and select Basic authentication

Configure Active Directory (Extranet)
Step	More Information
Set up Active Directory accounts to represent partner users	A separate extranet Active Directory is used. This is located in its own forest and is completely separate from the corporate Active Directory.

Configure ASP.NET

Step More Information

Configure the ASP.NET Web application to use Windows authentication (for IIS Basic)
—or—
Configure ASP.NET to use Forms authentication

Edit Web.config in the Web service's virtual root directory

Set the <authentication> element to either:

<authentication mode="Windows" />

—or—
<authentication mode="Forms" />

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 enable 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 username and password attributes on the <processModel> element
Default

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

Becomes

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

Note When 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.

Configuring SQL Server

Step	More Information
Create a Windows account on the SQL Server computer that matches the ASP.NET process account used to run the Web service	The user name and password must match your ASP.NET process account. Give the account the following privileges: Access this computer from the network Deny logon locally Log on as a batch job 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 the 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 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 within the database and place the database user into the role
Establish database permissions for the database role	Grant minimum permissions See Chapter 12, Data Access Security.

Configuring secure communication

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

Analysis

Because ASP.NET on the Web server is running as a least privileged local account, potential damage from compromise is mitigated.
SSL is used between browser and Web application to protect the Forms or Basic authentication credentials (both passed in clear text, although Basic uses Base64 encoding). SSL also protects the application-specific data returned from the Web application.
For Forms authentication, SSL is used on all secured pages (not just the logon page) to protect the authentication cookie passed on all subsequent Web requests after the initial authentication.
If SSL is used only on the initial logon page to encrypt the credentials passed for authentication, you should ensure that the Forms authentication ticket (contained within a cookie) is protected, because it is passed between client and server on each subsequent Web request. To encrypt the Forms authentication ticket, configure the protection attribute of the <forms> element as shown below and use the Encrypt method of the FormsAuthentication class to encrypt the ticket.
```
<authentication mode="Forms">
  <forms name="MyAppFormsAuth"
       loginUrl="login.aspx"
       protection="All"
       timeout="20" 
       path="/" >
  </forms>
</authentication>
```
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);
```
For more information about Forms authentication and ticket encryption, see Chapter 8, ASP.NET Security.

Note In ASP.NET 2.0, it is recommended that you use the Membership feature instead. For more information on using the Membership feature in ASP.NET 2.0, see "How To: Use Membership in ASP.NET 2.0."
Similarly, SSL is used on all pages for Basic authentication because the Basic credentials are passed on all Web page requests and not just the initial one where the Basic credentials are supplied by the user.
For Basic authentication, ASP.NET automatically creates a WindowsPrincipal object to represent the authenticated caller and associates it with the current Web request (HttpContext.User) where it is used by .NET authorization including PrincipalPermission demands and .NET roles.
For Forms authentication, you must develop code to validate the supplied credentials against Active Directory and construct a GenericPrincipal to represent the authenticated user.

Note If you are running ASP.NET 2.0, you can use the Membership feature with ActiveDirectoryMembershipProvider, which will do this for you. You do not need to write any custom code. For more information see "How To: Use Forms Authentication with Active Directory in ASP.NET 2.0."
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 internal network to the SQL Server computer.
IPSec between the Web service and database protects the data passed to and from the database on the corporate network.

Pitfalls

The use of a duplicated local Windows account on the database server (one that matches the ASP.NET process account local to IIS) results in increased administration. Passwords must be manually updated and synchronized on a periodic basis.
Basic authentication results in a pop-up dialog within the browser. To provide a more seamless logon experience, use Forms authentication.

No connectivity from extranet to corporate network

For additional security, the extranet application can be built to require no connectivity back into the corporate network. In this scenario:

A separate SQL Server database is located in the extranet and replication of data occurs from the internal database to the extranet database.
Routers are used to refuse connections from the extranet to the corporate network. Connections can be established the other way using specific high ports.
Connections from the corporate network to the extranet should always be performed through a dedicated server that has strong auditing and logging and through which users must authenticate before accessing the extranet.

More information

See the following Microsoft TechNet articles:
- Deploying SharePoint Portal Server in an Extranet Environment
For more information about using Forms authentication with Active Directory, see How To: Use Forms Authentication with Active Directory in ASP.NET 1.1 in the Reference section of this guide.

Summary

This chapter has described how to secure two common extranet application scenarios.

For intranet and Internet application scenarios, see Chapter 5, Intranet Security, and Chapter 7, Internet 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.

Aracılığıyla paylaş

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

Extranet Security

Contents

Exposing a Web Service

Characteristics

Secure the Scenario

The Result

Security Configuration Steps

Configuring the partner application

Configuring the extranet Web server

Configuring SQL Server

Configuring secure communication

Analysis

Pitfalls

Q&A

More information

Exposing a Web Application

Scenario Characteristics

Secure the Scenario

The Result

Configuring the extranet Web server

Configuring SQL Server

Configuring secure communication

Analysis

Pitfalls

More information

Summary

Ek kaynaklar

Aracılığıyla paylaş

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

Extranet Security

Contents

Exposing a Web Service

Characteristics

Secure the Scenario

The Result

Security Configuration Steps

Configuring the partner application

Configuring the extranet Web server

Configuring SQL Server

Configuring secure communication

Analysis

Pitfalls

Q&A

Related scenarios

More information

Exposing a Web Application

Scenario Characteristics

Secure the Scenario

The Result

Configuring the extranet Web server

Configuring SQL Server

Configuring secure communication

Analysis

Pitfalls

Related scenarios

More information

Summary

Ek kaynaklar