我很想知道ADFS 2.0超时场景中Freshness Value，TokenLifetime和WebSSOLifetime参数之间的关系。我已经did对此进行了一些分析，我还没有得到清晰的图片。
答案 0 :(得分：10)
我已经通过多个来源收集了以下有关ADFS超时的详细信息。
ADFS配置涉及两个主要超时：
<强> WebSSOLifetime：
这是服务器范围设置，适用于所有RP（依赖方）。每当用户询问给定RP的令牌时，他必须首先对ADFS服务进行身份验证。在与ADFS服务通信后，他将收到两个令牌，一个证明他是谁的令牌（让我们称之为ADFS令牌）和RP的令牌（假设是RP令牌）。现在，WebSSOLifetime超时确定ADFS令牌可用于请求新RP令牌的时间长度，而无需重新进行身份验证。换句话说，用户可以为此RP或其他RP请求新令牌，并且在WebSSOLifetime到期ADFS令牌之前，他不必证明他是谁。
<强> TokenLifetime：
这是适用于特定RP的RP级别设置。它不会影响ADFS服务器中配置的其他RP。每当用户收到RP令牌时，它将在某个时间到期。此时，用户必须再次转到ADFS服务器并请求新的RP令牌。根据ADFS令牌是否仍然有效，他不必重新进行身份验证。
降低TokenLifetime的一个论点可能是您希望声明更快地更新。使用默认值修改某些属性存储信息时，可能需要10个小时才能将此更改到达其声明中的用户。我们可以使用以下过程通过Shell脚本设置TokenLifetime：
•以管理员模式启动PowerShell并发出命令
“Add-PSSnapin Microsoft.Adfs.Powershell”
•使用以下命令获取应用程序的配置详细信息：
Get-ADFSRelyingPartyTrust -Name“您在ADFS信赖方信任中的应用显示名称”
•使用以下命令将ADFS设置中的TokenLifeTime值更改为所需的值：
set-ADFSRelyingPartyTrust -Targetname＆＃34;您的应用程序显示名称在ADFS依赖方信任＆＃34; -TokenLifetime＆＃34;以分钟为单位的值＆＃34;
这将在指定的时间段后使RP令牌无效。
使用上述设置，为了提示用户重新进行身份验证，我们要求WebSSOLifetime低于TokenLifetime。
想象一下这样一种情况：不同的RP具有不同的重新认证超时要求 - 假设RP希望用户在10分钟后重新认证（TokenLifetime设置为10），而其他RP的服务器级别WebSSOLifetime设置为50分钟。在这种情况下，用户不会被重定向到ADFS身份验证页面。相反，将在没有任何身份验证的情况下为用户创建新会话。这是因为虽然RP级别令牌已过期，但WebSSO令牌仍然有效。
新鲜度值
为了摆脱这个循环，我们可以使用名为Freshness Value（OASIS - wfresh）的设置。当包含在web.config的federatedAuthentication部分中时，此参数（设置为fresh =＆＃34; 0＆＃34;）将提示IDP根据WCT参数中的当前时间检查令牌的新鲜度值。
OASIS新鲜度值描述 - wfresh：
“此可选参数表示新鲜度要求。如果指定，则表示以分钟为单位指定的所需最大身份验证时间。 IP / STS不应该发出具有更长寿命的令牌。如果指定为“0”，则表示请求IP / STS在发出令牌之前重新提示用户进行身份验证。“
影响超时的其他因素：
我们还需要考虑以下因素，同时通过ISA或TMG反向代理发布ADFS，而不使用ADFS代理服务器 - 通常称为声明不知道反向代理。
MSISSignOut跟踪ADFS已发布的所有令牌（在此会话中），因此注销请求可以使ADFS已经过身份验证的所有依赖方会话无效，而不是仅退出启动请求的应用程序。这就是所谓的单点登出或单点登出。但是，ISA / TMG的设计并未考虑到SAML声明，因此在启动超时/退出流程时，它们无法正确响应。
当我们遇到以下任何一种情况时，声明无意识的反向代理令牌生命周期就会出现：
•用户的会话已与所请求的Web应用程序一起过期，他们需要使用ADFS重新进行身份验证，或
•如上所述，启动注销。
在反向代理会话的生命周期内，用户可以在不提示输入凭据的情况下重新向ADFS进行身份验证，因为代理会在会话期间将已收集的凭据传递给ADFS。
这与ADFS没有任何关系。这是反向代理的会话已配置的方式。这是限制此侦听器的反向代理会话生存期的一个强有力的理由。 因此，即使ADFS会话超时，使用活动的反向代理会话，也可以重新向ADFS进行身份验证。有关TMG - ADFS设置的更多详细信息，请阅读this博客文章。
我保持这个问题的开放，以获得有关此主题的更多意见。