ASP.NET 1.1 - Extranet Exposing a Web Application

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, and Prashant Bansode

Applies To

• ASP.NET 1.1

Scenario

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.

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

Solution

Solution Summary

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.
Communications Security	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.

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

Web Server

IIS

• 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

ASP.NET

• Configure the ASP.NET Web application to use Windows authentication (for IIS Basic). Set the <authentication> element to: <authentication mode="Windows" />

—or—

• Configure ASP.NET to use Forms authentication Edit Web.config in the Web service's virtual root directory. Set the <authentication> element to: <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). 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. Note - When running IIS 6.0 on Windows Server 2003 in process isolation mode, the processModel setting is not used.

AD Server

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

Database Server

• 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. This grants access to the SQL Server. 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.
• 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.

Communications Security

• Configure the Web site on the Web server for SSL.
• Configure IPSec between Web server and database server

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

Note - In ASP.NET 2.0, it is recommended that you use the Membership feature instead.

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

Related Scenarios

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.