我使用 ADFS 2.0 已经有一段时间了，我了解它是如何工作的。我已经完成了十几个自定义 RP、自定义 STS 以及使用 ADFS 作为依赖 STS。
但是，我有一个简单的要求，但我仍然无法满足。
我希望我的用户在一段时间后被迫重新登录。假设 1 分钟，用于测试目的。
首先，我在 RP 方面做了一些更正。似乎出于未知原因，即使令牌的validTo时间点回到过去，RP 也会保留会话。这与 Vittorio Bertocci 在他的书（第 123 页）中所说的相矛盾，他在书中展示了如何执行滑动过期 - 他说“SessionAuthenticationModule 将在之后立即处理过期的会话”。好吧，对我来说不是，但是我在这里找到了一个技巧http://blogs.planbsoftware.co.nz/?p=521 - 看看“if”子句：
sam.SessionSecurityTokenReceived +=
( s, e ) =>
{
SessionAuthenticationModule _sam = s as SessionAuthenticationModule;
DateTime now = DateTime.UtcNow;
DateTime validFrom = e.SessionToken.ValidFrom;
DateTime validTo = e.SessionToken.ValidTo;
try
{
double halfSpan = ( validTo - validFrom ).TotalSeconds / 2;
if ( validTo < now )
{
_sam.DeleteSessionTokenCookie();
e.Cancel = true;
}
}
catch ( Exception ex )
{
int v = 0;
}
};
这个技巧解决了 RP 方面的问题。当令牌无效时，应用程序将其清除并重定向到登录页面。
现在问题来了。我的登录页面使用FederatedPassiveSignIn控件。单击时，它将浏览器重定向到 ADFS。
但是 ADFS 很高兴地创建了一个新会话，而没有任何提示给用户。
我已将此 RP 的令牌生命周期设置为 1：
Set-ADFSRelyingPartyTrust -Targetname "myrpname" -TokenLifetime 1
并使用Get-ADFSRelyingPartyTrust我可以看到它设置为 1（我什至validTo在我的页面上打印令牌以确认设置正确）。
然后我设置 ADFS 属性ADFS-SetProperties：
ADFS-SetProperties -SsoLifetime 1
ADFS-SetProperties -ReplyCacheExpirationInterval 1
ADFS-SetProperties -SamlMessageDeliveryWindow 1
但仍然没有运气。我现在被困住了。
该方案适用于我的自定义 STS，其中 STS 会话的有效性基于表单 cookie - 如果我将 STS 的表单 cookie 超时设置为 1，则在我的 RP 应用程序中不活动 1 分钟后，我将被重定向到登录页面我的 RP 然后重定向到显示其登录页面的 STS。
但是，ADFS 2.0 并非如此。一分钟不活动后，我被重定向到我的 RP 的登录页面，该页面重定向到 ADFS 的登录页面，该页面又愉快地重定向回来，就像会话在 ADFS 中仍然处于活动状态一样。
我希望有人：
(1) 查看顶部描述的 hack 并解释为什么过期的令牌不会被自动拒绝并且需要这种丑陋的 hack
(2) 解释如何在 ADFS 2.0 端正确地使会话超时，以便更新令牌的请求受到登录页面的保护。
提前致谢。
编辑
我可以确认将上述所有参数设置为 1 分钟会使 ADFS 会话在 5 分钟（或更长时间）后失效。这很奇怪，似乎我犯了一个基本错误，或者 5 分钟是可接受的最小值。
我上面的（2）现在只是为了确认和解释我的观察。