ASP.NET 1.1 - Extranet Exposing a Web Service

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

Applies To

• ASP.NET 1.1
• Web Services (ASMX 1.1)

Scenario

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.

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

Solution

Solution Summary

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.

Partner Application

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.

Web Server

IIS

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

ASP.NET

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

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

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

Related Scenarios

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.