Inicio de sesión unificado

Contexto

En MENU, tenemos muchos dominios diferentes que respaldan distintas funcionalidades y productos dentro de nuestro ecosistema. Esto significa que, cada vez que cambies de un dominio a otro, debes iniciar sesión en cada uno de ellos.

Esto, junto con la migración de CMS al Centro del gestión, nos hizo reflexionar en la misma cuestión de siempre: debemos simplificar esta tarea.

Para cumplir con ese lema, desarrollamos un inicio de sesión unificado para todos los usuarios. Es nuestra versión del inicio de sesión único o SSO, que seguro que ya has visto antes. Esto significa que, ahora, puedes visitar un único punto y acceder allí a todos los dominios de confianza.

Ten en cuenta que, por el momento, esto solo se aplica al CMS y al Centro de gestión. Tendrás la opción de que se te redirija a otras apps de MENU, pero aún deberás iniciar sesión en ellas hasta que se incluyan en el SSO.

¿Qué es el inicio de sesión único (SSO, en inglés)?

El SSO es una solución de integración común utilizada en todo el mundo por muchas empresas de todo tipo y tamaño. Un sistema SSO proporciona una autenticación con inicio de sesión unificado para sistemas de apps. Los usuarios pueden iniciar sesión una vez y obtener acceso a todos los sistemas de apps de confianza.

¿Qué ventajas ofrece?

El SSO mejora la experiencia de usuario y reduce los riesgos de seguridad y los costos de gestión. Se ahorra tiempo porque solo inicias sesión una vez a través de la “puerta principal”, y esa puerta entiende que las apps y los sitios web seleccionados son seguros, por lo que simplemente puedes entrar en todos aquellos que son de confianza.

Este es el aspecto de la lista de apps de confianza (esquina superior derecha del Centro de gestión). En MENU, la llamamos bandeja de apps o bandeja de aplicaciones.

Consulta este artículo para obtener más información.

Ten en cuenta que, como hemos mencionado, el inicio de sesión unificado funciona actualmente para el Centro de gestión y el CMS. Puedes acceder al Centro de personalización, al sitio web de marketing y a la Knowledge Base desde este panel de administración en el Centro de gestión. Sin embargo, por ahora, debes iniciar sesión hasta que se incluyan en el SSO.

Además, no tienes que preocuparte por la seguridad. No solo se trata de un “círculo cerrado” de confianza entre esa puerta principal y otras herramientas, sino de un solo círculo, sin una multitud de credenciales y contraseñas para recordar.

Seguridad

Pongámonos técnicos por un segundo. El sistema SSO se compone del servidor de SSO y los clientes de SSO. El servidor de SSO y los clientes de SSO autentican juntos las solicitudes de inicio de sesión. El servidor de SSO genera y gestiona los certificados. Los clientes de SSO se despliegan con los sistemas de apps para proporcionar interfaces de autenticación de certificados, de modo que dichos sistemas se comuniquen con el servidor de SSO.

Flujo de autenticación detallado

Hablemos ahora en términos más sencillos. Aquí te explicamos lo que sucede en realidad y debajo incluimos un diagrama que lo representa:

1. Un usuario va a la app en la que quiere iniciar sesión: el CMS. El CMS es, en este caso, el proveedor de servicios.
   
   

2. El proveedor de servicios (CMS) envía un token que contiene información sobre el usuario (dirección de correo electrónico y el encabezado application_key de ese usuario) al sistema SSO: el proveedor de identidad o servicio de autenticación. En este caso, es el Centro de gestión. Así que el CMS le solicita al Centro de gestión que autentique ese usuario en su nombre, a fin de saber si puede o no concederle acceso.

   • El proveedor de identidad (Centro de gestión) comprueba primero si el usuario ya se ha autenticado.
     Si esto es así, entonces concederá al usuario acceso al proveedor de servicios (CMS).
     Ten en cuenta que, si el usuario ya se ha autenticado, esto se denomina sesión global. A continuación, el servidor envía el token de autenticación a “domain1”, y las cookies de sesión se guardan en el almacén de cookies del navegador. En este caso, el siguiente paso es el 5.

   • Si el usuario no ha iniciado sesión (es decir, no se ha autenticado todavía), se le pedirá que lo haga. Para ello, deberá proporcionar las credenciales solicitadas por el proveedor de identidad (Centro de gestión). En el caso de MENU, se trata simplemente de la dirección de correo electrónico para generar el enlace mágico sin contraseña. En este caso, el siguiente paso es el 3.
     
     

3. El proveedor de identidad (Centro de gestión) envía la dirección de correo electrónico y el encabezado application_key del usuario para verificar las credenciales. El servicio de autenticación enviará un token firmado al proveedor de servicios (CMS) para confirmar que este usuario se ha identificado correctamente y se le puede conceder acceso.
   
   

4. Se redirige al usuario al dominio original (CMS). El token se transmite a través del navegador del usuario al proveedor de servicios (CMS). En nuestro caso, devolveremos un JWT (JSON Web Token) firmado con la información del perfil del usuario si la validación se realizó correctamente.
   
   

5. El token que recibe el proveedor de servicios (CMS) se valida según la relación de confianza establecida entre dicho proveedor (CMS) y el proveedor de identidad (Centro de gestión) durante la configuración inicial. A continuación, crea una sesión local en función de la carga de JSON Web Tokens. La cookie del CMS también se almacena en el navegador.
   
   

6. El usuario obtiene acceso al proveedor de servicios (CMS).
   
   

7. Cuando el usuario intenta acceder a un proveedor de servicios diferente del CMS, este se trata como un nuevo proveedor de servicios. Esto significa que debe tener una relación de confianza similar configurada con la solución SSO. Si esto es así, el flujo de autenticación seguirá los mismos pasos.