asp.net - ADFS 2.0超时以及Freshness Value，TokenLifetime和WebSSOLifetime参数之间的关系

Question

我很想知道ADFS 2.0超时方案中的Freshness Value，TokenLifetime和WebSSOLifetime参数之间的关系。我已经对此进行了一点分析，但还没有清晰的图片。

Answer 1

我已经通过几个来源收集了以下ADFS超时的详细信息。
ADFS配置涉及两个主要的超时:

WebSSOLifetime –服务器范围超时参数–默认值= 480分钟

TokenLifetime –为每个依赖方配置–默认值= 10小时

WebSSO生存期:
这是服务器范围的设置，适用于所有RP(依赖方)。每当用户请求 token 给定的RP时，他都必须首先向ADFS服务进行身份验证。与ADFS服务进行通信后，他将收到两个 token ，一个用于证明自己身份的 token (简称为ADFS token )，一个用于RP的 token (例如RP token )。现在，WebSSOLifetime超时确定了ADFS token 可用于请求新的RP token 的时间，而无需重新进行身份验证。换句话说，用户可以为此RP或其他RP请求新 token ，并且在WebSSOLifetime到期ADFS token 之前，他不必证明自己是谁。
token 生命周期:
这是适用于特定RP的RP级别设置。它不会影响ADFS服务器中配置的其他RP。每当用户收到RP token 时，它都会在某个时间过期。届时，用户将不得不再次进入ADFS服务器并请求新的RP token 。根据ADFS token 是否仍然有效，他将不必重新进行身份验证。
降低TokenLifetime的一个论点可能是您希望声明更新得更快。默认情况下，只要修改了某些属性存储信息，此更改可能需要10个小时才能到达其声明中的用户。我们可以使用以下过程通过Shell脚本设置TokenLifetime:
•以管理员模式启动PowerShell并给出命令

       “Add-PSSnapin Microsoft.Adfs.Powershell” 

•使用以下命令获取应用程序的配置详细信息:

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

•使用以下命令将ADFS设置中的TokenLifeTime值更改为所需值:

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

在指定的期限后，这将使RP token 无效。

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.

新鲜度值:
为了摆脱此循环，我们可以使用一个称为“新鲜度值”(OASIS-wfresh)的设置。当您的web.config的federatedAuthentication部分中包含此参数(设置为freshness =“0”)时，该参数将提示IDP根据WCT参数中的当前时间检查 token 的新鲜度值。
OASIS“新鲜度”值的说明– 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.”

其他影响超时的因素:
在不使用ADFS代理服务器的情况下，通过ISA或TMG反向代理发布ADFS时，我们还需要考虑以下因素:通常称为不了解反向代理的声明。
MSISSignOut跟踪由ADFS发出的所有 token (在此 session 中)，因此注销请求可使ADFS身份验证的所有依赖方 session 无效，而不仅仅是退出发起请求的应用程序。这就是所谓的“单一注销”或“单一注销”。但是，在设计ISA/TMG时并未考虑到SAML声明，因此在启动“超时/退出”过程时，它们无法做出适当的响应。
当我们面对以下任何一种情况时，无索偿要求的反向代理 token 生存期就会变得很重要:
•用户的 session 与所请求的Web应用程序已过期，因此他们需要使用ADFS重新进行身份验证，或者
•如上所述，开始注销。

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.

这实际上与ADFS没有任何关系。这是在反向代理服务器上配置 session 的方式。这是限制此监听器的反向代理 session 生存期的重要原因。
因此，即使ADFS session 超时，使用事件的反向代理 session 也可以对ADFS重新进行身份验证。有关TMG – ADFS设置的更多详细信息，请阅读this博客文章。
我对此问题保持开放态度，以获取有关该主题的更多意见。