Sesiones del lado del cliente

Question

Quiero que los clientes de varias aplicaciones web relacionadas mantengan su propio estado de autenticación. Esto mejora la escalabilidad, ya que no se necesita replicación de sesión entre los nodos del clúster. Y facilita la integración de diferentes tecnologías de servidor como Java Servlets y PHP.

Mi plan es el siguiente:

1. establecer una cookie firmado y cifrado con el nombre de usuario y una sesión de tiempo de caducidad después de la autenticación del cliente.
2. Cuando el cliente envía una solicitud, el servidor descifra y valida la cookie y otorga o deniega el acceso según los valores de la cookie.
3. La caducidad de la sesión se actualizará restableciendo la cookie.

Todos los servidores que desean utilizar la sesión solo tienen que conocer el mecanismo de la cookie y la clave de descifrado. Ver también: Session state in the client tier

¿Este enfoque está bien? ¿Sería posible integrarlo en un servlet container/servidor de aplicaciones para que sea transparente para las aplicaciones? Un servlet debería ser capaz de usar HttpServletRequest # getRemoteUser() por ejemplo. es posible? ¿O necesitaría algo más que el nivel de contenedor como Spring Security? ¿Hay alguna biblioteca existente para la administración de la sesión del lado del cliente?

Answer 1

No es una buena idea. Almacenar datos vitales como el vencimiento de la sesión y el nombre de usuario completamente en el lado del cliente es demasiado peligroso, cifrado o no. Incluso si el concepto es técnicamente seguro en sí mismo (no puedo responderlo en profundidad, no soy un experto en cifrado), se podría facilitar un robo sin comprometer su servidor, simplemente adquiriendo su clave de cifrado.

Alguien que se apodera de la llave podría generar cookies de sesión a voluntad, hacerse pasar por cualquier usuario para cualquier longitud de tiempo, algo que el concepto de sesión clásica está diseñado para prevenir.

Existen soluciones mejores y escalables para este problema. ¿Por qué no, por ejemplo, configurar una instancia de verificación de sesión central que todos los servidores y servicios asociados pueden sondear? Mire a su alrededor en la web, estoy 100% seguro de que hay soluciones listas para sus necesidades.

Answer 2

Esto no es realmente cómo se implementan las sesiones. La cookie en sí no necesita llevar ningún dato de la sesión en sí, es solo una referencia.

Lo que la cookie contiene es generalmente un Session ID que luego se vincula a los datos en el servidor.

Si no tiene un servidor central de sesión de datos para el acceso de los otros servidores, le sugiero que obtenga uno :).

Answer 3

Puede evitar la duplicación de datos en un entorno en clúster utilizando un servidor de estado, un servidor que es bien conocido por todos los nodos en los clústeres y mantiene los datos de la sesión para todos los usuarios. Cada vez que un usuario realiza una solicitud, envía una cookie con la identificación de sesión al servidor de aplicaciones; este debería recuperar la sesión del servidor de estado. Esto es posible para el desarrollo de asp.net, pero no estoy seguro de cuán fácil es la compatibilidad de Java con este enfoque.

Answer 4

Esto mejora la escalabilidad, porque no se necesita replicación de sesión entre los nodos del clúster.

En primer lugar, el uso de sesión HTTP en realidad no le impide escalar, incluso cuando se utiliza la replicación HTTP estado de sesión (algunos mecanismos son más inteligentes que otros por la forma, por ejemplo de WebLogic in-memory replication no tiene una gran sobrecarga) . En segundo lugar, ¿realmente lo necesitas? La mayoría de las aplicaciones (la mayoría) no necesitan replicación de sesión. Tercero, estoy entendiendo bien: ¿planea no usar la sesión HTTP en absoluto?

(...) Establezca una cookie firmada y cifrada con el nombre de usuario y el tiempo de expiración de la sesión después de la autenticación del cliente.

¡No hagas esto! No almacene un nombre de usuario y otros datos sensibles utilizados por el servidor en una cookie, ¡esta es una muy mala idea! De hecho, debe admitir que es solo cuestión de tiempo antes de que alguien descubra cómo funciona su sistema y lo rompa (especialmente si su cookie es candidata para ataques crib). Sor, de verdad, deberías almacenar datos en la Sesión en el lado del servidor y solo una ID en la cookie, como si las cosas estuvieran realmente funcionando. Esto es mucho más seguro.

¿Este enfoque está bien?

Nº Y no es necesario esto para interoperable single-sign on (si esto es lo que está tratando de construir). Solo use una solución de autenticación centralizada como CAS Jasig que tiene bibliotecas para diversas tecnologías.

Answer 5

Como dijo Pekka, no es una buena idea. Uno puede interceptar su cookie con datos de sesión confidenciales. Incluso con SSL, al usar fiddler2 uno puede decrypt el tráfico

Answer 6

No estoy de acuerdo con los carteles que dicen que este enfoque no es seguro. Las variantes se utilizan en una serie de marcos muy respetados, como Rails y Play !, precisamente por los motivos que delineas, y es perfectamente seguro cuando se implementa correctamente.