Update on SharePoint forms based authentication(FBA) and Office client
Hi folks,
It’s Steve Peschka from the SharePoint Ranger team again. I wanted to update everyone on some changes with the level of support and integration in the Microsoft Office client applications (hereafter referred to simply as “Office”) and SharePoint sites that are secured with forms based authentication (FBA). For those of you who have read part 3 of the FBA whitepapers (http://msdn.microsoft.com/en-us/library/bb977430.aspx), you know that at the time Office and SharePoint 2007 was released, there was not a strong level of integration between the two. In fact, as some of you may have seen, if you had Enable Client Integration turned on for a zone secured with FBA, and then you tried to edit an item in that zone using the Edit in Microsoft Word command from the menu for example, instead of opening the document up, Word actually opened the login page for the site. It resulted in something that looks like this:
For the rest of this blog, I’m going to share with you a sneak of an update to part 3 of the FBA whitepaper that describes changes we’ve made to the Office client to enable much better integration with SharePoint sites secured with FBA. These changes allow Office applications to display whatever forms login page is being used for the site in a pop up dialog box. The Office application renders the HTML from that login page and allows the user to enter credentials. The credentials are sent back to the server and if the server returns a redirect response for the document that was originally requested, the Office application assumes that the identity has been successfully established. It is then able to use the authorization cookie it was given to retrieve the document and any associated metadata, and open the item up.
This approach allows you to use whatever forms authentication login page the site uses – whether it’s the login page that comes with SharePoint, a custom login page, or even a multi-factor login page. Below is an example of what the login dialog looks like when opening an item on a SharePoint site that uses the standard forms login page:
The steps necessary to implement this support are as follows:
On the Client
1. Download the hotfix for KB 960499 from the December 2008 Cumulative Update for the Office client applications; you can find this download at http://support.microsoft.com/kb/960499/. Please note that even though the documentation primarily describes fixes for the InfoPath client, this is the correct patch to enable support in Microsoft Office applications for FBA.
IMPORTANT: This patch can only be used with Office 2007 running on the Windows XP operating system. A patch that enables this support for Office 2007 running on the Windows Vista operating system is available in the April 2009 cumulative update for the Microsoft Office client. It also requires that Service Pack 2 for Vista be applied.
2. Install this patch on each client computer running Windows XP and Office 2007 from which you wish to use the Office client to open documents in an FBA-secured site.
3. Configure the appropriate set of registry values on each client computer to enable the Office client applications to use the FBA integration features. At a minimum, the FormsAuthEnabled value needs to be created and set 1. More details on the registry values, their location and function are described below.
NOTE: If you are using Internet Explorer, these new features require at least version 7.0 or higher.
On the SharePoint Farm
1. Go to Central Administration, click on the Application Management tab, then click on the Authentication Providers link.
2. In the Web Applications drop down, select the web application that contains an FBA zone and then click on the link for the zone that is configured to use FBA.
3. On the settings page for the zone, check the Enable anonymous access checkbox, and change the Enable Client Integration? setting to Yes.
NOTE: Checking the Enable anonymous access checkbox does not, by itself, grant anonymous access to any content in the web application. It is however, necessary to enable the Office client applications to gather enough information about the site to display the login dialog window.
The authentication settings for the web application should appear like this:
Registry Values
There are several registry values that can be used to help control how and when the Office client applications will attempt to use the FBA to authenticate a request. All registry values are stored under the key HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Internet\FormsBasedAuthSettings.
As described above, the FormsAuthEnabled value is required at a minimum for these new features to work. It is a DWORD value and must be set to 1 in order for the Office client to utilize these new FBA features. There are other registry values available for further fine-tuning your implementation that will be explained more fully in the update to the FBA whitepaper. They include settings for things like not allowing cross domain redirects for login, require SSL with the login page, enabling scripts, behaviors, and ActiveX in the login page, etc.
Other Things To Know
There are a few other things to know about the support described here. First, not every Office application will be able to take advantage of these new features. More may come online over time, but for now you should count on the core Office apps (Word, Excel, PowerPoint and Outlook) to support this. Second, adding this feature to the Office client enables some other scenarios that weren’t previously possible. For example, we can also potentially integrate with SharePoint sites secured with ADFS much better than we have previously. After all, ADFS is just FBA with a remote login page. We hope to address the ADFS scenario more specifically in the update to part 3 of the FBA whitepaper, so make sure you download it and take a look when it’s released.
That’s all for this entry, hope you find the information useful.
Steve
