¿Cómo integrar la seguridad de Plataforma con Apereo CAS SSO?
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.