Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users

  • Article

Summary:  Learn how to set the logon token expiration correctly for Microsoft SharePoint 2010 SAML claims users.

Applies to: Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Provided by:  Steve Peschka, Microsoft Corporation

Contents

  • Understanding How to Set the Logon Token Expiration and Token Lifetime for SharePoint 2010 SAML Claims Users

  • Evaluating How to Resolve That SAML Claims Users Are Signed Out When The Logon Token Nears Expiration on a Site with Anonymous Access Enabled

  • Conclusion

  • Additional Resources

Understanding How to Set the Logon Token Expiration and Token Lifetime for SharePoint 2010 SAML Claims Users

As I was working on understanding the process for expiring logon cookies recently, I found what seemed like a big problem. For Security Assertion Markup Language (SAML) claims users, after they get their logon cookie from Active Directory Federation Services (AD FS) 2.0, they never seem to time out. They could close the browser and, several minutes or even hours later, open the browser again and navigate directly to the site, without having to reauthenticate to AD FS 2.0. In addition, the Microsoft Office 2010 client applications worked the same way. I finally figured out the multiple pieces that were causing the problem, and I want to share them here.

First, a brief background. The first time that you navigate to a Microsoft SharePoint 2010 site that is secured with SAML claims, it redirects you to get authenticated and get your claims. Your SAML identity provider, also known as identity provider security token service (IP-STS), does all that and then redirects you to SharePoint. When you come back into SharePoint 2010, SharePoint creates a FedAuth cookie; that is how SharePoint knows that you have been authenticated. To make a smoother end-user experience, SharePoint writes the FedAuth cookie value to the local cookies folder. On subsequent requests for that site, if SharePoint finds a valid FedAuth cookie for the site, SharePoint reads the cookie and takes you directly to the SharePoint content, without reauthenticating.

This can be a bit of a jolt to those of you who are used to using AD FS 1.X and Microsoft Office SharePoint Server 2007 because, when using them, all web single sign-on (SSO) cookies are session-based, so we did not save them to disk. When you closed your browser, for example, the cookie went away; you had to reauthenticate each time that you closed and opened your browser.

That is not the case with SharePoint 2010. But you can make a change to the SharePoint security token service (STS) to make it work with session cookies again, as it did in Office SharePoint Server 2007. The following Windows PowerShell code makes the change.

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
iisreset

After implementing this code, you will see that there is no longer a cookie written to disk. To change back to the default behavior, just reverse your steps, as shown in the following Windows PowerShell command.

$sts.UseSessionCookies = $false
$sts.Update()
iisreset

So, how do you configure this behavior to get a SAML token with a reasonably manageable lifetime? There are several considerations that you need to look at:

  1. The TokenLifetime property can be set per relying party in AD FS 2.0. This is a bit of a problem because it means that the default behavior is that after you get a cookie it is good for a long time (I have not actually tested to see how long the cookie is good for).

  2. In the following code, SPS 2010 ADFS is the name of the relying party trust entity in AD FS 2.0. (Thanks to Rich Harrison for providing this nugget for updating the TokenLifetime property in AD FS 2.0 for the relying party.)

    Set-ADFSRelyingPartyTrust -TargetName "SPS 2010 ADFS" -TokenLifetime 5

    So, if you want to set the TokenLifetime property of the relying party in AD FS 2.0 at creation time, you need to do so by using Windows PowerShell. The following is the one-line script that I used to create my relying party.

    Add-ADFSRelyingPartyTrust -Name "FC1" -Identifier "https://fc1/_trust/" -WsFedEndpoint "https://fc1/_trust/" -TokenLifetime 2 -SignatureAlgorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1

    After creating the relying party this way, you manually do the following:

    1. Add the realm to the list of identifiers (for example, urn:sharepoint:example).

    2. Add an issuance authorization rule to allow access to all users.

    3. Add an issue transform rule to send email addresses and roles.

  3. If you try to log on now, you will likely find that, after you authenticate to AD FS 2.0, you get caught up in an endless loop, going back and forth between SharePoint 2010 and AD FS 2.0. If you look at the traffic in Microsoft Fiddler, you can see that you are authenticating successfully to AD FS 2.0 and then coming back to SharePoint 2010. The authentication code is successfully issuing the FedAuth cookie, and then the authentication code redirects you to /_layouts/authenticate.aspx on the SharePoint site, which clears out the FedAuth cookie and redirects you back to the AD FS site.

    You go back and forth until AD FS 2.0 stops it and gives you an error message similar to "The same client browser session has made '6' requests in the last '12' seconds".

    This actually makes sense. This is because the default LogonTokenCacheExpirationWindow value for the SharePoint STS is 10 minutes. In this case, when I created my relying party, I set the token lifetime in AD FS 2.0 to be 2 minutes. Therefore, as soon as the authentication happened, the authentication code logic knew the cookie was good for less time than the LogonTokenCacheExpirationWindow value. The authentication code goes back to AD FS 2.0 to authenticate again. And so it goes, back and forth. To fix this, you just have to change the LogonTokenCacheExpirationWindow value to be less than the SAML TokenLifetime value. Then you can log into the site. The following is example code for setting the LogonTokenCacheExpirationWindow value in SharePoint.

    $sts = Get-SPSecurityTokenServiceConfig
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)
$sts.Update()
Iisreset

After you have configured these settings correctly, the logon expiration for SAML users works correctly. For 2 minutes, I can open and close my browser window and continue to get back into the site without being redirected back to SharePoint. After 2 minutes, it correctly makes me reauthenticate to AD FS 2.0.

Evaluating How to Resolve That SAML Claims Users Are Signed Out When The Logon Token Nears Expiration on a Site with Anonymous Access Enabled

Consider this scenario: A user signs in and is issued a token and a cookie that is valid for a certain amount of time, on a site that has anonymous access enabled. After that period of time has elapsed, the cookie expires and the cookie is not sent to SharePoint. SharePoint now does not know the difference between a user who has logged on earlier and an anonymous user. Because the page is enabled for anonymous access, the page just renders the content that is allowed for viewing via anonymous access. If the user wants to view the non-anonymous part of the page, the user has to log on to the page again.

If you do not want your user to have to log on often, the AD FS v2 TokenLifetime should be set to a large value (in the order of hours) and the LogonTokenCacheExpirationWindow value should be set to as low as 1 second, to maximize their login session duration. This decision (whether to set the AD FS v2 TokenLifetime to a large value and the LogonTokenCacheExpirationWindow to as low as 1 second) depends on your specific topology deployment and your organization's security requirements. Some of the points to consider are:

  • Are these sites using SSL Transport Layer Security (TLS)?

  • What is the profile of the users who are logging on to the site?

  • Where are the users logging on from?

  • What kind of data is stored?

  • What is your organization's security policy?

Conclusion

This article provides guidelines about how to set the logon token expiration correctly for SAML claims users in SharePoint 2010.

Additional Resources

For more information, see the following resources: