Autenticación entre múltiples sistemas / plataformas dentro del mismo contexto de aplicación web

• Genera un token de sesión al iniciar sesión.
• Almacene ese token de sesión en la base de datos.
• Comprueba si hay tokens de sesión válidos al autenticar.

Mucho más de lo que tienes. Solo considere si desea tener más de una sesión válida a la vez y cómo va a terminar las sesiones.

EDITAR para el hilo de comentarios loco a continuación

Si bien uno puede proporcionar tokens al cliente que son verificados por el segundo servidor sin comunicarse con el primer servidor, eso es feo e implica mucho trabajo. Tal escenario no permite invalidar sesiones a menos que el cliente se encargue de ello. También requiere una cierta ventana de tiempo cuando se pasan tokens, sello de tiempo de tokens, seguimiento de tokens por el segundo sistema, firmas o HMAC en el token pass, etc. ese lío por completo.

Supongo que ambos sistemas pueden acceder a la misma base de datos, pero si por alguna razón no pudieran hacerlo, sería apropiado tener una API expuesta al segundo sistema que puede verificar de forma remota (secret.page?checkUser=token). .. o tal).

Sin SSL, no hay nada que puedas hacer para evitar el secuestro de sesiones mediante los ataques Firesheep / MITM.

Mi recomendación es una aplicación web única que se utiliza para la autenticación del usuario principal.

Nota: Debido a la naturaleza de las cookies, este método solo funcionará si las aplicaciones web comparten un dominio común. (es decir, appone.example.com y apptwo.example.com)
openid hace algo similar, pero evita el problema de las cookies, es posible que desee buscar en un sombrero.

Cómo funcionaría esto.

1. El usuario apunta su navegador hacia la aplicación A. La aplicación A comprueba si hay una cookie / sesión / lo que sea válida.
   1. Primero comprueba su propia sesión / información de cookies.
   2. Si no puede encontrar su propia cookie, busca la cookie de "transferencia" de la aplicación Auth.
      1. Si se encuentra, crea una nueva sesión para esta aplicación. El usuario acaba de iniciar sesión.
2. Cuando encuentra que esto no es válido o falta, reenvía la página hacia la aplicación de autenticación.
3. La aplicación Auth comprueba si hay una sesión válida en su extremo.
   1. Cuando descubre que falta, aparece una pantalla de inicio de sesión, etc.
4. Una vez que tiene una sesión válida, la aplicación Auth establece una "transferencia" específica cookie para esa aplicación y redirige a la persona a la Aplicación A.

Debería incluir información adicional en esta cookie de transferencia, como por ejemplo:

1. nombre de usuario
2. AuthTime
3. dirección IP.
4. Número aleatorio.

Vea lo siguiente para un ejemplo. enlace

Esto será casi imperceptible desde la perspectiva del usuario. Por ejemplo.

1. El usuario apunta su navegador hacia la aplicación A.
2. La aplicación A hace su baile de autenticación con la aplicación Auth. (requiere que el usuario inicie sesión, etc.)
3. El usuario hace clic en un enlace que reenvía a la aplicación B.
4. La aplicación B hace su baile de autenticación con la aplicación Auth. (Esta vez, la aplicación Auth ya tiene una cookie para sí misma).
   1. La aplicación B reenvía a la aplicación Auth.
   2. La aplicación Auth encuentra la cookie y, de inmediato, crea una cookie de transferencia y la envía a la App B.
   3. El usuario ni siquiera se da cuenta de esto y se encuentra en la aplicación B de inmediato.

Cuatro opciones, la primera con el costo máximo (dinero y rendimiento) y la tercera más barata

1. Implementar soluciones como Siteminder, Novell, Tivoli, etc.

2. Mantener el estado de la sesión en DB. Por hacer esto. El problema con este enfoque es que sería difícil hacer un seguimiento de las desconexiones, la caducidad de la sesión y la propagación de esta información entre las dos aplicaciones. Como consultar la base de datos antes de cada solicitud sería muy costoso

3. Usando una tercera aplicación solo para administrar los estados de la sesión. Esta aplicación no está expuesta al usuario final solo restringida dentro de la red con acceso solo a las dos aplicaciones. Almacena los estados para todos los usuarios en el contexto de la Aplicación y las dos aplicaciones envían una solicitud a esta aplicación

     

   En eventos de inicio de sesión   En eventos de cierre de sesión   En eventos de expiración de sesión   antes de procesar cualquier solicitud para verificar la validez de la sesión

4. Uso de una cookie (con el supuesto de que ambas aplicaciones comparten el mismo dominio principal)

     

   Cree una cookie que contenga el nombre de usuario + salt / ecret clave y este cifrado   La clave secreta y las claves de cifrado son con ambas aplicaciones   Cualquier solicitud del usuario llevará esta cookie (ruta de la cookie establecida en /)   Entonces, si la cookie contiene un nombre de usuario, otra aplicación confía en que el usuario ha iniciado sesión en otra aplicación