Autenticacíon CAS en aplicaciones Fundeweb 2.0

— PEDRO DELGADO YARZA 2014/01/29 13:53

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:

• Abrimos el POM Principal del proyecto y modificamos el <parent> a la versión 2.0.20 o posterior.

• Posiblemente, tengamos problemas de dependencias si estabamos en una version del <parent> anterior a la 2.0.17. Para solucionar el problema, abrimos el POM del módulo WEB y eliminamos las dependencias <artifactId>cas-client-core</artifactId> y <artifactId>velocity</artifactId> y añadimos las siguiente en su lugar:

                <dependency>
			<groupId>org.jasig.cas.client</groupId>
			<artifactId>cas-client-support-saml</artifactId>
		</dependency>

• Abrimos el fichero weblogic-applicaction.xml y añadimos dentro de la etiqueta <prefer-application-packages> la etiqueta <package-name>org.hibernate.validator.*</package-name>.

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 loggin se hace contra ese servidor, un filtro que añadimos nos indicará si estamos loggeados o no contra ese servidor. Para poder hacer loggin 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 dumbo con las intrucciones que aparecen en la siguiente guía de Apoyo Telemático.

En el fichero web\src\main\filters\filtro-local.properties configuramos estas propiedades:

# CAS
cas.disabled=false
cas.server.url=sso
cas.application.url=<nombre_de_host_de_mi_maquina>:7001

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 nuetra 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 (estan en la parte final del fichero, comentadas). Tenemos tres tipos de autetnicación, que son los siguientes:

Donde el unico 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 -->

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, esten 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>.

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/.*\.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" />

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:

• Cerrar sesión del CAS.
• Cerrar sesión de la aplicación.
• Cerrar sesión del aplicación y del CAS.

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.

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 se tiene que comentar el elemento <filter-mapping> (en el web.xml) asociado al CAS, que generalmente tiene un elemento <filter-name> con valor casfilter.