Estou usando o ADFS 2.0 há algum tempo e entendo como as coisas funcionam. Eu fiz uma dúzia de RPs personalizados, STSes personalizados, além de usar o ADFS como o STS confiáve

o entanto, tenho um requisito simples que ainda não cumpr

Eu quero que meus usuários sejam forçados a relogin depois de um tempo fixo. Digamos 1 minuto, para fins de teste.

Primeiro, fiz algumas correções no lado do RPs. Parece que, por motivo desconhecido, o RP retém a sessão mesmo que o @ do tokvalidTo aponta no tempo. Isso contradiz o que Vittorio Bertocci diz em seu livro (página 123), onde mostra como executar a expiração deslizante - ele diz que "O SessionAuthenticationModule cuidará do tratamento da sessão expirada logo após". Bem, para mim não, mas eu encontrei um truque aquihttp: //blogs.planbsoftware.co.nz/? p = 521 - veja a cláusula "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;
                }
            };

Este truque corrige o problema no lado dos RPs. Quando o token é inválido, o aplicativo o limpa e redireciona para a página de logi

gora vem o problema. Minha página de login usa oFederatedPassiveSignIn ao controle. Quando clicado, ele redireciona o navegador para o ADFS.

Mas o ADFS cria felizmente umnew session sem nenhum aviso para o usuário.

Definei a vida útil do token para este RP como 1:

Set-ADFSRelyingPartyTrust -Targetname "myrpname" -TokenLifetime 1

e usandoGet-ADFSRelyingPartyTrust Vejo que está definido como 1 (até imprimo o tokenvalidTo na minha página para confirmar se está definido corretamente

Em seguida, defino propriedades do ADFS comADFS-SetProperties:

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

mas ainda sem sorte. Estou preso agora.

O cenário funciona corretamente com meu STS personalizado, em que a validade da sessão STS se baseia em um cookie de Formulários - se eu definir o tempo limite do cookie de formulários do STS como 1, após 1 minuto de inatividade no aplicativo RP, sou redirecionado para a página de login do meu RP, que depois redireciona para o STS, que apresenta sua página de logi

No entanto, esse não é o caso do ADFS 2.0. Após um minuto de inatividade, sou redirecionado para a página de logon do meu RP, que é redirecionada para a página de logon do ADFS, que por sua vez é redirecionada de volta feliz, assim como a sessão ainda estaria ativa no ADF

Gostaria que alguém:

(1) dê uma olhada no hack descrito na parte superior e explique por que um token expirado não é automaticamente rejeitado e é necessário um hack tão feio

(2) explique como atingir o tempo limite da sessão corretamente no lado do ADFS 2.0, para que uma solicitação para renovar o token seja protegida com uma página de logi

Desde já, obrigado

edita

Posso confirmar que a definição de todos os parâmetros acima para 1 minuto invalida a sessão do ADFS após 5 minutos (ou mais). Essa é uma situação difícil e parece que estou cometendo um erro básico ou 5 minutos é o valor mínimo aceitáve

Meu (2) acima é agora apenas para confirmar e explicar minha observaçã