Abrir el navegador con un usuario ya autenticado en otra aplicación

Question

Abrir el navegador con un usuario ya autenticado en otra aplicación

#1 de ThoriumBR (1 votos)
#2 de Enos D'Andrea (0 votos)

0

Escenario: He iniciado sesión en alguna aplicación (java - swing). La autenticación es típica: inicio de sesión y contraseña verificada por el servidor (J2EE) en el inicio de la aplicación cliente, después de ese trabajo normal en la aplicación que incluye muchas solicitudes / respuestas:

Client <------------------> Server1

Ahora, quiero hacer algo como esto: el usuario hace clic en algún botón de la aplicación y después de eso, la aplicación abre el navegador de Internet predeterminado con alguna URL que apunta a otro servidor www ( Servidor2 ) pero con "contexto / sesión de usuario" para un mayor procesamiento (enviando la solicitud a Servidor1 ), como esto:

Client -----> Browser -----> Server2 -----> Server1

La página debe "capturar" el ID de sesión del usuario del cliente actual (tipo de inicio de sesión único). Que yo sepa, no es capaz de iniciar el navegador con la cookie creada "justo antes de comenzar", por lo que la idea es:

Abrir el navegador con / Server2ServiceUrl / JSESSIONID.
El navegador va a Server2ServiceUrl.
El usuario está realizando algunas operaciones en la página (rellenando el formulario) y haciendo clic, por ejemplo, en "Guardar botón" en esta página.
El resultado se solicita a Server2.
Server2 crea una cookie de sesión (JSESSIONID) basada en JSESSIONID en su url inicial y envía una solicitud a Server1 con una cookie de sesión (en el encabezado HTTP "Cookie") para que Server1 sepa qué usuario envía la solicitud.

Por supuesto que está muy lejos para estar seguro. Uno de los grandes problemas es el ID de sesión visible todo el tiempo en la barra de direcciones del navegador. Una de las ideas para aumentar un poco la seguridad es:

El navegador va a Server2Url, pero no al servicio, solo a alguna URL que:
- creará una cookie de sesión del navegador basada en JSESSIONID en la url inicial
- enviará un comando de redirección al navegador.
El navegador crea una cookie de sesión y redirige al servicio (Server2ServiceUrl). Debido a eso, el ID de sesión será visible en la barra de direcciones del navegador solo hasta la redirección.

Pero todavía siento que este concepto debería ser más seguro. ¿Que debería hacer entonces? Tal vez es alguna técnica estándar para resolver este problema?

web-browser cookies session-management single-sign-on

pregunta Buffalo 05.11.2017 - 01:44

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-browser cookies session-management single-sign-on

Reemplace IPSEC VPN con Shadowsocks, ¿es lo suficientemente seguro? ¿Es esta política de datos suficiente para mi pequeña empresa nómada?

score 1 · Answer 1

Tan pronto como el usuario haga clic en el botón, cree un token largo de uso único aleatorio y envíelo al servidor (algo como yourdomain.com/setsession?session=SESSIONID&single-use-token=TOKENID . Este token se usará más adelante para recuperar el ID de sesión.

Después de eso, la aplicación inicia un servidor HTTP muy simple y sirve su propia página HTML en el navegador predeterminado. Esta página se redireccionará a yourdomain.com/getsession?token=single-use-id , que a su vez abrirá la página deseada y establecerá la cookie de sesión.

El componente getsession realizará una búsqueda del token, y si proviene de la misma IP que setsession , eliminará el token y enviará las cookies de la sesión al navegador.

Con los tokens de autodestrucción, no tienes que preocuparte por los ataques de repetición y la reutilización del token, incluso si alguien ve el token.

score 0 · Answer 2

Para poder transmitir de forma segura un ID de sesión desde Spring a través del navegador local, puede crear una página HTML local con un formulario de envío automático y un valor de campo oculto establecido en el ID de sesión, luego simplemente abra esta página con el navegador.

Para hacer las cosas más seguras, puede proporcionar el ID de sesión a la página a través de un servicio web local, para que nunca se almacene en el disco.

En cualquier caso, incluso muchos sistemas de autenticación central utilizan tokens dentro de las solicitudes GET, por lo tanto, a menos que necesite seguridad de grado militar, abrir una URL GET con token incrustado debería funcionar bien.