Implementing Persistent Cookies in Sharepoint 2010 Products

Implementing Persistent Cookies in SharePoint 2010 ProductsJuly 2012

Implementing Persistent Cookies in SharePoint 2010 Products

This document is provided "as-is". Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

Implementing Persistent Cookies in SharePoint Products

Microsoft Corporation

July 2012

Applies to:Microsoft SharePoint® Server® 2010, SharePoint®Foundation® 2010, and Active Directory® Federation Services

Summary: This paper describes best practices and scenario requirements forimplementing persistent cookies or session cookies within your organization when using Microsoft SharePoint® Products.

Authors and Contributors

Bassem Yacoube, Senior Consultant II, Microsoft Corporation

Steve Peschka, Principal Consultant, Microsoft Corporation

Contents

Overview of SharePoint 2010 persistent cookies

Session cookies

Persistent cookies

SharePoint authentication cookies

Integrating with the Microsoft Office System

Workarounds to use with session cookies

Overview of SharePoint 2010 persistent cookies

A cookie is a small text file that a web site issuestohelp identify you to that web site. Cookies are used to maintain state information as you navigate to different pages on a web site or return to the web site at a later time. Cookies are either stored in memory (session cookies) or on your hard disk (persistent cookies).

Session cookies

Session cookies are used to store state information within a session. A browser temporarily cachessessioncookies while a user is visiting the web sitethat issuesthe session cookie. Session cookies are deleted from the cache when the user closes the browser.

Persistent cookies

Persistent cookies are stored for a specified amount of time that is set by the web server that hosts the web site when the web server passes the cookie to the browser. Persistent cookies are used to store state information between visits to a web site.

Persistent cookies outlast browser sessions. If a persistent cookie has its lifetime set to one year, the initial value set in that cookie is sent back to the server every time the user visits the sitewithin that year. This functionality can be used to record a vital piece of information such as how the user initially accessed the website. Because of this aspect of persistent cookie functionality, persistent cookies are also called tracking cookies.

SharePoint authentication cookies

SharePoint supports both session cookies and persistent cookies. After a SharePoint site validates a user's credentials, the web server creates a valid authentication cookie and sends it to the browser with the originally requested page. By default, SharePoint sitesissuepersistent cookies.

All applications that use the same cookie store share the persistent cookie, andthe cookie enables users to open documents in those applications without enteringuser credentials again.SharePoint sites create persistent cookies with a defaulttime-out value of 10 hoursfor sites that use Windows claims or forms-based authentication claims. For SAML claims, SharePoint 2010 Products do not have a default time-out value. When the cookie expires, client integration stops working. At that point, if a user who is working on a document tries to savethe document, the user has to provide credentials again. If a browser is being used to access the document, usersmight beprompted to re-enter their credentials.

If a SharePoint site is configured to use session cookiesinstead of persistent cookies, the browser keeps the cookie in memory.Because session cookiesarestored in memory within the browser process, there are some inherent limitations when you use session cookies, including:

The session cookie is retained only as long as the browser is open. When the browser is closed, the cookie is destroyed along with everything else in memory that the browser was using.
The session cookie belongs to the browser's application process and cannot be shared with other processes. Office system applications run in their own processes. Because of this, a session cookie that a user generates when using a browser to log on to a web site cannot be shared with Microsoft Word, for example.

A SharePoint on-premise authentication cookie storesthe followingattributes:

User Key
User Name
Expiry Date/Time
Is the Cookie Persistent
Audience Uri
Crypto Signature

A SharePoint online authentication cookie storesthe followingattributes:

User Key
User Name
Expiry Date/Time
Is the Cookie Persistent
Audience Uri
Is the cookie for a smart client
Crypto Signature

Using persistent cookies with SharePoint 2010 Products provides extended functionality by supporting integration with the Microsoft Office system and enabling features such as:

Open in Outlook
Export to Spreadsheet

Within SharePoint document libraries, persistent cookies enable features such as:

Edit in Word
Edit in Excel
Edit in PowerPoint
Connect To Outlook

Using persistent cookies with SharePoint 2010 Products also enables the following enhancements:

If applications are using the same cookie store, multiple logon prompts are prevented.
Forms and sessions will continue to persist.

In some scenarios, session cookies might be preferred for security reasons. To configurea SharePoint site to issue session cookies,usethe following Windows PowerShell example:

Windows PowerShell Command

Add-PSSnapin "Microsoft.SharePoint.PowerShell"
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
Iisreset

Integrating with the Microsoft Office System

SharePoint users who also have the Microsoft Office system applications installed experience a high level of integration between the two products.However, many of these integration features depend on persistent cookies. Without persistent cookies, some integration functionality does not work.

Features that requirepersistent cookies:

Open in Explorer.
Connect to Outlook.
Connect to Office.Without persistent cookies, the SharePoint site folder on the file system will not be populated.
Processes that have not implemented the Microsoft Office Forms Based Authentication Protocol(MSOFBA) - the protocol that is used to establish a user’s identity with a remote protocol server.

MSOFBA uses an HTML form to establish a user’s identity,without whichbrowser access and representational state transfer (REST) calls to SharePointsites are not possible. Office client applications (for example, Word and Excel) implement MSOFBA. For more information, see [MS-OFBA]: Office Forms Based Authentication Protocol Specification(

Any background job, for example a job that requires a login but cannotrequest credentials.

Workarounds to use with session cookies

As described, certain features only work with persistent cookies. If you use session cookies,SharePoint users who try to access ribbon buttons or menus that require persistent cookies might encounter errors. To reduce user confusion about these issues, you can use workarounds to disable the features that are not available. One option is to disableclient integration. Another option is to disable the display of ribbon components. If you disableclient integration,users will lose functionality beyond the scope of the limitations imposed by using session cookies. For example, New Document functionality is supported if a SharePoint site is configured to use session cookies but is not supported if client integration is disabled. Therefore, disabling specific ribbon buttons or menus might be preferable to disabling client integration.

Disabling Client Integration

One way to disable features that won’t work when persistent cookies are not used is to disable client integration. In the Central Administration web site, on the Authentication Provider page, you can disable client integration by clearing the Enable Client Integrationcheck box.

If the Enable Client Integrationcheck box is cleared, the following functionality changes occur:

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.
Some toolbar items are no longer displayed, including:
New Document
Open in Outlook
Open In Windows Explorer
Export to Spreadsheet
Open with Database Program
The Explorer View option is hidden.
The Create an Access View option is hidden.
In picture libraries, the following functionality is removed:
Upload Multiple
Edit Picture
Download
Send To
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:
Edit in Word
Edit in Excel
Edit in PowerPoint
Discuss
Connect To Outlook
In slide libraries the following functionality is removed:
Publish Slide
Send to PowerPoint

Also, syncing SharePoint data with Microsoft Office Outlook no longer works.

When operating in this mode, users who work with documents in SharePoint libraries must right-click items and choose to save a copy to disk. They can then edit and update the document, and upload it and check it back in when they are finished editing.

Disabling ribbon options

The KB article, How to restrict SharePoint users from opening Document Libraries using "Open in Windows Explorer" option ( describes how to disable the option that allows users to open aSharePoint document library folder in Windows Explorer. The KB article also describes how to remove the "Connect to Outlook" option. For sites that have already been created, a script similar to the one shown in the following example will deactivate those options.

After installing the feature, as described in the following article: Install-SPFeature( use the following Windows PowerShell command example to activate this feature on all existing sites under a specific URL:

Windows PowerShell Command

Add-PSSnapin "Microsoft.SharePoint.PowerShell"
$site = Get-SPSite -identity
$site | Get-SPWeb -limit all | ForEach-Object { Write-Host $_.Url; Enable-SPFeature
-Identity {featureid} -url $_.Url }

Where:

The featureid is the value that you specified in the id element in the Elements.Xml file of the feature. In the previous example, the featureid would be RemoveRibbonButton. For more information, seeEnable-SPFeature(

To ensure that newly created sites have these options disabled,you can use feature stapling to staple the feature to site definitions. For more information on feature stapling, see Feature Stapling and the FeatureActivated Event in Windows SharePoint Services 3.0(

Implementing persistent cookies on a public or shared computer

In a public or shared environment (for example, on a computer deployed as a kiosk), persistent cookies might pose certainsecurity risks.Some of the measures that can be taken to reduce possible risks include:

Controlling access to SharePoint sites on computers in a shared environment by logging off inactive users quickly.
To make persistent cookies perceived as more secure, you can shorten the lifetime of the token that the identity provider issuesand then set the value of the logon token expiration in the SharePoint site to be less than that. For example, setting a 20 minute lifetime of the token in the identity provider and then setting a 10 minute logon token expiration will trigger a re-issuance of the fedauth cookie every 11 minutes, assuming the user is actively accessing the SharePoint site. If the user is idle for 20 minutes, the maximum value, and then tries to access a resource, the user will be redirected to the identity provider for authentication. Depending on the corporate policy, userscan configure the idle time they want to allow and thenconfigure the lifetime of the token issued by the identity provider and logon token expiration in the SharePoint site.
For more information about how to make the identity provider issue SAML tokens with a shorter lifetime (assuming ADFS is the identity provider used), see Update #2 in the following blog post: Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users(