Grupo 3

1. Servicio de
Autenticación Central
CAS
Seguridad en Redes Grupo 3

2. Historia
▪ CAS fue creado por Shawn Bayer en la universidad de Yale, con el
apoyo de Drew Mazurek, el cual logro la implementación del inicio
de sesión único.
▪ En diciembre del 2004, CAS se volvería proyecto por parte del
JASIG, grupo el cual tiene la responsabilidad sobre CAS desde el
2008.
▪ En mayo del 2014 se lanzo la versión 3.0 del protocolo CAS el cual
implementaría muchas mejoras y seguridad a inicio de sesión.

3. ¿Que es CAS?
Es un protocolo de inicio de sesión único para la web. Su
objetivo es permitir que un usuario acceda a múltiples
aplicaciones mientras proporciona sus credenciales (como
ID de usuario y contraseña) solo una vez. También permite
que las aplicaciones web autentiquen usuarios sin tener
acceso a las credenciales de seguridad de un usuario,
como una contraseña.

4. ¿Cómo funciona?
▪ El protocolo CAS implica al menos tres partes: un navegador web de cliente ,
la aplicación web que solicita autenticación y el servidor CAS . También
puede implicar un servicio de fondo , como un servidor de base de datos, que no
tiene su propia interfaz HTTP, sino que se comunica con una aplicación web.
▪ Cuando el cliente visita una aplicación que requiere autenticación, la aplicación la
redirige a CAS. CAS valida la autenticidad del cliente, generalmente al verificar
un nombre de usuario y una contraseña en una base de datos (como Kerberos o
Active Directory ).
▪ Si la autenticación tiene éxito, CAS devuelve el cliente a la aplicación, pasando
un ticket de servicio . La aplicación valida el ticket contactando a CAS a través de
una conexión segura y proporcionando su propio identificador de servicio y el
ticket. A continuación, CAS proporciona a la aplicación información confiable
sobre si un usuario en particular se ha autenticado con éxito.

5. APEREO CAS
▪ Apereo CAS es una solución empresarial Single Sign-On para
servicios web. Single Sign-On (SSO) significa una mejor
experiencia de usuario al ejecutar una multitud de servicios web,
cada uno con sus propios medios de autenticación. Con una
solución SSO, los diferentes servicios web pueden autenticarse en
una fuente de confianza auto formadora, que el usuario debe iniciar
sesión, en lugar de requerir que el usuario final inicie sesión en
cada servicio por separado.

7. Servidor Apereo CAS
▪ Protocolo CAS v1, v2 y v3
▪ Protocolo SAML v1 y v2
▪ Protocolo OAuth
▪ OpenID y OpenID Connect Protocol
▪ Protocolo de Solicitante Pasivo WS-Federation
▪ Autenticación a través de JAAS , LDAP , RDBMS, X.509 , Radio, SPNEGO , JWT ,
Remoto, Confiable, BÁSICO, Apache Shiro , MongoDB , Pac4J y más.
▪ Autenticación delegada a WS-FED, Facebook, Twitter, SAML IdP, OpenID , OpenID
Connect , CAS y más.
▪ Autorización a través de ABAC, Hora / Fecha, RESTO, Mero de Internet2 y más.

8. Aplicaciones CAS Oracle
▪ CASifying el cliente web Oracle Calendar con mod_cas.
▪ CASifying Oracle Portal.
▪ CASifying aplicaciones Oracle 11i.
▪ CASifying Oracle BI Publisher Enterprise Edition 11g.

9. Aplicaciones de CASified
▪ uPortal : propio portal de código abierto
▪ Mantis
▪ pNews - un lector de noticias.
▪ Sympa - un administrador de listas de correo.
▪ TikiWiki - Wiki y articulos.
▪ Mule : un marco de mensajería Enterprise JavaBean. CASIFICADO en virtud del uso
de Acegi.
▪ Claroline : un entorno de aprendizaje colaborativo PHP / MySQL gratuito para crear y
administrar cursos a través de la web. GPL. CASified fuera de la caja a partir de 1.7.
▪ Moodle : un sistema gratuito de gestión de cursos de código abierto (CMS). Material
didáctico. CAS como un módulo de autenticación estándar.

10. CAS 5 incluye soporte para autenticación de múltiples factores
(MFA), soporte para OpenID Connect y SAML 2.0 IdP, junto con
integraciones integradas para proveedores de servicio SAML 2.0
(SP).
▪ Autenticación multifactorial
▪ Duo Security ®
▪ Google Authenticator TM
▪ Yubikey TM
▪ Authy ®
▪ Y más..
▪ Integraciones de SAML 2.0 SP
▪ Dropbox TM
▪ Box®
▪ Salesforce®
▪ SAManage®
▪ ServiceNow®
▪ PowerFAIDS® Net Partner
▪ Workday®
▪ WebEx®
▪ Office365®

11. Trasporte Seguro HTTPS
▪ Toda comunicación con el servidor CAS DEBE tener lugar a través de un canal
seguro (es decir, TLSv1 Transport Layer Security). Hay dos justificaciones principales
para este requisito:
▪ El proceso de autenticación requiere la transmisión de credenciales de seguridad.
▪ El boleto de otorgamiento de boleto de CAS es un token de portador.
▪ Dado que la divulgación de cualquiera de los datos permitiría los ataques de
suplantación, es de vital importancia asegurar el canal de comunicación entre los
clientes CAS y el servidor CAS.
▪ Prácticamente, significa que todas las URL de CAS deben usar HTTPS,
pero también significa que todas las conexiones desde el servidor CAS a la
aplicación deben realizarse mediante HTTPS.

12. Funciones de seguridad orientadas a la
implementación
CAS admite una serie de características que pueden aprovecharse para implementar diversas
políticas de seguridad. Las siguientes funciones se proporcionan a través de la configuración
CAS y la integración del cliente CAS.
▪ Autenticación forzada.
▪ Autenticación Pasiva.
▪ Autenticación Proxy.
▪ Autenticación multifactorial.

13. Gracias por su atención