Cómo establecer el tiempo de espera correctamente al federar con el ADFS 2.0

Question

Estoy usando ADFS 2.0 desde hace bastante tiempo y entiendo cómo funcionan las cosas. He hecho docenas de RP personalizados, STS personalizados y también uso el ADFS como el STS de confianza.

Sin embargo, tengo un requisito simple que aún no cumplo.

Quiero forzar a mis usuarios a relogin después de un tiempo fijo. Digamos 1 minuto, para propósitos de prueba.

Primero, he hecho algunas correcciones en el lado de los RP. Parece que por razones desconocidas, el RP retiene la sesión incluso si el token es validTo apunta hacia atrás en el tiempo. Esto contradice lo que dice Vittorio Bertocci en su libro (página 123) donde muestra cómo realizar la expiración deslizante: dice que "SessionAuthenticationModule se encargará de manejar la sesión caducada inmediatamente después". Bueno, para mí no lo hace, sin embargo he encontrado un truco aquí http://blogs.planbsoftware.co.nz/?p=521 - echar un vistazo a la cláusula "si":

 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 truco corrige el problema en el lado RPs. Cuando el token no es válido, la aplicación lo borra y lo redirecciona a la página de inicio de sesión.

Ahora viene el problema. Mi página de inicio de sesión utiliza el control FederatedPassiveSignIn. Al hacer clic, redirige el navegador al ADFS.

Pero ADFS felizmente crea una nueva sesión sin ningún aviso para el usuario.

he puesto toda la vida de la ficha de este RP a 1:

Set-ADFSRelyingPartyTrust -Targetname "myrpname" -TokenLifetime 1 

y el uso de Get-ADFSRelyingPartyTrust puedo ver que se establece en 1 (I incluso imprimir la ficha validTo en mi página de confirmar que esto se establece correctamente).

Entonces establecer las propiedades de AD FS con ADFS-SetProperties:

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

pero aún ninguna suerte. Estoy atascado ahora. El escenario funciona correctamente con mi STS personalizado donde la validez de la sesión STS se basa en una cookie Forms: si configuro el timeout de cookie de formularios de STS en 1, después de 1 minuto de inactividad en mi aplicación RP me redirigen a la página de inicio de sesión de mi RP que luego redirige al STS que presenta su página de inicio de sesión.

Sin embargo, este no es el caso con ADFS 2.0. Después de un minuto de inactividad, me redirigen a la página de inicio de sesión de mi RP que redirige a la página de inicio de sesión de ADFS, que a su vez redirige felizmente al igual que la sesión seguiría estando activa dentro de ADFS.

Me gustaría que alguien:

(1) echar un vistazo al truco descrito en la parte superior y explicar por qué un token caducada no es automáticamente rechazada y no se necesita tal truco feo

(2) explique cómo temporizar correctamente la sesión en el lado de ADFS 2.0 para que una solicitud de renovación del token esté protegida con una página de inicio de sesión.

Gracias de antemano.

edición

puedo confirmar que el ajuste de parámetros por encima de 1 minuto hace que la sesión de AD FS no válida después de 5 minutos (o más). Eso es extraño y parece que o bien estoy cometiendo un error básico o 5 minutos es el valor mínimo aceptable.

Mi (2) de arriba ahora es solo para confirmar y explicar mi observación.

Answer 1

De acuerdo con los comentarios anteriores (esfuerzo conjunto con el OP) la propiedad Freshness en el FederatedPassiveSignIn instancia debe ser fijado a 0.

Según http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.html esto indica para los IP/STS para volver a pedir al usuario para la autenticación antes de que emita el token.

Answer 2

También podría intentar cambiar ADFS de la autenticación integrada de Windows a la autenticación basada en formularios. Probablemente aún tendrá que usar la propiedad frescura, pero ahora sus usuarios deberán ingresar sus credenciales, incluso si están en la misma red que su AD.

En este artículo se explica muy sencillamente:

http://social.technet.microsoft.com/wiki/contents/articles/1600.aspx

Answer 3

Es bastante extraño que establecer el valor TokenLifetime no funcionaba. El article in MSDN explica el tiempo de espera como una configuración directa: asignando el valor TokenLifetime. Me interesa saber si la configuración descrita en MSDN es correcta. Si eso no ayudó, entonces es el momento de revisar ese artículo. Espero que sea una gran ayuda para aquellos que enfrentan este problema.