Как правильно установить тайм-аут при объединении с ADFS 2.0

Я уже довольно давно использую ADFS 2.0 и понимаю, как все работает. Я сделал дюжину настраиваемых RP, настраиваемых STS, а также использовал ADFS в качестве полагающейся STS.

Однако у меня есть простое требование, которое я до сих пор не выполняю.

Я хочу, чтобы мои пользователи были вынуждены повторно войти в систему через определенное время. Скажем, 1 минута, для тестовых целей.

Во-первых, я внес некоторые исправления в RP. Похоже, что по неизвестной причине RP сохраняет сеанс, даже если токен validTo указывает назад во времени. Это противоречит тому, что Витторио Берточчи говорит в своей книге (стр. 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 основана на куки-файлах форм - если я установил время ожидания куки-файлов форм STS равным 1, через 1 минуту бездействия в моем приложении RP меня перенаправят на страница входа в систему моей RP, которая затем перенаправляется на STS, которая представляет свою страницу входа.

Однако это не относится к ADFS 2.0. После минуты бездействия я перенаправляюсь на страницу входа в мою RP, которая перенаправляет на страницу входа в ADFS, которая, в свою очередь, благополучно перенаправляет обратно, как будто сеанс все еще активен в ADFS.

Я бы хотел, чтобы кто-нибудь:

(1) взглянул на взлом, описанный вверху, и объяснил, почему просроченный токен не отклоняется автоматически, и нужен такой уродливый хак

(2) объясните, как правильный тайм-аут сеанса на стороне ADFS 2.0, чтобы запрос на обновление токена защищался страницей входа.

Заранее спасибо.

edit

Я могу подтвердить, что установка всех вышеуказанных параметров на 1 минуту делает сеанс ADFS недействительным через 5 минут (или более). Это странность, и кажется, что либо я делаю основную ошибку, либо 5 минут - это минимально приемлемое значение.

Мое (2) сверху теперь просто для подтверждения и объяснения моих наблюдений.