Freigeben über

Cookie Persistence in SharePoint Online

  • Artikel

Introduction

Certain legacy features in SharePoint Online — Explorer view, for example — leverage legacy technologies like Windows WebDAV.  WebDAV makes use of the browser's authentication cookie.  Because of security concerns, WebDAV cannot access session cookies; only cookies that are written to disk are accessible by WebDAV. This means that in order for WebDAV to access the authentication cookie, the cookie needs to be persistent (persistent cookies are written to disk)*.

The easiest way to ensure cookie persistence is to check the "Keep Me Signed In"? box on the Office 365 Home Realm Discovery Page before entering your username and password. However, some customers who have Auto-Acceleration enabled in their tenancies will not be presented with a home realm discovery page. Other administrators may wish to issue persistent cookies across the organization, or a subset of the organization, and not have to bother with user education or extra steps in order to streamline user workloads and ensure capabilities. Typically, these Administrators have federated identity providers (such as ADFS.)  If you have ADFS using WS-Fed Federation with Office 365, you can direct Azure Active Directory to issue a persistent cookie by including certain claims rules in your Relying Party Trust**.

Establishing the Claim

Previously, if your ADFS Properties were set to allow the Keep Me Signed In Enabled and Persistent SSO Enabled attributes (Set-Adfsproperties -KmsiEnabled and -PersistentSSOEnabled, respectively) then the Persistent SSO claim was present in the claims pipeline, and administrators could pass that claim through to the service. However, a fix was recently (August 2017) released that only issues the PSSO claim on the pipeline if the KMSI option is checked at the identity provider's Forms Based Authentication page. Therefore, customers may have noticed that they are no longer being issued persistent cookies in SharePoint Online.  To work around this fix, ADFS Administrators can add or edit their issuance claims rules for the Microsoft Office 365 Identity Platform relying party trust to include the PSSO claim as follows:

  • If an Administrator wants to issue a persistent single sign on token for all users, he can simply issue the claim with the following language:
 => issue(Type = "https://schemas.microsoft.com/2014/03/psso", Value = "true");
  • If an Administrator wants to issue the claim only for users that authenticate from inside the corporate network, they would use two claims. First would be to pass through the InsideCorporateNetwork claim, and then they would issue a PSSO claim based on the value of the InsideCorporateNetwork claim, as follows:
 c:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"]

=> issue(claim = c);

 

 c:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"]

=> issue(Type = "https://schemas.microsoft.com/2014/03/psso", Value = "true");
  • If an Administrator wants to only issue claims to a subset of users, such as based on group membership, they must find the SID of the group they wish to use to issue the claim, and then use the following claims rule language:
 c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "[SID OF GROUP]", Issuer == "AD AUTHORITY"]

=> issue(Type = "https://schemas.microsoft.com/2014/03/psso", Value = "True", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType);

Editing Claims in ADFS

Your organization's administrator for Active Directory Federation Services will know how to access the Office 365 Relying Party Trust; however, for completeness, here is how one would implement the claims rules above.

In ADFS, open the ADFS Management Console (In Server Manager > Tools > ADFS Management)

ADFS Management Screen Shot

.

In the left hand navigation pane of the ADFS Management Console select ADFS > Trust Relationships > Relying Party Trusts. There you will see the trusts that have been configured. By default, the Office 365 Relying Party Trust Display Name is "Microsoft Office O365 Identity Platform" and the Identifier is "urn:federation:MicrosoftOnline"

Relying Party Trusts Screenshot

Right click the Microsoft Office O365 Identity Platform and select Edit Claims Rules.  The rules above are Issuance Transform Rules.  You can add them by clicking the Add rule and choosing the "Send Claims Using a Custom Rule" Option:

Custom Claim Rule Dialog Screenshot

Here is an example of a simple issue of the PSSO Claim:

Custom Claims Rules Language example

Click Finish, and the Claims Rule will be added to the pipeline. Please note that order matters; if you decide to issue the PSSO claim based on another claim (such as the InsideCorporateNetwork Claim, above), that claims rule must be present before the PSSO claim.

 

Notes on Persistent Cookies

*: Administrators should use caution when deciding if and how to issue these cookies. Currently, there is no check if a specific setting has changed; so long as the user has a valid FedAuth cookie, they are allowed access to SharePoint resources and do not have to re-authenticate. For example, someone who issues a persistent cookie based on a machine being inside the corporate network (Example above), who then takes their laptop down the street and access SPO from the corner coffee shop, will still be able to access SharePoint Resources.

It is up to the administrator to understand and manage the kinds of risks using these cookies can incur.

**: As of right now, AAD does not support SAML based use of the Persistent Single Sign On Claim / SAML attribute.

Comments

  • Anonymous
    September 15, 2017
    Nice article. Thanks for the info.