Un sistema CAS provee un servicio de autenticación centralizado. Esto significa que tras una autenticación inicial tendremos acceso a un conjunto de aplicaciones asociadas a dicha plataforma, ahorrándonos varios “logins” adicionales si queremos entrar en una u otra aplicación. Dichas aplicaciones pueden encontrarse, no sólo en distintos dominios, sino que también pueden estar en distintos servidores.
El protocolo del CAS involucra al menos a tres partes: un navegador web, la aplicación web que requiera autenticación y el servidor CAS. Cuando el cliente visita la aplicación en la que necesita autenticación para acceder, la aplicación le redirige al servidor CAS. Este servidor valida la autenticidad del cliente, generalmente mediante usuario y contraseña.
Si la autenticación es correcta, el servidor CAS redirige al cliente a la aplicación web, pasándole un ticket de seguridad llamado CASTGT que se almacena en una cookie en el navegador.
Cuando el control vuelve a la aplicación web, esta valida el TGT conectando con el servidor CAS mediante una conexión segura. El CAS valida la aplicación, proporcionando su propio identificador de servicio llamado ticket (de un solo uso y con tiempo de expiración, que suele aparecer en la URL) si la aplicación esta registrada en el servidor CAS. Entonces el CAS devuelve información del usuario validado.
Cuando el cliente vuelve a acceder a otra aplicación web asociada al CAS, se repite el mismo proceso, con la diferencia de que la redirección a la página de autenticación del servidor CAS, lleva asociada la cookie CASTGT, que el CAS comprueba si es valida. Si es valida, repite el provceso de validación de la aplicación web, pero no pide las credenciales de autenticación del cliente nuevamente. Esta cookie CASTGT suele tener un tiempo de caducidad (12h) y expiración (4h).
Tenemos que realizar las siguientes modificaciones:
<dependency> <groupId>org.jasig.cas.client</groupId> <artifactId>cas-client-support-saml</artifactId> </dependency>
Cuando se utiliza el sistema de CAS, para poder cerrar las sesiones iniciadas por el cliente en el CAS es necesario realizar una redirección a la pagina de cierre de sesión o logout del CAS, que permite eliminar la cookie CASTGT. Mientras no se elimine esa cookie, el usuario podrá acceder a las aplicaciones asociadas al CAS sin tener que volver a realizar la autenticación para acceder a las aplicaciones.
Este comportamiento, hace que los usuarios piensen que nunca pueden cerrar las sesiones en las aplicaciones, creyendo que las aplicaciones no funcionan correctamente. También es importante resaltar, que en ordenadores compartidos, el usuario tiene que cerrar la sesión con el CAS, ya que otro usuario podría acceder a las aplicaciones con unos privilegios no apropiados, creándose un problema de seguridad. Es necesario por ello, explicar a los usuarios como funciona el sistema y los peligros que conlleva.
En FundeWeb 2.0, se dispone un método llamado logoutByCAS incluido en la clase UmuIndentity que permite cerrar tanto la sesión con la aplicación web, como la sesión del usuario en el CAS, ya que realiza una redirección a la pagina de cierre de sesión del CAS.
Aunque si se sustituye este método por el habitual cierre de sesión de la aplicación, se rompe el servicio de autenticación centralizada que proporciona el CAS. Lo ideal es que cuando cerremos una aplicación asociada al CAS, se produzca una redirección a la página de entrada o principal del CAS, y que sea el usuario el que decida cerrar o no la sesión con el CAS.
Para poder utilizar la autenticación tenemos que dar de alta la aplicación en el servidor CAS. El login se hace contra ese servidor, un filtro que añadimos nos indicará si estamos loggeados o no contra ese servidor. Para poder hacer login contra ese servidor debemos de tener nuestra aplicación dada de alta en el servidor CAS.
Para ello el primer paso que tenemos que hacer es poner un JIRA con las instrucciones que aparecen en la siguiente guía de La Sección de Telemática.
En los ficheros de filtrado de _web\src\main\filters_ configuramos estas propiedades:
Abrimos el fichero filtro-local.properties y sustituimos la configuracion del CAS por:
# CAS cas.disabled=false cas.server.url=sso cas.application.url=_mipc_.atica.um.es:8002 cas.proxyGrantingTicketStorageClass=org.jasig.cas.client.proxy.ProxyGrantingTicketStorageImpl # false con Proxy Ticket install.jdbcProxyGrantingTicketStorageDao=false
Abrimos el fichero filtro-desarrollo y sustituimos la configuracion del CAS por:
# CAS cas.disabled=false cas.server.url=sso cas.application.url=_mi_aplicacion_pruebas.um.es cas.proxyGrantingTicketStorageClass=es.um.atica.casclient.JdbcProxyGrantingTicketStorage # true con Proxy Ticket install.jdbcProxyGrantingTicketStorageDao=false
Abrimos el fichero filtro-preproduccion.properties y sustituimos la configuracion del CAS por:
# CAS cas.disabled=false cas.server.url=sso cas.application.url=_mi_aplicacion_pruebas.um.es cas.proxyGrantingTicketStorageClass=es.um.atica.casclient.JdbcProxyGrantingTicketStorage # true con Proxy Ticket install.jdbcProxyGrantingTicketStorageDao=false
Abrimos el fichero filtro-preproduccion.properties y sustituimos la configuracion del CAS por:
# CAS cas.disabled=false cas.server.url=entrada cas.application.url=_mi_aplicacion_.um.es cas.proxyGrantingTicketStorageClass=es.um.atica.casclient.JdbcProxyGrantingTicketStorage # true con Proxy Ticket install.jdbcProxyGrantingTicketStorageDao=false
El nombre host de la máquina debe se un nombre host válido que cumpla el patrón:
^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\-]*[A-Za-z0-9])$
Para comprobar si nuestro nombre host es válido podemos hacerlo en: https://www.regexplanet.com poniendo la expresión regular anterior.
Comprobar que en los ficheros web\src\main\filters\filtro-desarrollo.properties y web\src\main\filters\filtro-local.properties esté la variable del servidor de desarrollo de CAS (“sso”), que el servidor de pruebas.
A partir de este momento, cuando intentemos entrar en la aplicación aparecerá el login de CAS cuando se detecte que no estás loggeado en una aplicación CAS.
En nuestra aplicación, por defecto la página de login es la primera que aparece (está en el index.html). Ésa página, que es la de inicio por defecto, habrá que cambiarla por la que queramos que aparezca en primer lugar en nuestra aplicación. Para ello modificamos el fichero anterior filtro-local.properties o filtro-desarrollo.properties.
# sin CAS url.pagina.login=login.seam # con CAS url.pagina.login=paginas/home.seam # sin CAS viewid.pagina.login=login.xhtml # con CAS viewid.pagina.login=paginas/home.xhtml
Ahora tenemos que configurar el fichero components.xml para indicar el tipo de autenticación de CAS que queremos utilizar (están en la parte final del fichero, comentadas). Tenemos tres tipos de autenticación, que son los siguientes:
Donde el único dato que obtenemos es el usuario conectado al CAS, donde utilizamos las siguientes etiquetas (el resto tienen que estar comentadas): <fdw-cas:cas-client3-authentication-filter>, <fdw-cas:cas-client3-ticket-validator-filter> y <fdw-cas:cas-client3-http-servlet-request-wrapper-filter>.
<!-- CAS - SSO --> <!-- NORMAL --> <fdw-cas:cas-client3-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" /> <fdw-cas:cas-client3-ticket-validator-filter disabled="@cas.filter.disabled@" casServerUrlPrefix="@cas.server.url@" serverName="@cas.server.name@" redirectAfterValidation="false" regex-url-pattern="/paginas/.*\.seam" /> <!-- SAML <fdw-cas:cas-client3-saml-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" /> <fdw-cas:cas-client3-saml-ticket-validator-filter disabled="@cas.filter.disabled@" casServerUrlPrefix="@cas.server.url@" serverName="@cas.server.name@" redirectAfterValidation="false" regex-url-pattern="/paginas/.*\.seam" /> --> <!-- OBLIGATORIO SIEMPRE --> <fdw-cas:cas-client3-http-servlet-request-wrapper-filter disabled="@cas.filter.disabled@" regex-url-pattern="/paginas/.*\.seam" /> <!-- FIN CAS - SSO -->
El doble factor de autenticación en aplicaciones FundeWeb, lo podemos configurar de dos maneras:
Para ambas configuraciones, tendremos que poner un JIRA al proyecto DJ-AT-Telemática y componente AUT-AUT, indicando la URL base será controlada bajo el 2FA. Para la primera forma de configuración, ya no es necesario realizar pasos adicionales.
Para la segunda forma de configuración, tendremos que añadir configuración adicional en el fichero components.xml. Vamos a la etiqueta <fdw-cas:cas-client3-authentication-filter> y tenemos disponibles dos nuevas propiedades:
<!-- Solo queremos la página /paginas/twoFactorAuthentication.seam protegida con 2FA --> <fdw-cas:cas-client3-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" twoFactorUrlPattern="/paginas/twoFactorAuthentication.seam"/> <!-- Queremos que todas las paginas de la carpeta /paginas/twoFactorAuthentication esten protegidas con 2FA --> <fdw-cas:cas-client3-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" twoFactorUrlPattern="/paginas/twoFactorAuthentication/*.seam"/>
<!-- Solo queremos la página /paginas/twoFactorAuthentication.seam protegida con 2FA --> <fdw-cas:cas-client3-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" twoFactorUrlRegexp="/paginas/twoFactorAuthentication\.seam"/> <!-- Queremos que todas las paginas de la carpeta /paginas/twoFactorAuthentication esten protegidas con 2FA --> <fdw-cas:cas-client3-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" twoFactorUrlRegexp="/paginas/twoFactorAuthentication/.*\.seam"/> <!-- Queremos que todas las paginas de las carpetas /paginas/twoFactorAuthenticationPart1 y /paginas/twoFactorAuthenticationPart2 estén protegidas con 2FA --> <fdw-cas:cas-client3-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" twoFactorUrlRegexp="/paginas/twoFactorAuthenticationPart1/.*\.seam|/paginas/twoFactorAuthenticationPart2/.*\.seam"/>
Este segundo caso, implica forzosamente, que tendremos que volver a autenticarnos en el CAS mediante las dos formas de autenticación para acceder a la parte de la aplicación protegida con 2FA.
La páginas protegidas con 2FA, tienen que estar dentro de del conjunto de paginas protegidas por el CAS, es decir, deben estar incluidas dentro de lo indicado en url-pattern o regex-url-pattern.
Con autenticación Cl@ve, el sso nos proporciona el DNI (identificador), los apellidos (FamilyName) y el nombre (FirstName).
Si la universidad tiene los datos de la persona, FundeWeb obtendrá esos datos y rellenará la instancia de Persona dentro de UMUIdentity (identity.persona), como si se hubiese autenticado con correo, hay que tener en cuenta que solamente se modifican esos datos así que si en nuestra aplicación usamos por ejemplo el valor de identity.principal.name, en este caso será el DNI devuelto por el sso y no el correo.
Si la universidad no tiene los datos de la persona, FundeWeb rellenará la instancia identity.persona con los datos devueltos por el sso, y por tanto solamente contaremos con los campos identificador(DNI), nombre y apellidos.
En los servidores de desarrollo y local debería estar dado de alta el método Cl@ve por defecto, pero en test y producción hay que poner un jira.
Esta forma de configuración esta obsoleta, no utilizar, con la autenticación normal es suficiente.
Donde podemos obtener los datos que hay en el LDAP del usuario conectado al CAS, donde utilizamos las siguientes etiquetas (el resto tienen que estar comentadas): <fdw-cas:cas-client3-saml-authentication-filter>, <fdw-cas:cas-client3-saml-ticket-validator-filter> y <fdw-cas:cas-client3-http-servlet-request-wrapper-filter>.
<!-- CAS - SSO <!-- NORMAL <fdw-cas:cas-client3-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" /> <fdw-cas:cas-client3-ticket-validator-filter disabled="@cas.filter.disabled@" casServerUrlPrefix="@cas.server.url@" serverName="@cas.server.name@" redirectAfterValidation="false" regex-url-pattern="/paginas/.*\.seam" /> --> <!-- SAML --> <fdw-cas:cas-client3-saml-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" /> <fdw-cas:cas-client3-saml-ticket-validator-filter disabled="@cas.filter.disabled@" casServerUrlPrefix="@cas.server.url@" serverName="@cas.server.name@" redirectAfterValidation="false" regex-url-pattern="/paginas/.*\.seam" /> <!-- OBLIGATORIO SIEMPRE --> <fdw-cas:cas-client3-http-servlet-request-wrapper-filter disabled="@cas.filter.disabled@" regex-url-pattern="/paginas/.*\.seam" /> <!-- FIN CAS - SSO -->
Esta autenticación se combina con una de las dos anteriores, si se utiliza la autenticación normal, no hace falta añadir el filtro de validación de Service Tickets y permite que aplicaciones a las que no se les puede integrar el cliente de acceso a CAS, estén protegidas por el CAS, añadimos la siguiente etiqueta: <fdw-cas:cas-client3-proxy-receiving-ticket-validation-filter>. En el fichero components.properties tenemos que añadir la propiedad: cas.application.contextroot=<mi_aplicacion>.
Donde <mi_aplicacion> es el nombre de la aplicación o context-root.
Ejemplo con autenticación NORMAL:
<!-- CAS - SSO --> <!-- NORMAL --> <fdw-cas:cas-client3-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" /> <!--fdw-cas:cas-client3-ticket-validator-filter disabled="@cas.filter.disabled@" casServerUrlPrefix="@cas.server.url@" serverName="@cas.server.name@" redirectAfterValidation="false" regex-url-pattern="/paginas/.*\.seam" /--> <!-- SAML <fdw-cas:cas-client3-saml-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" /> <fdw-cas:cas-client3-saml-ticket-validator-filter disabled="@cas.filter.disabled@" casServerUrlPrefix="@cas.server.url@" serverName="@cas.server.name@" redirectAfterValidation="false" regex-url-pattern="/paginas/.*\.seam" /> --> <!-- OBLIGATORIO SIEMPRE --> <fdw-cas:cas-client3-http-servlet-request-wrapper-filter disabled="@cas.filter.disabled@" regex-url-pattern="/paginas/.*\.seam" /> <!-- PROXY TICKET --> <fdw-cas:cas-client3-proxy-receiving-ticket-validation-filter disabled="@cas.filter.disabled@" casServerUrlPrefix="@cas.server.url@" serverName="@cas.server.name@" proxyCallbackUrl="@cas.server.name@/@cas.application.contextroot@/proxyCallback" proxyReceptorUrl="/@cas.application.contextroot@/proxyCallback" url-pattern="proxyCallback" />
Ejemplo con autenticación SAML:
<!-- CAS - SSO <!-- NORMAL <fdw-cas:cas-client3-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seamm" /> <fdw-cas:cas-client3-ticket-validator-filter disabled="@cas.filter.disabled@" casServerUrlPrefix="@cas.server.url@" serverName="@cas.server.name@" redirectAfterValidation="false" regex-url-pattern="/paginas/.*\.seam" /> --> <!-- SAML --> <fdw-cas:cas-client3-saml-authentication-filter disabled="@cas.filter.disabled@" casServerLoginUrl="@cas.login.url@" serverName="@cas.server.name@" regex-url-pattern="/paginas/.*\.seam" /> <fdw-cas:cas-client3-saml-ticket-validator-filter disabled="@cas.filter.disabled@" casServerUrlPrefix="@cas.server.url@" serverName="@cas.server.name@" redirectAfterValidation="false" regex-url-pattern="/paginas/.*\.seam" /> <!-- OBLIGATORIO SIEMPRE --> <fdw-cas:cas-client3-http-servlet-request-wrapper-filter disabled="@cas.filter.disabled@" regex-url-pattern="/paginas/.*\.seam" /> <!-- PROXY TICKET --> <fdw-cas:cas-client3-proxy-receiving-ticket-validation-filter disabled="@cas.filter.disabled@" casServerUrlPrefix="@cas.server.url@" serverName="@cas.server.name@" proxyCallbackUrl="@cas.server.name@/@cas.application.contextroot@/proxyCallback" proxyReceptorUrl="/@cas.application.contextroot@/proxyCallback" url-pattern="proxyCallback" />
Abrimos el fichero components.properties y añadimos las siguientes propiedades:
# CAS configuration
cas.filter.disabled=${cas.disabled}
cas.server.url=https://${cas.server.url}.um.es/cas/
cas.login.url=https://${cas.server.url}.um.es/cas/login
cas.logout.url=https://${cas.server.url}.um.es/cas/logout
cas.server.name=https://${cas.application.url}
cas.proxyCallbackUrl=https://${cas.application.url}/${application.name}/CasProxyServlet
cas.proxyReceptorUrl=/CasProxyServlet
cas.proxyGrantingTicketStorageClass=${cas.proxyGrantingTicketStorageClass}
install.jdbcProxyGrantingTicketStorageDao=${install.jdbcProxyGrantingTicketStorageDao}
El valor de cas.application.contextroot es el contexto raíz de la aplicación. Sino sabéis cual es, lo podemos obtener de el fichero POM del módulo EAR, en la propiedad <contextRoot> del plugin maven-ear-plugin.
Para poder obtener el Proxy Ticket:
String newTicket = ""; // CAS: Obtencion del ticket proxy para validacion por terceros Principal principal = CasClient3Util.getCasClient3Principal(); if (principal instanceof AttributePrincipal) { AttributePrincipal casPrincipal = (AttributePrincipal) principal; newTicket = casPrincipal.getProxyTicketFor(TokenService_Service.TOKEN_FROM_TICKET_SERVICE); }
Además del Proxy Ticket, la clase AttributePrincipal contiene un mapa con todos los atributos contenidos en el CAS para el usuario conectado. En aplicaciones FundeWeb es posible obtener todos estos atributos de forma similar al ejemplo anterior:
@In
private UmuIdentity identity;
...
Map<String, Object> attributes = CasClient3Util.getPrincipalAttributes(identity.getPrincipal()); //CasClient3Util.getCasClient3Principal()
....
Cuando una aplicación web se asocia al CAS, y un usuario accede satisfactoriamente, se crean dos sesiones, una con el propio servidor CAS y otra con la aplicación.
Para finalizar las sesiones, tenemos tres posibles escenarios:
En este escenario, el usuario puede cerrar la sesión del CAS y seguir trabajando en la aplicación, para poder hacerlo, el usuario tiene que ir a la página de logout del CAS, la url suele ser: https://_SERVIDOR_.um.es/cas/logout y hacer un logOut.
En este escenario, el usuario puede cerrar la sesión de la aplicación web, pero sigue manteniendo la sesión con el CAS. De esta forma puede acceder a otras aplicaciones asociadas al CAS. Para poder hacerlo, se utiliza el método logout de la clase Identiy. Además, tenemos que modificar el fichero pages.xml, para redireccionar al usuario a la página de entrada del CAS. La modificación es la siguiente:
<page view-id="*"> ... <navigation from-action="#{identity.logout}"> <redirect url="https://@cas.server.url@.um.es/cas/"/> </navigation> </page>
De esta forma, el usuario tiene la impresión de que efectivamente ha cerrado la sesión en la aplicación y tiene disponibles el resto de aplicaciones que están registradas en el CAS, para acceder a ellas o cerrar la sesión en el CAS.
Añadimos las excepciones siguientes:
<exception class="org.umu.atica.seam.security.CasLoginException"> <redirect view-id="/error.xhtml"> <message severity="error">#{messages['org.umu.atica.seam.security.CasLoginException']}</message> </redirect> </exception> <exception class="org.jasig.cas.client.validation.TicketValidationException"> <redirect view-id="/error_cas.xhtml"/> </exception> <exception class="org.jasig.cas.client.validation.InvalidProxyChainTicketValidationException"> <redirect view-id="/error_cas.xhtml"/> </exception>
En los ficheros de mensajes, añadimos (sino esta ya previamente):
#---- CAS error ------------------------------------ error.cas.titulo.disculpe=DISCULPE LAS MOLESTIAS error.cas.titulo.error=ERROR AL ACCEDER A LA APLICACI\u00F3N prueba org.umu.atica.seam.security.CasLoginException=No tiene permisos de acceso a la aplicaci\u00F3n.
#---- CAS error ------------------------------------ error.cas.titulo.disculpe=OUR APALOGIES FOR THE INCONVENIENCE error.cas.titulo.error=ERROR ACCESING prueba APPLICATION org.umu.atica.seam.security.CasLoginException=You don't have permission to access to the application.
Revisamos que tenemos la página error_cas.xhtml, sino, la podemos descargar de aquí, y la descomprimimos en /src/main/webapp.
En este último escenario, el usuario cierra la sesión en la aplicación web y en el CAS, con lo que si quiere acceder a otra aplicación asociada al CAS, tendrá que volver a realizar el proceso de autenticación.
Para poder hacerlo, se utiliza el método casLogout de la clase UmuIdentiy, este método invalida la sesión en la aplicación web y hace una redirección a la página de cierre de sesión o logout del CAS.
Se puede deshabilitar el CAS para poder realizar pruebas (principalmente en entorno LOCAL y DESARROLLO) con determinados usuarios. En este caso, se utiliza la página de autenticación general login.xhtml para poder especificar el usuario que accede a la aplicación.
Para deshabilitar el CAS solo tenemos que ir al fichero de filtro correspondiente al entorno, por ejemplo, web\src\main\filters\filtro-local.properties o web\src\main\filters\filtro-desarrollo.properties y en la propiedad cas.disabled le ponemos el valor false.
— JUAN MIGUEL BERNAL GONZALEZ 15/01/2020 09:49
— PEDRO DELGADO YARZA 2014/01/29 13:53
— RAMON GINEL GEA 15/01/2020 09:49