Forms Authentication 3 of 3, Soft, Info, SharePoint
[ Pobierz całość w formacie PDF ]
Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...
Strona 1 z 12
©2008 Microsoft Corporation. All rights
reserved.
Forms Authentication in SharePoint Products and Technologies
(Part 3): Forms Authentication vs. Windows Authentication
Summary:
Learn the functional and operational differences between sites that are secured with Windows
authentication and those that are secured with forms authentication. This article is part 3 of 3. (12 printed pages)
Steve Peschka, Microsoft Corporation
December 2007
Applies to:
Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3.0
Contents
z
Introduction to Differences Between Forms Authentication and Windows Authentication
z
Crawling Content
z
Integrating with the 2007 Microsoft Office System
z
Opening Documents in Internet Explorer
z
Checking the "Sign me in automatically" Check Box at Logon
z
Using an HttpModule During Authentication
z
User Profile Imports
z
Resolving Names
z
Using an LDAP Provider
z
Using the Microsoft Single Sign-On Service
z
Conclusion
z
Additional Resources
Read also:
Forms Authentication in SharePoint Products and Technologies (Part 1): Introduction
Forms Authentication in SharePoint Products and Technologies (Part 2): Membership and Role Provider Samples
Introduction to Differences Between Forms Authentication and Windows Authentication
There are several functional and operational differences between sites that are secured with Windows
authentication and those that are secured with forms authentication. The following sections highlight several of
the more important differences that you should be aware of as you plan your implementation.
In addition, there was also at least one pre-SP1 hotfix that was important to forms authentication users when
using Web applications that were deployed into multiple zones. In one issue, alerts were sent out to users who
used the URL from the Default zone for the Web application. If we apply the example from this article series,
that meant that users who accessed the site at
would receive alerts that use the
URL
. Those users would not be able to access the site using that URL. The hotfix for this issue
is rolled up into
Microsoft Windows SharePoint Services 3.0 Service Pack 1 (SP1)
Note:
To take advantage of this hotfix, download and install
Microsoft Windows SharePoint Services 3.0
Service Pack 1 (SP1)
2008-02-22
Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...
Strona 2 z 12
us/office/sharepointserver/bb735839.aspx ] .
Crawling Content
The crawl process for Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services 3.0
content (in this article series, collectively referred to as
SharePoint Products and Technologies
) is designed to
use Windows authentication. When Office SharePoint Server 2007 was released, it was not able to crawl
content that was secured with forms authentication. In Service Pack 1, SharePoint Products and Technologies
include the ability to set special crawl rules that describe cookie-based authentication so those sites can be
crawled. However, it does a simple crawl of the content only, and does not capture security information or the
kind of rich metadata that the crawler can gather when using the native SharePoint protocol handler.
For those reasons, whether or not you have applied Service Pack 1, it is recommended that you crawl
SharePoint sites protected by forms authentication by using the native SharePoint protocol handler. If your
Web application already includes a zone that is secured with Windows authentication, in most cases you can
use that zone for crawling. If your Web application has only a single zone and it is secured with forms
authentication, you need to extend it into a new zone by using Windows authentication to support the native
protocol handler. For more information, see
Prepare to Crawl Host-Named Sites That Use Forms Authentication
7c4b6a4732a51033.mspx?mfr=true ] .
When you extend the Web application into a new zone, remember the following rules:
z
If you are using only Windows SharePoint Services, the Default zone must be secured with Windows
authentication. If the Default zone is secured with forms authentication and a secondary zone uses
Windows authentication, the crawler will not be able to index it.
z
If you are using MOSS 2007, the Default zone can be secured with Windows authentication, but it does
not have to be. You can use forms authentication for the Default zone and extend a separate zone for
Windows authentication. However, you must change the start address in the default content source to the
URL for the Windows authentication zone. When a new Web application is created, a start address is
automatically added that uses the URL for the Default zone. MOSS 2007 gives you the flexibility to
change the values in the list of start addresses, but Windows SharePoint Services does not.
To change the start address
1. Open your browser and navigate to the Shared Services Provider (SSP) Web site.
2. Click the
Search Settings
link.
3. Click the
Content sources and crawl schedules
link.
4. Click the
Local Office SharePoint Server sites
link.
5. In the Edit Content Source page that opens, in the
Start Addresses
section, edit the addresses in the
box.
6. Click
OK
to save your changes.
Integrating with the 2007 Microsoft Office System
MOSS 2007 and Windows SharePoint Services 3.0 users who also have the 2007 Microsoft Office system of
applications installed enjoy a high level of integration between the 2007 Office system and SharePoint Products
and Technologies. Many of those integration features, however, depend on Windows authentication. Without
Windows authentication, some integration points do not work, and others are changed considerably. To help
minimize user confusion, SharePoint Products and Technologies offer a mode in which certain menu items that
require Windows authentication are removed. In the Central Administration Web site, on the Authentication
Provider page, this mode is controlled via the
Enable Client Integration
box.
When you configure a zone to use forms authentication, the
Enable Client Integration
box is cleared by
default. If a zone is configured in this way, the following changes occur in functionality:
z
Support for remote interfaces is turned off. That includes WebDAV, SOAP, and Microsoft Office FrontPage
remote procedure calls (RPC). Some functionality is not available, such as Web folders or the Web
services for accessing content in that site.
z
Some toolbar items no longer appear:
2008-02-22
Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...
Strona 3 z 12
z
New Document
z
Open in Outlook
z
Open In Windows Explorer
z
Export to Spreadsheet
z
Open with Database Program
z
Explorer View option is hidden.
z
Create an Access View option is hidden.
z
In picture libraries, the following functionality is removed:
z
Upload Multiple
z
Edit Picture
z
Download
z
Send To
z
On the Edit Control Block (ECB) menu, the drop-down menu that appears when you click items in
document libraries, the following items are removed:
z
Edit in Word
z
Edit in Excel
z
Edit in PowerPoint
z
Discuss
z
Connect To Outlook
z
In slide libraries the following functionality is removed:
z
Publish Slide
z
Send to PowerPoint
Also, syncing SharePoint data with Microsoft Office Outlook no longer works.
When operating in this mode, users can still work with documents in SharePoint libraries, but they must right-
click items and choose to save a copy to disk. They can then edit and update the document, and then upload it
and check it back in when they are finished editing.
Some organizations might want to use forms authentication, but also require the same level of integration they
get when using Windows authentication. There are a couple of possible workarounds in this scenario, but it is
helpful to examine why this limitation exists.
When a user accesses a page on a site protected by forms authentication, the server looks for a valid
authentication cookie. If no cookie is found, or if the cookie is not valid, the server redirects the browser to the
logon page by using an HTTP 302 status code. At this page, the user is allowed to authenticate by using his or
her credentials. After the credentials are validated, the server creates a valid authentication cookie and sends
it back to the browser, with the originally requested page. The browser keeps the cookie in memory and sends
it back to the server with every subsequent request to that Web server. With each request, the server checks
the validity of the cookie to ensure that it is good (that it has not expired or been tampered with), and then
processes the request.
Because the authentication cookie is in memory with the browser process, it introduces some limitations:
z
The cookie is retained only as long as the browser is open; when the browser is closed the cookie is
destroyed with everything else in memory that the browser was using.
z
The cookie belongs to the browser's application process (such as the .exe file for the browser), and
cannot be shared with other processes. Office system applications run in their own processes, for
2008-02-22
Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...
Strona 4 z 12
example, msword.exe for Microsoft Office Word. As such, a cookie that a user generated when logging
into the site in the browser cannot be shared with Word.
z
Office system applications do not know how to respond to the 302 response sent back from the server.
For example, if you are using forms authentication and have the Enable Client Integration feature turned
on, the
Enable Client Integration
menu includes an
Edit in Word
menu when you select a Word
document. If you click the
Edit in Word
menu, instead of opening the document, Word displays the
forms logon page shown in Figure 1.
Figure 1. Forms logon page
All of the issues described here justify why the Enable Client Integration option was developed: so the end-
user experience would be more uniform and predictable in that environment, though different for users that
are used to SharePoint sites secured with Windows authentication. Even with those restrictions, there are still
a few options that can be used to allow for using forms authentication and yet still provide many or all of the
deep integration points with Office applications that are available when using Windows authentication.
Opening Documents in Internet Explorer
You can configure Internet Explorer so that all links for Office documents in Web sites open directly in the
browser instead of in the native application. When you do this, several Office application menus and toolbars
are merged and displayed with the Internet Explorer menus and toolbars, and the browser hosts the
document, worksheet, or presentation.
By opening the document in Internet Explorer, the browser is able to take advantage of its process having the
authentication cookie that was created at logon. That allows Internet Explorer to open the document and
respond to the authentication prompts without further intervention from the user. The drawback to this
approach is that documents hosted in Internet Explorer do not contain all of the native application's menus and
toolbars, and the interface is different enough that users may find it confusing or limited.
To configure Internet Explorer to open Office documents in the browser, see Knowledge Base article 162059:
How to Configure Internet Explorer to Open Office Documents in the Appropriate Office Program Instead of in
Internet Explorer
Internet Explorer, but you can change the values described to implement the opposite behavior.
Checking the "Sign me in automatically" Check Box at Logon
The forms logon page includes a check box that states to
Sign me in automatically
, and it is cleared by
default. If you select the box at logon, an encrypted authentication cookie is persisted to the local disk on the
2008-02-22
Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...
Strona 5 z 12
computer from which the user is logging on. The user credentials are not stored in the cookie; instead, what is
stored is some encrypted data that identifies the user.
Office system applications look for such an authentication cookie when they receive an authentication prompt.
If one exists, it is sent in response to the authentication request. If the cookie is still valid, meaning it has not
expired, authentication using the cookie succeeds and the document opens in the Office client application
without further intervention from the user.
Some things may still not work quite as expected even with this authentication cookie. For example, Microsoft
Office Outlook uses the
stssync
protocol to synchronize data between Outlook and SharePoint Products and
Technologies. While the authentication cookie is valid, this should still work. However, the authentication
expires by default after 30 minutes; after that time the synchronization with Outlook will stop working until the
user reauthenticates.
A cookie expires based on how old it is; you can change the expiration duration value by adding or updating
the time-out parameter in the forms node in the web.config file. For more information, see
Forms Element for
Authentication (ASP.NET Settings Schema)
(printer).aspx ] .
The drawback to this approach is that if the computer from which the user logged on is compromised or
otherwise not secured at all times, then someone else could log on to that computer and access SharePoint
content by using the context of the user who created the authentication cookie. For that reason, there are very
few situations in which it is safe to deploy in this way.
If you do choose to implement this method, there are a few parameters that you can use to control the cookie.
For example, you can control the following:
z
The cookie
name
z
RequireSSL
to force Secure Sockets Layer (SSL) in order to use cookies
z
SlidingExpiration
to control a cookie's lifetime end event
z
Timeout
to control how long a cookie is valid
Note:
For a complete list of attributes you can use in the
forms
element in the web.config file, see
Forms
Element for Authentication (ASP.NET Settings Schema)
us/library/1d3t3c61(printer).aspx ] .
In Windows Vista, Internet Explorer 7 includes an additional security feature named
protected mode
. By
default, protected mode is enabled for the Internet, Intranet, and Restricted Sites zones. Because this feature
places persistent cookies in a location that prevents sharing across applications, client integration does not
work as intended.
To configure Internet Explorer 7 to work with client integration, do one of the following:
z
Disable protected mode.
z
If protected mode is enabled, add SharePoint sites to the Trusted sites zone in Internet Explorer.
For information about disabling protected mode, see "Configuring Protected Mode" in
Understanding and
Working in Protected Mode Internet Explorer
Using an HttpModule During Authentication
Another option is to write an
HttpModule
that changes the authentication challenge type. For this scenario, the challenge type must change from the
302 redirection response that Internet Information Services (IIS) issues for forms authentication, to a
Windows-style Basic authentication challenge. That allows the user to enter credentials in a dialog box prompt,
which is an approach that Microsoft Office applications can use successfully.
A proof of concept for this approach has been developed by members of the Microsoft Services and SharePoint
Product Group teams. It is available as an unsupported code sample on CodePlex, for use as is. For more
information, see
Forms Based Authentication (FBA)
is included with simple installation instructions.
The drawback to this approach, however, is that it requires users to reenter their credentials each time a
document is opened from the SharePoint site.
2008-02-22
[ Pobierz całość w formacie PDF ]