ADFS 2.0 time out and relation between Freshness V

I am interested to know the relation between Freshness Value,TokenLifetime and WebSSOLifetime parameters in ADFS 2.0 time out scenario. I have already did my bit of analysis on this and I am yet to get a clear picture.

I have collected the below details w.r.t ADFS timeout through several sources.

There are two major timeouts involved in the ADFS configuration:

WebSSOLifetime – Server wide timeout parameter – Default value = 480 mins
TokenLifetime – This is configured for each Relying party – Default value = 10 hours

WebSSOLifetime:

This is a server wide setting which applies to all the RP’s (Relying Party). 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). 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:

This is a RP level setting which applies to a particular RP. It will not affect other RP’s configured in the ADFS server. 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 and 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. We can set the TokenLifetime through Shell script using the below procedure:

• Start the PowerShell in administrator mode and give the command

       “Add-PSSnapin Microsoft.Adfs.Powershell”

• Get the configuration details of the application using the command:

Get-ADFSRelyingPartyTrust -Name “your app display name in ADFS Relying party trust”

• Change the TokenLifeTime value in ADFS settings to the required value using the below command:

set-ADFSRelyingPartyTrust -Targetname "your app display name in ADFS Relying party trust" -TokenLifetime "value in minutes"

This will invalidate the RP token after the specified amount of period.

With the above settings, In order to prompt a user to re-authenticate, we require WebSSOLifetime to be lower than the TokenLifetime.

Imagine a scenario where different RP’s have different re-authentication timeout requirements – Say an RP wants it users to re-authenticate after 10 mins(TokenLifetime set to 10) when the Server level WebSSOLifetime for other RP’s are set to 50 mins. In this instance, the user will not be redirected to the ADFS authentication page. Instead, user will be created a new session without any authentication. This is because the WebSSO token is still valid though the RP level token has expired.

Freshness Value:

In order to come out of this loop, we can use a setting called Freshness Value (OASIS - wfresh). This Parameter (set as freshness="0") when included in the federatedAuthentication section of your web.config will prompt the IDP to check the freshness value of the token based on the current time in WCT parameter.

OASIS Description for the Freshness value – wfresh:

“This OPTIONAL parameter indicates the freshness requirements. If specified, this indicates the desired maximum age of authentication specified in minutes. An IP/STS SHOULD NOT issue a token with a longer lifetime. If specified as “0” it indicates a request for the IP/STS to re-prompt the user for authentication before issuing the token.”

Other Factors That Influence Timeout:

We also need to consider the below factors while publishing ADFS through ISA or TMG reverse proxy in place where ADFS proxy servers are not used – generally called as claims unaware reverse proxies.

MSISSignOut tracks all of the tokens that have been issued by ADFS (in this session) so a sign out request can invalidate all Relying Party sessions that ADFS has authenticated, rather than just signing out of the application where the request was initiated. This is what’s known as Single Sign Out or Single Logout. However, ISA/TMG hasn’t been designed with SAML Claims in mind, so they can’t respond appropriately when the Timeout / sign out process is initiated.

The Claims-unaware Reverse Proxy token lifetime comes into picture when we face any one of the below scenario:

• A user’s session has expired with the requested web application and they need to re-authenticate with ADFS, or

• Sign Out is initiated, as described above.

Within the lifetime of the Reverse Proxy’s session a user can re-authenticate to ADFS without getting prompted for credentials, since the proxy passes the already-collected credentials on to ADFS for the duration of the session.

This doesn’t really have anything to do with ADFS. This is how the session at the Reverse Proxy has been configured. This is a strong reason to restrict the Reverse Proxy session lifetime for this listener. So even if the ADFS session is timed out, with an active Reverse proxy session it is possible to re-authenticate to ADFS. For more details about TMG – ADFS setup, read this blog post.

I am keeping this question open to get more inputs on this topic.