asp.net – ADFS 2.0超时以及Freshness Value,TokenLifetime和WebSSOLi

我很想知道ADFS 2.0超时场景中Freshness Value,TokenLifetime和WebSSOLifetime参数之间的关系.我已经对此进行了 did分析,我还没有得到清晰的图片.

解决方法

ADFS配置涉及两个主要超时：

> WebSSOLifetime – 服务器范围超时参数 – 默认值= 480分钟
> TokenLifetime – 为每个依赖方配置 – 默认值= 10小时

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 “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令牌无效.

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(OASIS – wfresh)的设置.当包含在web.config的federatedAuthentication部分中时,此参数(设置为fresh =“0”)将提示IDP根据WCT参数中的当前时间检查令牌的新鲜度值.

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.”

影响超时的其他因素：

我们还需要考虑以下因素,同时通过ISA或TMG反向代理发布ADFS,而不使用ADFS代理服务器 – 通常称为声明不知道反向代理.

MSISSignOut跟踪ADFS已发布的所有令牌(在此会话中),因此注销请求可以使ADFS已经过身份验证的所有依赖方会话无效,而不是仅退出启动请求的应用程序.这就是所谓的单点登出或单点登出.但是,ISA / TMG的设计并未考虑SAML声明,因此在启动超时/注销过程时,它们无法正确响应.

当我们遇到以下任何一种情况时,声明无意识的反向代理令牌生命周期就会出现：

用户的会话已与所请求的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没有任何关系.这是反向代理的会话已配置的方式.这是限制此侦听器的反向代理会话生存期的一个强有力的理由.
因此,即使ADFS会话超时,使用活动的反向代理会话,也可以重新向ADFS进行身份验证.有关TMG – ADFS设置的更多详细信息,请阅读this博客文章.

我保持这个问题是开放的,以获得有关该主题的更多意见.

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!