authentication - Sesión de usuario transparente en varios sitios(inicio de sesión único y cierre de sesión único)

session single-sign-on (7)

¿Estás usando ASP.NET? Si es así, es posible que desee echar un vistazo a la propiedad enableCrossAppRedirects .

Tengo varios sitios en diferentes dominios: example.com , example.org , mail.example.com y passport.example.org . Todos los sitios tienen una apariencia común y deberían compartir la misma base de usuarios.

Y en un caso tan extremo, aún quiero que todos los sitios de manera transparente (tanto como sea posible) compartan sesiones de usuario con las siguientes propiedades clave:

Inicio de sesión único . Cuando el usuario inicia sesión en passport.example.org y visita cualquier otro sitio, se le debe tratar como iniciado sesión.
Los usuarios que han iniciado sesión reciben el saludo "Hola, $username " en el encabezado del sitio y en el menú de navegación diferente, que enumera los servicios a los que tienen acceso. Si no ha iniciado sesión, en lugar de saludar hay un enlace "Iniciar sesión", que apunta a passport.example.org/signon .
La lista de dominios de confianza es conocida, por lo que es bastante fácil de implementar ya sea con OpenID o con algún protocolo ligero de fabricación casera. Cuando el usuario ingresa al sitio por primera vez, lo redirijo al punto extremo de autenticación especial en passport.example.org , que luego lo redirige silenciosamente de regreso, con información de identidad (o identidad anónima "sin iniciar sesión") incluida. Para la mayoría de los navegadores esto es completamente transparente. Obviamente, estoy usando valores de nonce para luchar contra los bucles de redirección.
Single sign-off . Cuando el usuario hace clic en "cerrar sesión" en el encabezado de cualquier sitio la próxima vez que visita un sitio, debe ser visto como "no iniciar sesión".
OpenID no fue diseñado para esto. Mi idea actual (ya tengo una implementación que funciona parcialmente) es enviar no identidad de usuario, pero token de sesión "global" y compartir tabla de sesiones globales (global_session_token ↔ relación de usuario) en DB.
Robots y usuarios sin cookies . Los sitios tienen áreas públicas a las que los usuarios-agentes deben tener acceso sin ningún tipo de soporte de cookies.
Debido a esto, la redirección que mencioné en (1) se convierte en un problema, porque por cada solicitud de página, terminaré lanzando user-agent a auth endpoint y viceversa. No solo esto confundirá a los robots, sino que contaminará mi base de datos de sesiones con sesiones muertas muy rápidamente. Y definitivamente no quiero mostrar la página "¡oye, no tienes las cookies habilitadas, vete!", Eso sería extremadamente grosero y decepcionante. Si bien necesito el soporte de cookies para iniciar sesión, quiero que los usuarios lean libremente para qué son los sitios, etc., sin restricciones.
Y explícitamente no quiero poner identificadores de sesión en las URL a excepción de algunas redirecciones transparentes entre dominios que he mencionado. Creo que hacerlo es un problema de seguridad y, en general, es algo malo.
Y aquí estoy casi sin ideas.

De acuerdo, sé que esto es difícil, pero Google en realidad lo hace de alguna manera con ( google.com , google. Lot-of-gTLDs , gmail.com , etc.), ¿verdad? Entonces esto debería ser posible.

Agradecería tanto las ideas de descripción de protocolo (que sería lo mejor) o los enlaces a los sistemas (ya sea para leer o solo para ver y aprender) que ya implementaron algo como esto.

Para resumir: varios dominios sin raíz común, base de usuarios compartidos, inicio de sesión único, inicio de sesión único, no se requieren cookies para navegar de forma anónima.

Todos los sitios están en la misma red (pero descansan en servidores diferentes) y comparten parcialmente la misma base de datos PostgreSQL (descansando en los diferentes esquemas de la misma base de datos). La mayoría de los sitios están escritos con Python / Django, pero algunos usan PHP y Ruby on Rails. Si bien estoy pensando en algo que no se base en el marco ni en el lenguaje, estoy agradecido por señalar cualquier implementación. Incluso si no podré usarlos, si tengo la idea de cómo se hace, tal vez pueda implementar algo similar.

AFAIK, Google solo usa una cookie para el dominio "Google.com". Pero Google también usa OpenID que permite un mecanismo de inicio de sesión genérico. Básicamente, esto funciona al redirigirlo a una página de inicio de sesión especial. Esta página de inicio de sesión detectará si ha iniciado sesión o no y, si no ha iniciado sesión, le pedirá que inicie sesión. De lo contrario, simplemente lo redireccionará directamente a la página siguiente.

Entonces, en su caso, un usuario abriría una página.ejemplo.com y la sesión de esta aplicación no tiene una ID de inicio de sesión. Por lo tanto, redirigiría al usuario a logon.example.biz, donde el usuario iniciará sesión. Detrás de esta página también estaría una sesión y esa sesión indicaría que el usuario ya ha iniciado sesión. (O no, en cuyo caso el usuario debe inicie sesión primero.) Luego redirecciona al usuario a somepage.example.com?sessionid=something donde este sessionid se almacenará en la sesión de somepage.example.com. Luego, esta sesión también sabrá que el usuario ha iniciado sesión y que para el usuario casi parece transparente.

En realidad, el usuario se redirige dos veces.

Bueno, déjame explicarte un poco más. (¡Todas las URL son ficticias!) Como dije, el visitante va a http://www.yourwebpage.com e indica que quiere iniciar sesión. Se le redirige a http://your.loginpage.org?return=http: //www.yourwebpage.com/Authenticated donde tendrá que proporcionar su nombre de usuario y contraseña.
Cuando la información de su cuenta sea válida, volverá a la página que se proporcionó en la URL de inicio de sesión, pero con un parámetro adicional que se usará como ID. Por lo tanto, él va a http://www.yourwebpage.com/Authenticated?ID=SharedSecret donde SharedSecret sería una identificación temporal, válida por 30 segundos o menos.
Cuando se llama a su página de autenticación, la página llama a un método que se comparte entre yourwebpage.com y loginpage.org para buscar la información de la cuenta de SharedSecret para recuperar una identificación más permanente. Esta identificación permanente se almacena en la sesión web de yourwebpage.com y NUNCA se debe mostrar al usuario.
El método compartido podría ser cualquier cosa. Si ambos servidores están en la misma máquina, ambos podrían acceder a la misma base de datos. De lo contrario, podrían comunicarse con otro servidor a través de servicios web. Esta sería la comunicación de servidor a servidor, por lo tanto, no importa si el usuario es un robot o no tiene soporte para cookies. Esta parte no será notada por el usuario.
Lo único que tendrá que tratar es la sesión para el usuario. Normalmente, a los usuarios se les enviará una ID de sesión almacenada en una cookie, pero también puede ser parte de la URL como parte de una solicitud GET. Sin embargo, es un poco más seguro tener el ID de sesión dentro de una solicitud POST, agregando un campo de entrada oculto a su formulario.

Afortunadamente, varios lenguajes de desarrollo web ya ofrecen soporte de sesión, por lo que ni siquiera tiene que preocuparse por mantener las sesiones y enviar ID de sesión. La técnica es interesante, sin embargo. Y debe tener en cuenta que las sesiones siempre deben ser temporales, ya que existe el riesgo de que las identificaciones de la sesión sean secuestradas.

Si tiene que ocuparse de varios sitios en dominios diferentes, primero tendrá que trabajar en una comunicación de servidor a servidor. Lo más fácil sería permitirles compartir la misma base de datos, pero es mejor construir un servicio web alrededor de esta base de datos para obtener protección adicional. Asegúrese de que este servicio web solo acepte solicitudes de sus propios dominios solo para agregar incluso un poco más de protección.
Cuando tiene conexiones de servidor a servidor, el usuario podrá cambiar entre sus dominios y, siempre que esté transfiriendo una ID de sesión al nuevo dominio, el usuario iniciará sesión. Si el usuario está utilizando cookies, no es muy probable que la sesión se pierda, lo que requeriría iniciar sesión de nuevo. Sin cookies, existe la posibilidad de que el usuario tenga que iniciar sesión de nuevo para obtener una nueva cookie si la ID de la sesión se pierde entre las páginas de navegación. (Por ejemplo, el visitante va a visitar Google y luego vuelve a su sitio. Con una cookie, la sesión se puede leer desde la cookie. Sin una cookie, la sesión se pierde porque Google no reenviará la identificación de la sesión.

Tenga en cuenta que transmitir los ID de sesión entre diferentes dominios es un riesgo de seguridad. La identificación de la sesión puede ser secuestrada, lo que hace posible que otra persona suplante a su visitante. Por lo tanto, las ID de sesión deben ser de corta duración y ofuscadas. Pero incluso si un hacker obtiene acceso a una ID de sesión, todavía no tendrá acceso completo a la cuenta en sí. No podrá interceptar la comunicación de servidor a servidor para que no pueda acceder a la base de datos con su información de usuario, a menos que vaya directamente a la página de inicio de sesión.

He usado shibboleth, tanto para escenarios SSO como para Federated Identity, pero supongo que necesita soluciones más simples que las mencionadas anteriormente.

Para esta solución no es necesario el servidor de pasaportes.

Registrarse

Iniciar sesión
Crear token con identificación de sesión cifrada y otra información
Muestra img con token de todos tus dominios para configurar cookies en su.

Autorización por cookie

Usted ya tiene cookies en todos los dominios.

desconectar

Borrar la cookie
Destruye la sesión
Borrar la identificación de usuario de la relación con la última identificación de sesión en DB (creo que guarda la identificación de la sesión en la tabla de usuario para la sesión de aumento por cookie)

No puedo probar esta solución. Pero ahora tengo el mismo problema que usted (SSO) y lo intento mañana.

Si todas sus aplicaciones están en un dominio, entonces no es demasiado difícil porque puede usar una cookie de nivel de dominio para manejar el control de la sesión. (La gestión de sesión sin cookies es difícil, pero puede hacerse, pero es difícil).

Sin embargo, indicó algunos sitios en el dominio example.com y algunos en el dominio example.org.

Jugando un poco con mi suspiro de google y otros sitios de ellos orkut.com, parece que cuando accedes a una página que necesita credenciales, te redirige a un sitio común para iniciar sesión, que luego te redirecciona al original sitio, presumiblemente pasando algún tipo de token de sesión en la URL. A partir de esto, presumiblemente, los servidores de orkut.com consultan directamente con los servidores de google.com para verificar el token y obtener cualquier otra información del usuario que se necesite.

Más información sobre las cookies de nivel de dominio según se requiera

Si tiene dos sitios, digamos foo.example.com y bar.example.com, puede establecer una cookie específica para el host, pero también puede establecer una cookie para el dominio que todos los hosts del dominio vean.

Por lo tanto, foo.example.com puede establecer una cookie para foo.example.com específicamente, y solo se verá por sí mismo, pero también puede establecer una cookie para el dominio example.com, y cuando el usuario vaya a la bar.example.com también verán esta segunda cookie.

Sin embargo, si también tiene un sitio, snafu.example.org, no puede ver esta cookie de nivel de dominio que foo estableció, porque example.org y example.com son dos dominios completamente diferentes.

Puede usar la cookie de nivel de dominio para mantener la información de la sesión en todos los sitios en el mismo dominio.

La forma de configurar las cookies de nivel de dominio depende de su entorno de desarrollo (no tengo experiencia con los rieles, lo siento).

Un plugin de raíles con dominio cruzado para hacer esto sería increíble.

Me gustaría hacerlo, la única forma en que podría pensar era forzar al usuario a descargar una barra de herramientas, o alguna pequeña aplicación de aire que manejaría el inicio de sesión automáticamente para mí.

Me encantaría saber otra manera porque eso sopla