¿Cómo implementar SSO de inicio de sesión cruzado entre dominios y dominios sin redireccionamientos de navegador para usuarios no registrados?

Navega tus respuestas
4

Necesito implementar una solución SSO con los siguientes requisitos:

  1. Dominio cruzado: Supongamos que tengo a.com , b.com y sso.com . Si me conecto a través de a.com , no debería tener que iniciar sesión cuando visito b.com .
  2. Centralizado: el usuario no registrado que hace clic en "Iniciar sesión" en a.com muestra una pantalla de inicio de sesión alojada en sso.com . Las credenciales se verifican mediante sso.com en la fuente de datos a la que solo tiene acceso.
  3. Inicio de sesión automático: si el usuario ha iniciado sesión en a.com , y posteriormente visita b.com , iniciará sesión inmediatamente. Es decir, en b.com , en lugar de un enlace de "Inicio de sesión" Queremos mostrar de inmediato su nombre de usuario, etc., sin la necesidad de hacer clic en nada.
  4. No hay redireccionamiento para usuarios anónimos: la gran mayoría de mis usuarios usarán los sitios sin tener una cuenta. Por lo tanto, cuando llegan a a.com , o b.com , no debe haber un redireccionamiento rápido de toda la página a sso.com y volver a verificar si están conectados. Tal redirección sería perjudicial para SEO y latencia.

Para los pocos usuarios que han iniciado sesión en a.com y luego van a b.com (o viceversa), se acepta una redirección.

Hay muchos ejemplos en la web para SSO, especialmente con OAuth2, OpenID Connect y CAS, pero no pude encontrar una receta para estos requisitos específicos. La más cercana es la guía de SSO de Stackoverflow ( aquí ), pero tienen algunos requisitos adicionales que no tengo (por ejemplo, el inicio de sesión aún debería funcionar si el servidor SSO no funciona).

    
pregunta Jan Żankowski 18.12.2017 - 17:56
fuente

1 respuesta

2

Me parece que este esquema OpenID Connect debería hacerlo. Tenga en cuenta que no soy un experto en seguridad, así que no lo use sin más confirmación.

  1. El usuario no está conectado a a.com , b.com , sso.com .
  2. El usuario va a a.com , hace clic en "Iniciar sesión".
  3. Redirigir a sso.com , con la URL de retorno en a.com como parámetro.
  4. El usuario proporciona credenciales válidas. sso.com los acepta, redirige a a.com con el código de autorización como parámetro. También hay una cookie de sesión de SSO para sso.com en la respuesta de redireccionamiento.
  5. El navegador sigue la redirección, las consultas a.com . El servidor a.com envía el código de autorización a sso.com en el backend, recibe el token de acceso & ID Token, establece la cookie de sesión en a.com . El usuario ha iniciado sesión en a.com .
  6. El usuario va a b.com .
  7. Javascript en b.com realiza una llamada CORS AJAX silenciosa a sso.com , a un punto final personalizado (por ejemplo, sso.com/has-sso-session ). El punto final responde con esencialmente true / false basado en la presencia de cookie SSO en la solicitud.
  8. Si la respuesta es:
    • true , Javascript redirige el navegador a sso.com , con la URL de retorno en b.com como parámetro. Esto activa la autenticación regular de OpenID Connect, que será automática porque el usuario tiene una cookie de SSO. Al final, el servidor b.com envía el código de autorización a sso.com en el backend, recibe el token de acceso & ID Token, establece la cookie de sesión en b.com . El usuario ha iniciado sesión en b.com .
    • false , Javascript establece una cookie de sesión SSO check failed en b.com . Esto evita que se realicen más comprobaciones al navegar por b.com , a menos que el usuario haga clic en "Iniciar sesión".
respondido por el Jan Żankowski 18.12.2017 - 17:57
fuente

Lea otras preguntas en las etiquetas

¿Confía en las restricciones de nombre o en el anclaje de CA intermedio? ¿Mi ISP aloja malware o ha sufrido una toma de control de subdominio, o mi enrutador está comprometido?