Extranet Authentication Options

December, 2006

An increasingly common deployment scenario for SharePoint Products and Technologies is as an extranet environment. Companies looking to extend a web presence beyond the physical boundaries of their network – perhaps to share information and collaborate with partners, clients, and vendors – are turning to SharePoint as a tool to rapidly and economically build Extranets.

However, organizations considering SharePoint face three inescapable business challenges - how to create accounts for external users to whom to distribute responsibility for maintaining the accounts and how to go about disabling the accounts when the time is right.

With the introduction of Microsoft Office SharePoint Server 2007, the level of flexibility in addressing these challenges has increased. SharePoint 2007 introduces several new deployment options. In order to decide which avenue to pursue, organizations must consider several factors specific to their implementation. This month’s Tip of the Month will help sort through the new options, along with their relative strengths and weaknesses.

Windows Authentication

Windows Authentication is the traditional method of authentication for a SharePoint implementation and the only one available out of the box with SharePoint Portal Server 2003. Windows Authentication is based upon Active Directory and is an ideal platform when the end users of the SharePoint implementation are members of the corporate domain. Users already have accounts by virtue of their employment within the enterprise, and the authentication scheme integrates well for users who are logged on directly to the network. With single sign-on settings applied, users are automatically logged on to SharePoint simply by logging onto Windows on their desktops and laptops.

However, when companies start to extend their SharePoint implementation to those outside of their network domain – to partners, vendors, or clients – Windows Authentication by itself is not sufficient.

If utilizing a pure Windows Authentication environment, one additional option to allow for external access – creation of a secondary domain dedicated for external accounts. But the complexities of this approach increase dramatically with the size of the organization and the volume of external accounts needed. Small organizations extending SharePoint to a relatively small user base may see minimal effort in creating manual accounts on the second domain. However, larger organizations, with larger implementations may require a third-party tool – such as one written by Abel Solutions – allowing site administrators to use the SharePoint site administration interface to locate existing accounts, and create new ones on the fly if no account exists.

Forms Authentication

SharePoint 2007 introduces a new option – Forms Authentication – for connecting outside users to their SharePoint environments. With Forms Authentication, rather than logging in by putting credentials in the Windows popup login box, the login takes place in a form on a standard web page.

From a technical standpoint, accounts can be stored in a number of places – a SQL server database or any LDAP-compliant environment.

There are several advantages to a Forms Authentication approach. First, Forms Authentication removes the dependency on Active Directory as an account management tool, making it an alternative choice for organizations using other network management tools. Second, it allows companies to authenticate against two or more difference identity management systems when creating partner applications. Finally, Forms authentication – by virtue of having a display page that users can see prior to logging in – provides a more elegant road map towards creating familiar “Forgot Your Password” functionality. While it would still require custom code to implement end user password management features, having a login page makes the interface easier for the end user to take advantage of.

However, Forms Authentication is not without its disadvantages as well. First, Forms Authentication does require some custom code in adding in the aforementioned "Forgot Your Password" functionality. Second, Forms Authentication creates issues with SharePoint’s built-in client application integration. As a result, the client integration features of SharePoint can be disabled when using Forms Authentication. When these features are disabled, one of the limitations is that users will have to download files to their desktops first, rather than opening them directly from the portal. This would also prevent them from using the built-in links from various lists - such as Tasks and Contacts lists - to Outlook.

Web Single Sign-On

A third approach, available with WSS V3 and MOSS 2007 is Web Single Sign-On. Web Single Sign-On allows organizations to implement SharePoint in an environment that uses federated authentication to secure identities across organizations and security environments. Under this approach, companies would establish trust relationships between their network domain and that of their partners.

While Web Single Sign-On can be implemented with a number of different Single Sign-On (SSO) providers, one such provider is Active Directory Federated Services (ADFS). ADFS is an SSO that works specifically with other Active Directory domains. It is a viable solution when both the company implementing SharePoint and the partner companies to which they are extending it are running Active Directory environments.

One major downside with this approach is the relative level of complexity involved with establishing trust relationships between two organizations. Because of the amount of up-front work required for each partner organization, this is an approach that companies should consider only if they want to extend their Intranet to a large number of end users associated with a relatively small number of partner companies and organizations.