[Shib-Users] links to sp resources in MS word don't work

122 views
Skip to first unread message

caleb racey

unread,
Oct 30, 2009, 4:44:59 AM10/30/09
to shibbole...@internet2.edu
I was aware that putting links in powerpoint to protected urls on the SP didn't work. It looks like windows fires up some kind of internal IE to process the first bit of the request then hands off to another version once the redirect to the IDP is made, this destroys the redirect chain and the IDP does not know where to send the user back too.

This seems to be now happening in word 2007, are other people encountering the same problem?

Does anyone know if there is any mitigation beyond "don't use word or powerpoint to present urls"

Caleb Racey
Team Leader
Middleware Team
ISS
Newcastle University
U.K.

Niels van Dijk

unread,
Oct 30, 2009, 5:19:07 AM10/30/09
to shibbole...@internet2.edu
Hi Caleb,

Many 'clients' have this problem, and yes it is very common :(

The MS office suite only supports basic/digest authentication in its
'internal webbrowser' and is not able to handle redirection required to
support federated access correctly. As far as I'm aware there is no
quick fix.

Below a memo from Microsoft that may offer a work around. They describe
how to apply a patch to office2007 (see 'On the Client' section) to
better be able to handle this kind of thing when using extended
authentication with their Sharepoint product. In principle it should
also work if you do not use sharepoint, as 'forms based authentication'
in Sharepoint is a ms name for what we would call federated access.

I have not tested it yet, and even if this works, there is currently
only a fix for 0ffice 2007 on XP :(

regards,
Niels

-----------------------

Feed: Microsoft SharePoint Team Blog
Posted on: woensdag 13 mei 2009 15:29
Author: sptblog
Subject: 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:

clip_image002

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:

clip_image004

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:

clip_image006

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

----------

--
Niels van Dijk
Advanced Services

T: +31 302 305 337 / M: +31 651 347 657
SURFnet - PO Box 19035 - NL-3501 DA Utrecht - The Netherlands -

http://www.surfnet.nl
SURFnet grensverleggend netwerk voor hoger onderwijs en onderzoek

Reply all
Reply to author
Forward
0 new messages