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!