Múltiples sistemas usan CAS para realizar el caso de inicio de sesión de SSO

1. Introducción a CAS

Hay muchas maneras de implementar SSO. Las relativamente simples y factibles son generalmente las dos anteriores más CAS. Generalmente, si desea implementar SSO entre múltiples sistemas en una empresa, la forma recomendada es el CAS que se presentará hoy, Central Servicio de autenticación, un servicio de autenticación central.

El esquema CAS incluye principalmente las siguientes dos partes:

• El servidor CAS, como centro de servicios de autenticación, debe implementarse por separado;
• Cliente CAS, se refiere a cada sistema que requiere un inicio de sesión único y admite oficialmente más de 10 tipos de clientes;

El siguiente es un proceso completo de CAS SSO para múltiples sistemas:

Proceso de inicio de sesión de SSO

1. Cuando el navegador accede por primera vez al sistema 1, el sistema 1 determina que no ha iniciado sesión (sin sesión local), por lo que lo redirige al centro de autenticación SSO, y el centro de autenticación no tiene la sesión global actual del navegador, por lo que regresa la página de inicio de sesión del navegador para solicitar el inicio de sesión;
2. Después de que el navegador inicie sesión correctamente, el centro de autenticación conservará la sesión global del usuario del navegador. Cuando el usuario se autentique posteriormente con el centro de autenticación SSO a través de otros sistemas, el JSESSIONID de la sesión global se llevará al centro de autenticación y el el centro de autenticación sabrá que el usuario actualmente tiene una sesión global y está conectado;
3. El centro de autenticación crea un token de autorización temporal y se lo entrega al sistema 1. Este token tiene un período de validez y solo se puede usar una vez. Después de que el sistema 1 recibe el token, no puede determinar si se ha falsificado, por lo que debe solicitar el centro de autenticación para comprobar de nuevo. Después de recibir una respuesta de autenticación exitosa, el sistema 1 creará una sesión parcial para el usuario actual. Antes de que caduque la sesión parcial, el usuario no necesita ir al centro de autenticación para autenticarse nuevamente cuando acceda al sistema 1 nuevamente;
4. Si el usuario del navegador accede a otro sistema 2 en este momento, el sistema 2 determina que no ha iniciado sesión (sin sesión local), por lo que lo redirige al centro de autenticación SSO con la sesión global JSESSIONID guardada en el segundo paso, y el centro de autenticación determina que el usuario ha iniciado sesión. Por lo tanto, se crea un token de autorización temporal y se entrega al sistema 2, y el sistema 2 continúa con el paso 3.

Luego hay un proceso para el cierre de sesión de SSO:

Proceso de cierre de sesión de SSO

2. Implementación de CAS

2.1 Servidor CAS

El servidor tiene un paquete de guerra listo para usar disponible en la dirección oficial de github, simplemente descárguelo directamente Dado que la última versión de la herramienta de administración de dependencias se cambió de maven a gradle, estoy más familiarizado con maven, así que no elegí la última versión, pero utilice la versión 5.3 . Después de descargarlo, descomprímelo.

Ejecute el comando de empaquetado en el directorio descomprimido build.cmd packagey podrá ver el paquete war en el directorio de destino Coloque cas.war en el directorio local de aplicaciones web de tomcat e inicie tomcat.

En este punto, cuando visite el servicio Tomcat local, http://localhost:8080/caspodrá ver la página de inicio de sesión.

Página de inicio de sesión del servidor CAS

La contraseña de cuenta predeterminada es: casuser/Mellon. La contraseña se configura en el siguiente directorio WEB-INF\classes\application.properties. Si necesita cambiar la contraseña, debe modificar el contenido de los siguientes archivos después de la descompresión en Tomcat.

##
# CAS Authentication Credentials
#
cas.authn.accept.users=casuser::Mellon

De forma predeterminada, el protocolo de comunicación entre el cliente y el servidor es https.Si desea ejecutar a través del entorno de protocolo http local, debe desactivar el servicio https predeterminado.

在WEB-INF\classes\application.properties的最后添加如下配置内容：
cas.tgc.secure=false
cas.serviceRegistry.initFromJson=true

在WEB-INF\classes\services\HTTPSandIMAPS-10000001.json中修改内容：
"serviceId" : "^(https|http|imaps)://.*"

Luego reinicie el servidor CAS.

2.2 Cliente CAS

<dependency>
    <groupId>net.unicon.cas</groupId>
    <artifactId>cas-client-autoconfig-support</artifactId>
    <version>2.1.0-GA</version>
</dependency>

@EnableCasClient
@SpringBootApplication
public class SsoClient1Application {
    
    

    public static void main(String[] args) {
    
    
        SpringApplication.run(SsoClient1Application.class, args);
    }

}

@RestController
public class LoginClient1Controller {
    
    

    @GetMapping("/getUserInfo")
    public String getUserInfo(){
    
    
        return "user1";
    }

}

server.port=8081

cas.server-url-prefix=http://localhost:8080/cas
cas.server-login-url=http://localhost:8080/cas/login
cas.client-host-url=http://localhost:8081
cas.validation-type=cas3

Lo anterior es todo el contenido de client1, y client2 es básicamente similar, así que no lo repetiré aquí.

Después de iniciar los dos clientes, el acceso a cualquiera de sus interfaces será redirigido a la página de inicio de sesión del servidor CAS. Siempre que se complete un inicio de sesión, se puede acceder directamente a cualquier interfaz de los dos sistemas sin iniciar sesión nuevamente, realizando así SSO.

Entonces, ¿cuál es la diferencia entre CAS y el protocolo OAuth2.0 con el que estamos familiarizados?

1. OAuth2 es un protocolo de autorización de tres partes que permite a los usuarios autorizar a través de aplicaciones confiables sin proporcionar contraseñas de cuentas, para que sus clientes puedan acceder a los recursos dentro del alcance de la autoridad.
2. CAS es un protocolo de servicio de autenticación central, un marco para implementar el inicio de sesión único de SSO basado en tickets, y proporciona una solución de inicio de sesión único confiable para sistemas de aplicaciones web.
3. El inicio de sesión único de CAS es para garantizar la seguridad de los recursos del usuario en el lado del cliente, mientras que OAuth2 es para garantizar la seguridad de los recursos del usuario en el lado del servidor.

La información final que el cliente CAS necesita obtener es si este usuario tiene permiso para acceder a mis recursos (cliente CAS); la información final obtenida por OAuth2 es si los recursos de mi usuario (proveedor de servicios oauth2) pueden permitirle acceso a usted (cliente oauth2).

Por lo tanto, se requiere una contraseña de cuenta unificada para la autenticación de identidad mediante CAS; los servicios de terceros deben estar autorizados para utilizar nuestros recursos mediante OAuth2

Finalmente, CAS no solo es compatible con el protocolo CAS en el esquema de implementación de SSO, sino que también es compatible con OAuth2, SAML y otros protocolos. Para obtener más información, consulte los documentos oficiales.

documentos de referencia

CAS - Guía de inicio (apereo.github.io)

Inicio de sesión único de SSO basado en CAS- Zhihu (zhihu.com)