Impacto de SSO en el tiempo de espera de sesión

Question

Necesito implementar SSO entre un dominio de Windows y una aplicación web J2EE.

He estado pensando cuál sería el impacto de esto en el tiempo de espera de la sesión de la aplicación web. Tenemos un tiempo de espera de 2 horas.

Si implementamos un SSO sin par, entonces creo que podría resultar confuso para el usuario.

El SSO hará que parezca que la aplicación web está disponible de inmediato.

Me preocupa que comiencen a llenar formularios, luego vayan a almorzar (o algo así) y regresen después de que la sesión haya expirado. Sin embargo, puede que no sea evidente de inmediato que esto haya ocurrido, ya que el SSO simplemente los volverá a iniciar (pero ahora con una nueva sesión).

¿Alguien tiene alguna experiencia con algo como esto y cómo manejarlo? ¿Necesitamos implementar algún tipo de mensajería adicional para decirle al usuario que su sesión anterior ha caducado y que su trabajo se ha perdido?

Answer 1

Creo que definitivamente necesitas abrir un cuadro de alerta de algún tipo si se reinicia la sesión del usuario. Pídales que hagan clic en Aceptar en el mensaje y que los redirijan a la página de inicio.

Además, creo que un tiempo de espera de 2 horas parece una mala idea si lo estás haciendo como creo que estás. ¿Quiere decir que el usuario tiene 2 horas desde que inicia sesión para trabajar antes de que finalice su sesión? ¿No tendría más sentido tener un tiempo de espera de 10 minutos, pero con el temporizador restableciéndose cada vez que el usuario envía una nueva solicitud dentro de esa sesión?

Answer 2

El tiempo de espera no es un tiempo fijo estático medido desde el inicio de sesión, sino una medida dinámica de inactividad.

En los sitios que disponemos de esta funcionalidad después de 10 minutos aproximadamente, la página web vuelve a la página de inicio de sesión (uso de JS) y el usuario puede volver a comenzar si lo desea.

Si están ocupados con un proceso largo en el que están revisando los resultados o algo así, compruebe el movimiento del mouse o alguna tecla de sublte que indique que aún están ocupados.

Answer 3

Antigua pregunta, pero en caso de que alguien se la encuentre:

Intenta realmente no almacenar ningún estado en la sesión del servidor. Cliente, bien; La persistencia del servidor de back-end (como una base de datos), bien. Simplemente nada entre eso se perdería. Cuando el usuario vuelve a autenticarse sin problemas, no notan el cambio. La duración del tiempo de espera se vuelve irrelevante.

Esta respuesta es en realidad más factible ahora, seis años después, ya que hay varios marcos front-end que almacenarán sus datos por usted. Puede seguir utilizando Spring Security (por ejemplo) en el servidor, ya que la autenticación sigue existiendo. la nueva sesión; debe regenerar su información de seguridad (SecurityContext, UserDetails, etc.) sobre la marcha. Cualquiera que sea la solicitud que reciba o envíe datos, entonces "simplemente debe funcionar". & Quot;