/
¿Cómo integrar la seguridad de Plataforma con Apereo CAS SSO?

¿Cómo integrar la seguridad de Plataforma con Apereo CAS SSO?

09/09/21


Descargo de responsabilidad

Este GI está obsoleto. Vea nuestro nuevo GI Premium



Introducción

Single sign on (SSO) es un proceso de autenticación de usuario/sesión que permite a un usuario proporcionar sus credenciales una única vez en un único punto de entrada para poder acceder a varias aplicaciones. El SSO autentica al usuario para acceder a todas las aplicación a las que se le ha conferido acceso. Elimina de esta forma futuras peticiones de autenticación cuando el usuario cambia de aplicación durante una sesión concreta.
Web SSO se refiere estrictamente a aplicaciones a las que se accede mediante un navegador web. Las peticiones de acceso a un recurso web son interceptadas bien por un componente en el servidor, bien por la aplicación en sí misma. Los usuarios que no estén autenticados serán redirigidos a un servicio de autenticación y sólo volverán a la página tras autenticarse de nuevo.


CAS o Servicio de autenticación central es un protocolo Web SSO. Su propósito es permitir a los usuarios el acceso a varias aplicaciones proporcionando sus credenciales (usuario y contraseña, por ejemplo) una única vez. Permite además que las aplicaciones web autentiquen a usuario sin acceder a las propias credenciales de los usuarios (contraseña).
El protocolo CAS involucra, al menos, a 3 agentes:

  • Un navegador cliente desde el que accede el usuario.
  • La aplicación Web que solicita la autenticación.
  • El servidor CAS.

Cuando el usuario visita una aplicación que requiere autenticación, dicha aplicación redirige la petición al servidor CAS. El servidor CAS valida la autenticación del usuario (normalmente comprobando usuario y contraseña contra una BBDD (LDAP,…).
En este caso será el propio servidor CAS el que proporcione la interfaz de usuario para realizar la autenticación del usuario.
Si la autenticación se lleva a cabo con éxito, el servidor CAS devuelve al cliente un ticket de servicio. La aplicación valida el ticket contactando con el Servidor CAS mediante una conexión segura y proporcionando además su propio identificador de servicio. El servidor CAS devuelve entonces información sobre si el usuario se ha autenticado con éxito.

Apereo CAS

Una de las soluciones más usadas como Web SSO es Apereo CAS.

Las características principales por las que se ha seleccionado son las siguientes:

  • Proyecto Open Source.
  • Protocolo abierto y bien documentado.
  • Autenticación orientada a plugins (LDAP, BBDD,…).
  • Soporte de múltiples protocolos (CAS, Oauth, OpenID,…).
  • Dispone de un extensa librería de clientes (Java, .Net, PHP, Perl…).
  • Integración con uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle entre otros.
  • Amplio grado de adopción.

https://www.apereo.org/projects/cas

Arquitectura Apereo CAS

En la siguiente figura se muestra la arquitectura de Apereo CAS:

El servidor CAS está construido con tecnología Java (Spring Framework) y su principal cometido es autenticar usuarios y otorgar acceso a servicios configurados (clientes CAS) mediante la generación y validación de tickets.
Un cliente CAS puede ser:

  • Cualquier aplicación que se comunique utilizando el protocolo soportado (librerías).
  • SW desarrollado para facilitar la integración de plataformas o aplicaciones utilizando uno de los protocolos soportados (conectores).

Preparación del CAS Server

Se utiliza la versión 5.1 de Apereo CAS, desplegándola a partir del cas-overlay-template-5.1. Para más información:
https://apereo.github.io/cas/5.1.x/
https://github.com/apereo/cas-overlay-template/tree/5.1


La configuración del servidor involucra dos aspectos:

  • La propia configuración de los componentes del Servidor CAS y
  • El registro y configuración de las aplicaciones que deleguen la autenticación en el servidor.

Configuración del Servidor CAS

La configuración del servidor CAS se realiza mediante el fichero cas.properties.

En dicho fichero se incluirá información relativa a conectores con BBDD de autenticación para usuarios, ticketing, codificación, etc.

Para más información: https://apereo.github.io/cas/5.1.x/installation/Configuration-Properties.html


Como se ha visto con anterioridad, se utilizan varias bases de datos:

  • LDAP Corporativo como directorio de usuarios.
  • ConfigDB como directorio alternativo de usuarios.
  • RealTimeDB on MongoDB para el almacenamiento de los Tickets (cookies).

En el servidor CAS se desplegará además el interfaz de usuario que servirá como página de login única para todas las aplicaciones registradas.

De esta forma, siempre que una aplicación solicite autenticación al Servidor CAS, este presentará una pantalla de login en la que el usuario introducirá sus credenciales. Una vez validadas, se redirigirá a la página principal configurada en cada una de las aplicaciones cliente.

Configuración de aplicaciones cliente

Para aplicaciones que deleguen su autenticación en el servidor CAS es necesario crear un perfil de aplicación por cada una.
Consistirá en un JSON que identificará al servicio, las url que incluye, página de logout, y orden de evaluación.

Configuración CAS Client

Al igual que es necesario realizar una configuración previa en el servidor, del mismo modo las aplicaciones clientes que van a delegar la autenticación en el servidor deben adaptarse, incluyendo distintos conectores y configuraciones.
Dependiendo del tipo de la aplicación a integrar será necesario utilizar una librería en la tecnología seleccionada (Java, .Net,…) como se ha visto con anterioridad o bien utilizar un conector que realice la integración (drupal,…).


Ejemplo: Integración Control Panel como cliente CAS

El Control Panel es una aplicación web que también puede registrarse como cliente CAS.

A continuación se expondrán los pasos a llevar a cabo para integrarla y configurarla sobre el servidor CAS.

Configuración Control Panel

Para que la aplicación Control Panel conecte y delegue la autenticación en el servidor CAS, es necesario incluir la librería java que proporciona Apereo CAS y configurar la seguridad propia de la aplicación.
La aplicación Control Panel es una aplicación Spring Boot. En la configuración del conector con el servidor CAS se incluiría:

Habría que configurar además el filtro de seguridad de Spring:
Y configurar el punto de entrada en la configuración de Spring Boot.

La configuración incluida sirve como ejemplo para tener en cuenta los pasos necesarios a la hora de configurar una aplicación para que delegue la autenticación en el servidor CAS.

Para cada tecnología/aplicación utilizada será necesario realizar un procedimiento similar. Para ello, habrá que consultar la documentación disponible en la web de Apereo.
https://apereo.github.io/cas/5.1.x/integration/CAS-Clients.html

Configuración CAS Server para autenticar Control Panel 

Una vez que la integración del Control Panel ya ha sido implementada, el siguiente paso es registrar la aplicación en el Servidor CAS.
Para ello, se creará un fichero .json con la configuración asociada a la misma. Deberá tener la siguiente forma:

De nuevo, es un ejemplo de configuración. Para más detalles, consultar la documentación de Apereo.
https://apereo.github.io/cas/5.1.x/integration/Delegate-Authentication.html

Flujo de autenticación completo


A continuación se incluye un diagrama con el diagrama de secuencia del caso de uso completo.

  1. El usuario introduce la url de la Aplicación web en el navegador.
  2. El navegador envía la petición, que es interceptada por el Servidor CAS.
  3. El servidor CAS proporciona la UI de login unificada para el SSO:
  4. El navegador presenta la UI de login al usuario.
  5. El usuario introduce id y contraseña.
  6. El navegador envía las credenciales al Servidor CAS.
  7. El Servidor CAS valida las credenciales (contra LDAP, base de datos, …).
  8. El Servidor CAS genera un ticket.
  9. Se envía el ticket a la aplicación.
  10. La aplicación solicita la validación del usuario mediante el ticket e id de aplicación.
  11. El servidor CAS valida las credenciales para el usuario del ticket y la aplicación.
  12. Se confirma la validez de las credenciales a la aplicación
  13. Lógica interna de la Aplicación, que incluye una invocación a un servicio registrado en el API Manager.
  14. Se invoca al servicio utilizando el API Key correspondiente a la aplicación registrada en el API Manager.
  15. Se invoca al servicio externo a través del API Manager.
  16. La aplicación recibe la respuesta del API Manager.
  17. Lógica interna de la aplicación. Construye el UI de respuesta.
  18. La aplicación envía la respuesta.
  19. Se presenta la IU al usuario con el resultado.