Using SharePoint for Extranets - 27 Aug 2008

I recently finished an extranet system implementation using Windows SharePoint Services (WSS) 3.0. In this overview of my experiences and guidance, I outline the benefits of using SharePoint for your extranet solution, describe extranet topology and taxonomy, explain the available authentication methods, and offer recommendations for extranets that span several disciplines.

Extranets
An extranet is a network typically used to exchange information between someone in your company and a client, customer, or business partner. It’s an extension of a company’s intranet, but not as public as its public website. Because of this, a company most likely has multiple extranets—one for each client, customer, or partner.

When designing an extranet solution, you usually desire a similar set of requirements. An example of a prioritized list of requirements might include the following:

• Security
• Ease of use
• Document management
• Searching
• Change notification
• Lists (calendar of events, contacts, tasks or other custom data)

Ten years ago, a company that wanted an extranet solution would need to build one from scratch or hire a consultant to customize a product that did something similar to what the company required. Since then, extranets have become so popular that hosted extranet solutions have emerged to satisfy the demand.

During the past few years, SharePoint has emerged as one of the top extranet solutions that companies are considering. SharePoint is not only a collaboration website, but a framework that developers can use to build entire applications. Out of the box, SharePoint includes document management, search, change notification, and list functionality while maintaining a high ease of use through its UI customization options. To finish out our requirements list, all SharePoint content is stored within a SQL Server database, so security can be well-controlled.

Although I used WSS 3.0 for my extranet, you could also use Microsoft Office Share- Point Server (MOSS) 2007. For a discussion about which platform is best suited for your situation, see the sidebar “SharePoint Extranets: WSS or MOSS?”.

Extranet Topology
Because SharePoint is an ASP.NET 2.0 web application, it supports any external-facing topology that web applications support. The best practice is to host SharePoint within the demilitarized zone (DMZ) and use Microsoft ISA Server as an applicationlevel firewall. For more details about the different topologies and architectures, read Microsoft’s extranet topology guidance at technet.microsoft.com/en-us/library/cc263513.aspx.

Extranet Taxonomy
At the highest level, SharePoint organizes itself as a collection of web applications. A web application can have multiple site collections that each contain multiple sites. Because of the time it takes for configuration, you don’t create a new web application in SharePoint each time you need to provision an extranet. Therefore, the SharePoint object that best maps to an extranet is a site collection. A single web application can contain as many as 50,000 site collections before performance begins to degrade. Figure 1 shows an example of a basic taxonomy.

SharePoint organizes information in site collections into a set of content databases. See the web-exclusive sidebar “Content Databases for Extranets” (www.windowsitpro.com, InstantDoc ID 99654) for more information and recommendations regarding content databases.

Authentication
When determining how to authenticate users in SharePoint, you have more options in WSS 3.0 than ever before, thanks mostly to ASP.NET 2.0’s membership provider API. Each web application supports as many as five different authentication methods (or providers) through the use of a feature called zones. Each time a new authentication provider is added to a web application, a new website is created for that zone in Microsoft IIS. Table 1 lists the zones for an extranet web application. Even though the site address is different between zones, SharePoint will resolve both requests to the same web application.

SharePoint also allows port numbers for zone identification, as Table 2 shows, but this is not typically recommended for extranets since firewalls usually only allow web traffic ports such as 80 and 443. Also, some features of SharePoint might not behave as intended on a custom port over the internet.

Web Figure 1 shows the Zone name options displayed on the Extend an Existing Web Application page. Zone names suggest a specific usage, but it’s only for administrative convenience. When extending an existing web application to a new zone, the name you choose doesn’t matter.

You have three options for web authentication: Windows, ASP.NET Forms, or web single sign-on (SSO). The following discussion outlines these authentication types to help you determine which one is best for your specific requirements.

Windows authentication. In WSS 2.0, Windows authentication was the only authentication option. Even though the authentication system has been drastically improved in WSS 3.0, Windows authentication is still the only choice that offers all SharePoint features and enhanced client integration out of the box. Although features such as support for WWW Distributed Authoring and Versioning (WebDAV) and Microsoft Office integration might not be your highest priority, they’re very convenient in some circumstances.

Continue to page 2

In organizations that use Active Directory (AD), Windows authentication is the most popular choice for internal users. It allows them to access extranets without having to sign in if they use their browser’s integrated Windows authentication feature. In Microsoft Internet Explorer (IE), you can configure this feature by including the address in the Local Intranet sites list.

ASP.NET forms-based authentication. Historically, users behind proxy servers have had difficulty accessing a website that requires Windows authentication. Therefore, one of the authentication options in WSS 3.0 is ASP.NET Forms, or forms-based authentication (FBA). FBA is the same authentication provider model included with ASP.NET 2.0. It presents the user with a web page (form) containing a text box for the username and password. FBA is extensible, letting you use any authentication and authorization method you require, provided you write a custom provider. Because writing an authentication provider is time consuming and a major project in itself, some providers are offered out of the box. ASP.NET includes a provider for SQL Server databases, and MOSS adds one for LDAP (such as AD or Active Directory Application Mode—ADAM). If you plan to use ADAM with WSS, you should consider using the External Collaboration Toolkit solution accelerator, which includes a provider for ADAM. You can download the toolkit at www.microsoft.com/downloads/details.aspx?FamilyId=D9AF2C25-989C-45C4-8008-1F15722190ED&displaylang=en. FBA does have some caveats, however. See the sidebar “FBA: the Downside” to find out what you should know before selecting FBA as your authentication method.

Web SSO authentication. Web SSO authentication involves setting up a domain trust over the Internet with another company, such as a business partner. This method uses Active Directory Federation Services (ADFS), but it can also accept SAML 1.1 tokens from other identity management systems that implement the WS-Federation specification. By trusting an organization through Web SSO, you can leave the tasks of provisioning and deactivating accounts to your Web SSO partners.

Zone Address Consolidation
Most extranet zone configurations in the documentation and articles I’ve read appear similar to those in Table 1. The assumption about this configuration is that you’ll authenticate internal users using Windows via an intranetlike address and authenticate external users using FBA via an Internet-like address. This configuration can create confusion for users, both internal and external, during collaboration. It would be more intuitive to have a single website address for both internal and external users. However, SharePoint doesn’t offer an easy way to configure multiple zones that use the same host header. To set this up, you’ll need to use IIS.

IIS won’t host two websites with the same host name on the same port unless the request originates from different IP addresses. To enable this behavior for Share- Point, first assign multiple IP addresses to your web server. Then, open each website and assign it to a different IP address.

SharePoint doesn’t provide an option to specify an IP address when creating or extending a web application. The workaround is to enter a random port number along with the common host name on the Extend an Existing Web Application page. After the site is created, change the port back to 80 and set up your IP address binding.

SSL
The ability of Secure Sockets Layer (SSL) to protect sensitive data over the Internet makes it a must-have for extranets. Ideally, an SSL connection should be forced for external users, but for performance reasons, optional for users already logged on to the local network. To make sure SharePoint will serve up requests for an SSL-protected site, you need to create an HTTP Secure (https) alternate access mapping (AAM) entry. Setting up an SSL certificate in IIS for a SharePoint website is no different than for any other IIS website.

Now that I’ve made my case for consolidated zone addressing, how would this work with SSL? Let’s imagine a hypothetical collaboration case. An internal employee accesses the extranet from within the company via Windows authentication without SSL. The employee creates a document and emails an external user a shortcut to the document. Because the internal user isn’t required to use SSL, the link might look like this: http://extranet.company.com/sites/xyzco/documents/doc1.doc. Because the external user can’t access the website without an encrypted (i.e., SSL) connection to the web server, clicking this link would return an error message. The web server intercepts the error and tries to correct the link by changing its prefix to https instead of http (e.g., https://extranet.company.com/sites/xyzco/documents/doc1.doc). The request is then processed, and the document is downloaded. You can implement this automatic redirection for SharePoint by taking the following steps in IIS:

1. Right-click the website and choose Properties. Click the Directory Security tab. Click Edit under the Secure Communications section and select the Require secure channel (SSL) check box as Figure 2 shows. This will reject non-encrypted traffic and provide an HTTP 403.4 (Forbidden. SSL required) error message.

2. Replace IIS’s 403-4 error page with one that redirects all “http” requests to “https”. One way to do this is to add the following JavaScript code to the 403-4.htm error page:

Alternatively, you could avoid setting up two zones and simply use Windows authentication for internal and external users. This would mean you currently have only one website in IIS, and this setting would force internal and external users to use SSL. Because IIS can’t discern whether a user is internal or external, you’ll need to create another website if you want this behavior. You’ll still need to extend the web application to another zone even if it uses the same authentication provider.

To put it all together, consider the extranet web application’s zone configuration example in Table 3. This configuration uses three IP addresses on the web server to assign requests to specific zones. In IIS, the websites would look like those in Web Figure 2.

The only remaining challenge is to make sure the right IP address is used for each website. Because your company manages its DNS, you can assign the extranet’s site address to the IP address that IIS is using for the internal authentication provider. Also controlled within your company’s environment is how the external DNS entry (and external IP address) is mapped to an internal IP address (For example, a firewall translates an external IP address into a specific internal IP address that’s different from the one your internal DNS uses.) Finally, business partners that use Web SSO will need to add a new forward lookup DNS zone in their environment to override the default public DNS entry. Keep in mind that if you plan to provide multiple externally facing zones that share the same site address, you’ll need a separate public IP address for each one that points to your web server.

Extranets Made Easier
Extranets are complicated, and what I’ve outlined is definitely a simplistic solution and shouldn’t be considered the ideal extranet solution for every situation. Based on my experience with SharePoint for this implementation and seeing what the platform is capable of, I believe that SharePoint will continue to grow in popularity and maturity as an extranet solution.