En las primeras etapas del desarrollo empresarial, las empresas utilizan muy pocos sistemas, generalmente uno o dos. Cada sistema tiene su propio módulo de inicio de sesión y los operadores inician sesión con sus propias cuentas todos los días, lo cual es muy conveniente. Sin embargo, con el desarrollo de las empresas, la cantidad de sistemas utilizados aumenta. Los operadores necesitan iniciar sesión varias veces cuando operan diferentes sistemas, y cada sistema tiene una cuenta diferente, lo cual es muy inconveniente para los operadores. Entonces, pensé si podría iniciar sesión en un sistema sin iniciar sesión en otros sistemas. Esto es lo que resuelve el inicio de sesión único.
El nombre completo en inglés del inicio de sesión único es Single Sign On y la abreviatura es SSO. Su explicación es: en múltiples sistemas de aplicaciones, solo necesita iniciar sesión una vez para acceder a otros sistemas de aplicaciones de confianza mutua.
Como se muestra en la figura, hay 4 sistemas en la figura, a saber, Aplicación1, Aplicación2, Aplicación3 y SSO. La Aplicación1, la Aplicación2 y la Aplicación3 no tienen módulos de inicio de sesión, mientras que SSO solo tiene un módulo de inicio de sesión y ningún otro módulo comercial. Cuando la Aplicación1, la Aplicación2 y la Aplicación3 necesitan iniciar sesión, saltarán al sistema SSO. iniciar sesión y otros sistemas de aplicación seguirán. Esto encaja perfectamente con nuestra definición de inicio de sesión único (SSO).
Antes de hablar sobre la implementación técnica del inicio de sesión único (SSO), hablemos primero del mecanismo de autenticación de inicio de sesión ordinario.
Como se muestra en la imagen de arriba, accedemos a una aplicación en el navegador (Browser). Esta aplicación requiere iniciar sesión. Después de completar el nombre de usuario y la contraseña, completamos la autenticación de inicio de sesión. En este momento, marcamos el estado de inicio de sesión como sí (iniciado sesión) en la sesión del usuario y escribimos una cookie en el navegador (Navegador). Esta cookie es el identificador único del usuario. La próxima vez que visitemos esta aplicación, esta cookie se incluirá en la solicitud. El servidor encontrará la sesión correspondiente en función de esta cookie y utilizará la sesión para determinar si el usuario ha iniciado sesión. Si no se realiza ninguna configuración especial, el nombre de esta cookie es jsessionid y el valor es único en el servidor.
Generalmente, una empresa solo tiene un nombre de dominio y los diferentes sistemas se distinguen a través de nombres de dominio de segundo nivel. Por ejemplo, tenemos un nombre de dominio llamado: a.com y dos sistemas comerciales: app1.a.com y app2.a.com. Queremos realizar un inicio de sesión único (SSO) y necesitamos un sistema de inicio de sesión llamado: sso.a.com.
Siempre que iniciemos sesión en sso.a.com, app1.a.com y app2.a.com también iniciarán sesión. A través del mecanismo de autenticación de inicio de sesión anterior, podemos saber que al iniciar sesión en sso.a.com, el estado de inicio de sesión en realidad se registra en la sesión en el lado del servidor de sso.a.com, y al mismo tiempo en el sso en el lado del navegador (Las cookies se escriben en a.com). Entonces, ¿cómo podemos permitir que app1.a.com y app2.a.com inicien sesión? Aquí hay dos preguntas:
Entonces, ¿cómo solucionamos estos dos problemas? Con respecto a la primera pregunta, después de iniciar sesión en sso, puede configurar el dominio de cookies en el dominio superior, es decir, a.com, para que todos los sistemas de subdominio puedan acceder a las cookies del dominio superior. Cuando configuramos cookies, solo podemos configurar el dominio superior y nuestro propio dominio, y no podemos configurar otros dominios. Por ejemplo: no podemos configurar cookies para el dominio baidu.com en nuestro propio sistema.
El problema de las cookies está resuelto, veamos nuevamente el problema de la sesión.
Iniciamos sesión en el sistema sso y luego visitamos la aplicación1 nuevamente. La cookie también se envió al servidor de la aplicación1. ¿Cómo encuentra el servidor de la aplicación1 la sesión correspondiente a esta cookie? Aquí necesitamos compartir las sesiones de los tres sistemas, como se muestra en la figura. Existen muchas soluciones para compartir sesiones, como: Spring-Session. Esto resuelve el segundo problema.
Se ha implementado el inicio de sesión único en el mismo dominio, pero no se trata de un inicio de sesión único real.
El inicio de sesión único bajo el mismo dominio hace un uso inteligente de las características del dominio superior de Cookie. ¿Qué pasa si es un dominio diferente? Las cookies no se comparten entre diferentes dominios. ¿Qué debo hacer?
Aquí vamos a hablar sobre el proceso CAS, que es el proceso estándar para el inicio de sesión único.
La imagen de arriba es el proceso estándar en el sitio web oficial de CAS. El proceso específico es el siguiente:
En este punto, se completa el inicio de sesión único entre dominios. Cuando accedamos nuevamente al sistema de la aplicación en el futuro, se iniciará sesión en la aplicación. A continuación, veamos el proceso de acceso al sistema app2.
De esta manera, el sistema app2 no necesita pasar por el proceso de inicio de sesión, ya ha iniciado sesión. SSO, app y app2 están en dominios diferentes y no hay problema si las sesiones entre ellas no se comparten.
Algunos estudiantes me preguntaron que después de iniciar sesión en el sistema SSO, al volver al sistema empresarial original, traje un parámetro ST. El sistema empresarial también necesita usar ST para acceder a SSO nuevamente para su verificación. Creo que este paso es un poco redundante. Quiere devolver la información del usuario al sistema empresarial original a través de la dirección de devolución de llamada después de pasar la autenticación de inicio de sesión SSO. El sistema empresarial original establece directamente el estado de inicio de sesión. ¿excelente?
De hecho, este problema es muy grave si no inicio sesión durante el SSO, pero escribo la dirección de devolución de llamada directamente en el navegador y obtengo información de usuario falsa, ¿el sistema empresarial también me considerará iniciado sesión? ¿Qué pasa? Esto es terrible.
Se han introducido todos los procesos de inicio de sesión único (SSO) y los principios son claros para todos. Resuma lo que debe hacer el inicio de sesión único:
Consulte el artículo que escribí sobre JWT/TOKEN