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

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)

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

ASP.NET on the Web server is running as a least privileged local account (the default ASPNET account), so 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.

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

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.

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

ASP.NET on the Web server is running as a least privileged local account (the default ASPNET account), so 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 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.

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.

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.

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.