ADFS 2.0超时和新鲜度的价值，TokenLifetime和WebSSOLifetime参数之间的关系 [英] ADFS 2.0 time out and relation between Freshness Value,TokenLifetime and WebSSOLifetime parameters

问题描述

我想知道在ADFS 2.0超时场景清新的价值，TokenLifetime和WebSSOLifetime参数之间的关系。我已经做我分析一下就这一点，我还没有得到清晰的画面。

解决方案

我已经收集了以下细节WRT ADFS超时通过几个来源。

有涉及ADFS配置两大超时：

1. WebSSOLifetime - 服务器广泛的超时参数 - 默认值= 480分钟
2. 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的管理员模式，并发出命令

 添加-PSSnapin Microsoft.Adfs.Powershell
 

•获取使用该命令的应用程序的配置细节：

  

GET-ADFSRelyingPartyTrust -Name在ADFS依赖方信任你的应用程序的显示名称

•在ADFS设置TokenLifeTime值使用下面的命令，切换到所需的值：

  

设置ADFSRelyingPartyTrust -TARGETNAME -TokenLifetime以分钟值在ADFS依赖方信任你的应用程序的显示名称

这将RP的令牌期间的指定金额后失效。

  

通过上面的设置，以提示用户重新进行身份验证，我们需要WebSSOLifetime到除TokenLifetime更低。

     

    

想象一下这样一个场景，不同的RP的有不同的重认证超时要求 - 说的RP希望它的用户10分钟后，重新进行身份验证（TokenLifetime设置为10），当服务器级别WebSSOLifetime其他RP的设置为50分钟。在这种情况下，用户将不会被重定向到ADFS身份验证页面。相反，用户将可以创建一个新的会话，而无需任何身份验证。这是因为，WebSSO令牌仍然是有效的，虽然所述的RP级别令牌已过期。

  

新鲜度值：

为了走出这个循环中，我们可以使用一个被称为新鲜度值（OASIS设置 - <一个href="http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223175013">wfresh).这个参数（设定为新鲜度=0）包含在你的web.config的federatedAuthentication部时将促使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的设置，请参阅这的博客文章

我保持这个问题公开，以获得更多的投入就这个话题。

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:

1. WebSSOLifetime – Server wide timeout parameter – Default value = 480 mins
2. 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.

这篇关于ADFS 2.0超时和新鲜度的价值，TokenLifetime和WebSSOLifetime参数之间的关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！