本文介绍了与 ADFS 2.0 联合时如何正确设置超时的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用 ADFS 2.0 有一段时间了,我了解它是如何工作的.我已经完成了几十个自定义 RP、自定义 STS 以及使用 ADFS 作为依赖的 STS.

I am using ADFS 2.0 for quite some time and I understand how things work. I've done dozen of custom RPs, custom STSes as well as using the ADFS as the relying STS.

但是,我有一个简单的要求,但我仍然无法满足.

However, I have a simple requirement which I still fail to fulfill.

我希望我的用户在一段时间后被迫重新登录.假设 1 分钟,用于测试目的.

I want my users to be forced to relogin after some fixed time. Let's say 1 minute, for test purposes.

首先,我在 RP 方面做了一些更正.似乎出于未知原因,即使令牌的 validTo 指向时间,RP 也会保留会话.这与 Vittorio Bertocci 在他的书(第 123 页)中所说的相矛盾,他展示了如何执行滑动过期 - 他说SessionAuthenticationModule 将在之后处理过期会话".好吧,对我来说不是,但是我在这里找到了一个技巧http://blogs.planbsoftware.co.nz/?p=521 - 看看if"子句:

First, I've made some corrections at the RPs side. It seems that for unknown reason, the RP retains the session even if the token's validTo points back in time. This contradicts what Vittorio Bertocci says in his book (page 123) where he shows how to perform sliding expiration - he says that "The SessionAuthenticationModule will take care of handling the expired session right after". Well, for me it doesn't, however I have found a trick here http://blogs.planbsoftware.co.nz/?p=521 - take a look at the "if" clause:

        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 方面的问题.当令牌无效时,应用程序将其清除并重定向到登录页面.

This trick fixes the issue at the RPs side. When the token is invalid the application clears it out and redirects to the login page.

问题来了.我的登录页面使用 FederatedPassiveSignIn 控件.单击时,它将浏览器重定向到 ADFS.

Now comes the problem. My login page uses the FederatedPassiveSignIn control. When clicked, it redirects the browser to the ADFS.

但 ADFS 很高兴地创建了一个新会话,而无需为用户提供任何提示.

But ADFS happily creates a new session without any prompt for the user.

我已将此 RP 的令牌生命周期设置为 1:

I have set the token's lifetime for this RP to 1:

Set-ADFSRelyingPartyTrust -Targetname "myrpname" -TokenLifetime 1

并使用 Get-ADFSRelyingPartyTrust 我可以看到它设置为 1(我什至在我的页面上打印了令牌 validTo 以确认设置正确).

and using Get-ADFSRelyingPartyTrust I can see that it's set to 1 (I even print the token validTo on my page to confirm that this is set correctly).

然后我使用 ADFS-SetProperties 设置 ADFS 属性:

Then I set ADFS properties with ADFS-SetProperties:

ADFS-SetProperties -SsoLifetime 1
ADFS-SetProperties -ReplyCacheExpirationInterval 1
ADFS-SetProperties -SamlMessageDeliveryWindow 1

但仍然没有运气.我现在卡住了.

but still no luck. I am stuck now.

该场景与我的自定义 STS 一起正常工作,其中 STS 会话的有效性基于表单 cookie - 如果我将 STS 的表单 cookie 超时设置为 1,在我的 RP 应用程序中处于非活动状态 1 分钟后,我将被重定向到我的 RP 的登录页面,然后重定向到显示其登录页面的 STS.

The scenario works correctly with my custom STS where the validity of the STS session is based on a Forms cookie - if I set the STS's forms cookie timeout to 1, after 1 minute of inactivity within my RP application I am redirected to the login page of my RP which then redirects to the STS which presents its login page.

但是,ADFS 2.0 并非如此.一分钟不活动后,我被重定向到我的 RP 的登录页面,该页面重定向到 ADFS 的登录页面,该页面又愉快地重定向回来,就像会话在 ADFS 中仍处于活动状态一样.

However, this is not the case with ADFS 2.0. After a minute of inactivity, I am redirected to the login page of my RP which redirects to ADFS's login page which in turn redirects back happily just like the session would be still active within ADFS.

我希望有人:

(1) 看一下顶部描述的 hack 并解释为什么不会自动拒绝过期的令牌并且需要这种丑陋的 hack

(1) take a look at the hack described at the top and explain why an expired token is not automatically rejected and such ugly hack is needed

(2) 解释如何在 ADFS 2.0 端正确地超时会话,以便使用登录页面保护更新令牌的请求.

(2) explain how to properly timeout the session at the ADFS 2.0 side so a request to renew the token is guarded with a login page.

提前致谢.

编辑

我可以确认将上述所有参数设置为 1 分钟会使 ADFS 会话在 5 分钟(或更长时间)后无效.这很奇怪,看来要么我犯了一个基本错误,要么 5 分钟是可接受的最小值.

I can confirm that setting all above parameters to 1 minute makes the ADFS session invalid after 5 minutes (or more). That's strage and it seems that either I am making a basic mistake or 5 minutes is the minumum acceptable value.

我上面的(2)现在只是为了确认和解释我的观察.

My (2) from above is now then just to confirm and explain my observation.

推荐答案

根据上述评论(与 OP 共同努力)Freshness 属性en-us/library/microsoft.identitymodel.web.controls.federatedpassivesignin.aspx" rel="noreferrer">FederatedPassiveSignIn 实例应设置为 0.

As per comments above (joint effort with the OP) the Freshness property on the FederatedPassiveSignIn instance should be set to 0.

根据 http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.html 这表示 IP/STS 在发出令牌之前重新提示用户进行身份验证.

According to http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.html this indicates for the IP/STS to re-prompt the user for authentication before it issues the token.

这篇关于与 ADFS 2.0 联合时如何正确设置超时的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-12 21:54