security - mensaje - comandos cluster linux

Inicio de sesión de dominios cruzados: cómo iniciar sesión automáticamente cuando se transfiere de un dominio a otro (5)

¿Qué hay de SEO? Parece que cada solicitud antes del inicio de sesión exitoso se redirige a otro dominio y viceversa. Diría que esto es muy feo. ¿Qué encabezados deberías enviar? 301 a SSO y luego 301 a la página original? Entonces, ¿el bot de búsqueda es "solicitado" para cambiar su índice para esa página dos veces?

Ofrecemos una serie de servicios en línea. Estamos obligados a desarrollar un sistema que proporcione una experiencia rápida / simple para los usuarios si se transfieren de un servicio (en domain1.com ) a otro servicio (en domain2.com ).

¿Existe una forma segura de iniciar sesión automáticamente en un usuario una vez que ha sido transferido al nuevo servicio?

Grítame si la solución a continuación es completamente insegura / incorrecta.

Estábamos considerando un sistema similar al proporcionado por una serie de servicios en línea para la recuperación de contraseñas: reciben un correo electrónico con un hash único que caduca y les permite cambiar su contraseña.

El domain1.com generaría un hash único y lo almacenaría en una base de datos con el hash vinculado a un usuario junto con un campo de fecha y hora de caducidad.

El usuario será transferido a domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

domain2.com luego haría una solicitud a domain1.com con el hash para obtener la información sobre el usuario. domain1.com eliminaría el hash de la base de datos. domain2.com registraría al usuario y establecería cookies, etc.

¿Podría algo basado en OpenID u OAuth lograr los mismos resultados?

Esta es una buena solución. Aquí hay dos puntos a considerar:

Usas el término "hash", pero no está claro qué datos hash. En su lugar, use un "nonce": un número grande (128 bits) generado por un RNG de calidad criptográfica.

Además, no especificó esto, pero las comunicaciones entre el usuario y ambos dominios, y entre los dominios en sí, deben ser seguras. Use SSL para autenticar los servidores y mantener la privacidad confidencial.

No tendría sentido usar SSL para el inicio de sesión entre dominios a menos que use SSL para toda la sesión. Es tan fácil robar una cookie de sesión como usar un hash en una url. ¿Cuál es el sentido de ocultar el hash en SSL si el resto de la sesión no es seguro?

El método dado en la parte superior es más o menos el método estándar. Si elige usar protocolos seguros es otro asunto completamente diferente, pero sería inútil cifrar solo parte de la sesión.

Si alguien pudiera jugar al hombre en el medio y agarrar ese hash, ¿sería capaz de robar la transferencia de dominio cruzado? Obviamente, debe generarse y enviarse al cliente antes de que necesite usarlo. Así que di por ejemplo:

Estoy jugando al hombre en el medio espiando a Jack. Jack accede a domain1.com que hace que se prepare y se le envíe un hash para que cuando acceda a domain2.com pueda enviar ese hash como autenticación. A medida que accede a domain1.com , su solicitud me llega, usted devuelve la página, agarro el hash y lo dejo continuar. domain2.com a domain2.com usando el hash, ahora me has dejado entrar en domain2.com y domain2.com eliminado el hash. Él no es más sabio hasta que intenta iniciar sesión en domain2.com y se le dice que sus credenciales ya no son válidas.

¿Cómo superas eso?

El inicio de sesión único (SSO) es conceptualmente muy simple.

El usuario domain1.com .
domain1.com ve que no hay una cookie de sesión.
domain1.com redirige a sso.com
sso.com presenta la página de inicio de sesión y toma credenciales
sso.com establece una cookie de sesión para el usuario
sso.com luego redirige a domain1 a una url especial (como domain1.com/ssologin )
la URL ssologin contiene un parámetro que básicamente está "firmado" por sso.com . Podría ser tan simple como una base64 de encriptación del loginid usando una clave secreta compartida.
domain1.com toma el token cifrado, lo descifra, utiliza el nuevo ID de inicio de sesión para iniciar sesión en el usuario.
domain1 establece la cookie de sesión para el usuario.

Ahora, el próximo caso.

El usuario domain2.com , que sigue a domain1 y redirige a sso.com
sso.com ya tiene una cookie para el usuario, por lo que no presenta la página de inicio de sesión
sso.com redirige a domain2.com con la información encriptada
domain2.com inicia sesión en el usuario.

Esa es la base de cómo funciona esto. Puede hacerlo más robusto, más rico en funciones (por ejemplo, este es SSOn , pero no SSOff , el usuario puede "cerrar la sesión" de domain1 , pero aún debe iniciar sesión en domain2 ). Puede usar claves públicas para firmar credenciales, puede tener solicitudes para transferir más información (como derechos de autorización, etc.) desde el servidor SSO. Puede tener una integración más íntima, como los dominios que comprueban rutinariamente que el usuario todavía tiene derechos del servidor SSO.

Pero el intercambio de cookies a través del navegador utilizando redireccionamientos es la base clave en la que se basan todas estas soluciones de SSO.