Aracılığıyla paylaş

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

  • Makale

 

As I was working on understanding the process for expiring login cookies recently, I found what seemed like a pretty big problem. For SAML claims users, once they got their login cookie from ADFS, they would never seem to time out. Meaning they could close the browser, and several minutes or even hours later open the browser again and just navigate directly to the site without having to reauthenticate to ADFS. In addition the Office 2010 client applications worked the same way. I finally figured out the multiple pieces that were causing that and so I’m documenting them here.

 First a really, really brief background. When you navigate to a SharePoint site secured with SAML claims the first time, it will redirect you to get authenticated and get your claims. Your SAML identity provider (a.k.a. IP-STS) does all that and redirects you back to SharePoint. When you come back into SharePoint we create a FedAuth cookie and that’s how we know you’ve been authenticated. To make for smoother end user experience we write the FedAuth cookie value to the local cookies folder. On subsequent requests for that site, if we find a valid FedAuth cookie for the site we’ll just read the cookie and take you right to the SharePoint content without authenticating again. This can be a bit of a jolt to those of you who are used to ADFS 1.x and SharePoint 2007, because with them all Web SSO cookies were session based so we didn’t save them to disk. When you closed your browser for instance, the cookie went away so you had to reauthenticate each time you closed and opened your browser. That is not the case with SharePoint 2010.

UPDATE #1: We found a change that can be made to the SharePoint STS to make it work with session cookies again, as it did in SharePoint 2007. This PowerShell will make the change:

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

After doing this you will see that there is no longer a FedAuth cookie written to disk. To change things back to the default behavior just reverse your steps:

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

 So, how do we configure this behavior to get a SAML token with a nice manageable lifetime? Here are the things you need to look at:

  1. The TokenLifetime property can be set per relying party in ADFS. Unfortunately it seems to only be settable at the time you create the relying party. This is a bit of a problem because that means the default behavior is that once you get a cookie you’re good to go for a really, really long time (I haven’t actually tested to see how long it’s good for).

UPDATE #2: Rich Harrison was good enough to provide this nugget for updating the TokenLifetime in ADFS for the relying party:

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

where "SPS 2010 ADFS" is the name of the Relying Party Trust entity in AD FS 2.0.

So, if you want to set the TokenLifetime of the relying party in ADFS at creation time, you need to do so using PowerShell. Here’s the little one line script I used to create my relying party:

 

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

 

After creating the relying party this way you need to manually:

  1. Add the realm to the list of identifiers (i.e. urn:sharepoint:foo)
  2. Add an Issuance Authorization Rule to permit access to all users
  3. Add an Issue Transform Rule to send over email address and roles

 

  1. If you just try and login now you will likely find that after you authenticate to ADFS, you’ll get caught up in this endless loop where you go back and forth between SharePoint and ADFS. If you look at the traffic in Fiddler it turns out that you are authenticating successfully to ADFS, you’re coming back to SharePoint and it is successfully issuing the FedAuth cookie, it redirects you to /_layouts/authenticate.aspx on the SharePoint site which clears out the FedAuth cookie and redirects you back to the ADFS site. You basically ping pong back and forth until ADFS stops it and gives you an error message along the lines of “The same client browser session has made ‘6’ requests in the last ‘12’ seconds.”. It turns out that this actually makes sense. That’s because the default LogonTokenCacheExpirationWindow for the SharePoint STS is 10 minutes. In this case when I created my relying party I set the token lifetime in ADFS to be 2 minutes, so as soon as it authenticated it knew the cookie was good for less time than the LogonTokenCacheExpirationWindow value, so it went back to ADFS to authenticate again. And so it went, back and forth. So to fix that part of you just need to change the LogonTokenCacheExpirationWindow to be less than the SAML TokenLifetime, and then you can log into the site. Here’s an example of setting the LogonTokenCacheExpirationWindow in SharePoint:

 

$sts = Get-SPSecurityTokenServiceConfig

$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)

$sts.Update()

Iisreset

 

Now, once you configure these settings correctly the login expiration for SAML users works correctly. I can open and close my browser window and continue to get back into the site without being redirected back to SharePoint for 2 minutes. After that time though it correctly makes me reauthenticate to ADFS.

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

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Hi Vitaly, Hi Steve I have the same problem than Vitaly. This probleme occures when i use ADFS with Multi-tenancy site collection. If i use a classic Site Col with ADFS, everythig seems Ok. Any idea please ?

  • Anonymous
    January 01, 2003
    Does setting the TokenLifetime have any affect on this. It needs to be set per Relying Party Trust.
    Get-AdfsRelyingPartyTrust -Name "Your Relying Party Trust Name"
    Set-AdfsRelyingPartyTrust -TargetName "Your Relying Party Trust Name" -TokenLifetime 720 (12 Hours)

  • Anonymous
    January 01, 2003
    Steve, I have the follow situation: TokenLifetime on ADFS STS for SharePoint setted for 10 hours and token cache on SharePoint (if I right understand - it is LogonTokenCacheExpirationWindow) setted to 1 minute. But I see in logs from time to time that after 15-20 minutes user may be redirected to ADFS STS. It was initiated by sending from _trust FedAuth cookie with expiration DateTime.MinValue (31 dec 1969). We have NLB on our solution, may be SPTokenCache not adopted to work with NLB? Was you faced with the same situations? What may you recommend? Thanks

  • Anonymous
    October 07, 2010
    Hi Steve, This was a nice article which I found while searching for setting the expiration time for the STS token. I am using forms authentication with a custom provider and custom login page. Everything works fine(authentication,authorization) except for the "persistent cookie (say for 365 days)" mechanism which I don't know how to get it to work. The basic requirement is that when a user selects "remember me", he should never be logged out (never). When he does not select remember me, it should default to a session cookie and not a persistent cookie. In SharePoint 2007, you could could create a new cookie out of the forms authentication ticket with the required timeframe (365 days) and you were all set. Once remember me is selected, you will always be logged into the site even after many days of inactivity. With claims authentication, since the token lifetime is controlled by the STS service and has few defaults for formstokenlifetime (which is 10 hrs). How do I set this value depending on whether user selects "remember me" or not ? Though this formstokenlifetime can be set at the STS service level, but how do I set it at a request level ? Any pointers will be really helpful. Thanks, Prashanth

  • Anonymous
    December 22, 2010
    Steve, When you tested this (LogonTokenCacheExpirationWindow = 1 min and SAML token lifetime = 5 mins), did you still have session cookies enabled? Travis Nielsen | PointBridge

  • Anonymous
    December 22, 2010
    Sorry. Disregard. I just found KB 2462541 and it resolved the looping issue I was seeing. Travis Nielsen | PointBridge

  • Anonymous
    January 28, 2011
    We have SP2010, ADFS for claims, and see the following: Completely random ADFS errors. We have tried the MS cumulative patch release on 31st Dec 2010. We have tried setting the ADFS lifetime to 0 which is forever, so higher than the sharepoint lifetime. We are using FedAuth persistent cookies. This has been going on for months and everything we try produces random ADFS errors. We are not pushing the back button, which I know is a known fault. Just click to the site, ADFS does its thing, use the site and randomly we get the ADFS error, even after a few minutes. Tried clearing down cookies too! Also, we get similar issues with different parts Office 2003 and Office 2010 when going direct to sharepoint to get/put files etc. Are they supported with ADFS properly. Is ADFS and Sharepoint 2010 and Office 2003/2010 all supported together? Any help gratefully received! Adam

  • Anonymous
    April 08, 2011
    Steve, We are using Form Based Authentication in 2010 and one of the requirements is to auto logout the site after certain amount of idle time. I used the following Powershell command to set the expiration time for the form token. The problem is it logout every 3 minutes even I'm working on the site. Do you know how to set it properly? Thanks. Set-SPSecurityTokenServiceConfig -FormsTokenLifetime 3

  • Anonymous
    April 18, 2011
    Hi Steve, I've documented how the LogonTokenCacheExpirationWindow property works in this post blogs.southworks.net/.../sliding-sessions-in-sharepoint-2010 I've spent quite a while with the Reflector opened, testing the different scenarios. Hopefully this can save people time when trying to understand it. Thanks, Federico

  • Anonymous
    May 30, 2011
    HI Steve, We are also facing the same issue and would like to turn off persistent cookie and use session cookie. But the difference is we are using Forms-based authentication for our site. Can you let me know if we can apply the same fix detailed by you here? $sts = Get-SPSecurityTokenServiceConfig $sts.UseSessionCookies = $true $sts.Update() iisreset One more thing, the KB 2462541 hotfix is also not applied in our environment. Can you also let me know if we have to apply this hotfix before we try the above solution?

  • Anonymous
    May 31, 2012
    Thanks Steve for your posts. I'm thinking i might require something similar to achieve the following: I have two SP Web Applications on a farm (for example X.mydomain.com and Y.mydomain.com) both configured with ADFS claims authentication. Hence on ADFS 2.0 I created two relying parties (one for each site). All is working fine, however, for one of these web applications (Y.mydomain.com), I require that the system will always force re-authentication. i.e. Whenever user accesses Y.mydomain.com system should always prompt for credentials (even when hopping to from X.mydomain.com). Is this possible? Many Thanks!

  • Anonymous
    August 28, 2012
    I was reading your ADFS articles. I am facing peculiar issue, may be you came across same issue. Please guide me if you have any solution on my problem. any help will be appricate. My Environment is: 1.SharePoint 2010 farm with ADFS claim based authentication where current token expiry is 50 min Problem Statement: Whenever user open any word or excel file through Office Web Application (OWA) and keep drafting large documents when ADFS refresh (i.e. ADFS initiate token reissue ) happens,  users start getting below exceptions. Same time user lost his changes from last saved instance till the time error popup. Error text: 1.Excel : “Either due to communication issues or server problem, you need to be rejoined to your editing session” 2.Word: “You do have permission to open this file” We were able to replicate bug very easily. Expected Result: During ADFS refresh, user data should remain intact. Possible solution       1.Is it possible to achieve this by sliding session? or do you think any other solution to come over this issue. 2.By increasing ADFS Fedauth cookie expire. But this will lead to security threat and this will not resolve issue 100%. Please share your valuable advice. Thanks for your efforts in advance. -Sudarshan S Vatturkar

  • Anonymous
    February 12, 2013
    Hi Steve, when we don't use SessionCookie ($sts.UseSessionCookies = $false), do you know where exactly does SharePoint save the persistent cookie on the disk drive?  (Physical path name).  Can we check/ configure this location? Thanks for your help. Thanh-Nu Leroy

  • Anonymous
    February 18, 2014
    I have a following situation. Have a Sharepoint farm with 8 Front end servers with 2 of them allocated for Central Adimin. I have to setup the fedAuth cookie as session cookie to ensure, the session get removed when the user closes the browser. Ran the following PS script to configure session cookies. $sts = Get-SPSecurityTokenServiceConfig $sts.UseSessionCookies = $true $sts.Update() iisreset Even after this configuration, I see FedAuth is being set as Persistent cookie with an expiration date. FedAuth cookie is setup as Persistent cookie intermittently. Any insight on this intermittent behavior will be very helpful.

  • Anonymous
    September 18, 2014
    The comment has been removed

  • Anonymous
    November 04, 2014
    The comment has been removed

  • Anonymous
    February 06, 2015
    good for home
    https://www.pinterest.com/janianjani526/
    http://rumahbagus.info/desain-rumah-minimalis-type-45/
    http://rumahbagus.info/desain-rumah-minimalis-type-36-72/
    http://rumahbagus.info/desain-rumah-unik-nuansa-etnik/
    http://rumahbagus.info/gambar-rumah-tampak-depan-fasade/
    http://rumahbagus.info/desain-interior-model-rumah-idaman/
    http://rumahbagus.info/gambar-teras-rumah-dan-konstruksinya/
    http://rumahbagus.info/jenis-dan-model-pintu-rumah/
    http://rumahbagus.info/desain-interior-rumah-sederhana/
    http://rumahbagus.info/mengenal-desain-arsitektur-rumah-adat-toraja/
    http://rumahbagus.info/tahapan-perancangan-sketsa-rumah-minimalis/
    http://rumahbagus.info/rumah-mewah-minimalis/
    http://rumahbagus.info/foto-rumah-minimalis-modern/
    http://rumahbagus.info/model-rumah-minimalis-sederhana/
    http://rumahbagus.info/model-rumah-minimalis-2-lantai/
    http://rumahbagus.info/desain-kamar-minimalis-sederhana/
    http://rumahbagus.info/model-desain-gambar-rumah-minimalis-type-21/