ADFS: WebSSOlifetime vs TokenLifetime

Published on Friday, January 6, 2012 in

I’m currently facing an issue I had some issues in the past with an ADFS deployment using ISA as an ADFS Proxy. We use ISA for the following reasons:

  • It allows us to do all kinds of authentication. For instance we are using BE-ID to authenticate users.
  • The customer already has ISA so we save out a server by not using the ADFS Proxy itself.
  • There’s no federation with other IDPs so we don’t have to do any fancy home realm discovery.

Now the problem we were seeing was that whenever the ISA session timed out, the user was presented with the ISA Forms Based Authentication (FBA) logon screen. If the users were to choose another identity, he would still appear as the original user towards the ADFS enabled application.

This makes totally sense as the client also got ADFS tokens and they have other timeouts than those configured on ISA. This post will try to explain some relevant parameters from the ADFS side. I’m not saying the defaults aren’t good, that’s something you’ve got to decide for yourself.

WebSSOLifetime (Default 480 = 8 hours)

This parameter is server-wide. Meaning if you configure it, it’s active for all of the ADFS relying parties. Whenever a user asks a token for a given RP he will have to authenticate to the ADFS service first. Upon communicating with the ADFS service he will receive two tokens: a token which proves who he is (let’s call that the ADFS Token) and a token for the RP (let’s say the RP Token). All in all this seems very much like the TGT and TGS tickets of Kerberos.

Now the WebSSOLifetime timeout determines how long the ADFS token can be used to request new RP Tokens without having to re-authenticate. In other words a user can ask new tokens for this RP, or for other RP’s, and he will not have to prove who he is until the WebSSOLifetime expires the ADFS token.

TokenLifetime (Default 0 (which is 10 hours))

The TokeLifetime is now easy to explain. This parameter is configurable for each RP. Whenever a user receives a RP Token, it will expire at some time. At that time the user will have to go to the ADFS server again an request a new RP token. Depending on whether or not the ADFS Token is still valid or not, he will not have to re-authenticate.

One argument to lower the TokenLifetime could be that you want the claims to be updated faster. With the default whenever some of the Attribute Store info is modified, it might potentially take 10 hours before this change reaches the user in its claims.

I wrote this post because I struggled with this myself and I found not that much information. There’s some information available in the SharePoint 2010 context, but I feel like these parameters aren’t explained enough. I have to admit that the above came clear once I saw one of the ADFS sessions at The Experts Conference of Laura E. Hunter and Brian Puhl. Thanks both for your great sessions!

Related Posts

10 Response to ADFS: WebSSOlifetime vs TokenLifetime

22 June, 2012 21:56

Thanks for the explanation!

09 July, 2012 10:53

Nice one, I have manually been setting the TokenLifetime value to 600, but no I see there is no need!

15 October, 2012 20:52

Great explanation. We've been testing using WebSSOLifetime. Nice to know there is an alternative to the sledgehammer approach.

21 January, 2013 17:32

TokenLifetime (Default 0 (which is 10 hours)) - for me it is showing 1 hour in IE & Google Chrome. Could you please confirm this, if it is not a typo from your side?

29 January, 2013 10:04

Hey, It's been a while since I've went deeper on this. But here's a link to a TechNet article where they also state 10 hours as the default token lifetime.... http://technet.microsoft.com/en-us/library/cc782865(v=ws.10).aspx

04 June, 2013 18:05

Thank you, now it's clear to me

29 January, 2014 16:54

Just to be clear....The default TokenLifetime is 60 MINS not 10 hours in ADFS 2.0. http://technet.microsoft.com/en-us/library/gg188586.aspx
10 hours is for ADFS 1.0 not 2.0 which most people would have implemented.

11 February, 2014 08:19

Thanks for taking the time to post back. You are absolutely right.

02 October, 2015 12:58

Thanks thanks, thanks. :)

23 November, 2017 02:42

Awesome article. Thanks for the very detailed information.

Add Your Comment