Using SharePoint for Extranets

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:

if (location.protocol != ‘https:’)
  window.location = ‘https://’
  + location.host
  + location.pathname
  + location.search;

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.

End of Article

   Previous  1  [2]  Next