Autenticación CAS en aplicaciones Fundeweb 2.0

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).

Configuración de la Aplicación

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-application.xml y añadimos dentro de la etiqueta <prefer-application-packages> la etiqueta <package-name>org.hibernate.validator.*</package-name>.

Precauciones

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.

Autenticación con 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:

filtro-local.properties

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


filtro-desarrollo.properties

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


filtro-preproduccion.properties

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


filtro-produccion.properties

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:

Autenticación NORMAL

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 -->


Doble Factor de Autenticación - 2FA

El doble factor de autenticación en aplicaciones FundeWeb, lo podemos configurar de dos maneras:

  1. Toda la aplicación bajo el control del 2FA.
  2. Una parte de la aplicación bajo el control del 2FA.

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.

Una parte de la aplicación bajo el control del 2FA

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:

  • twoFactorUrlPattern: para poder especificar rutas de forma básica. Ejemplos:
<!-- 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"/>
  • twoFactorUrlRegexp: para poder especificar una rutas mediante una expresión regular. Ejemplos:
<!-- 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.

Autenticación Cl@ve

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.

  • Si la aplicación no está dada de alta aún en el CAS, hay que seguir la información de la wiki Sección de Telemática - Alta de Aplicaicones en el CAS.
  • Si la aplicación ya está dada de alta en el CAS, hay que poner un jira a DJ-AT-Telemática componente AUT-AUT con la url de la aplicación, que ya está dada de alta en el CAS, e indicando que se necesita añadir el método Cl@ve y que se pasen los atributos FamilyName y FirstName.


Autenticación SAML

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 -->


Autenticación TOKEN PROXY

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);
        }

Obtener atributos del CAS

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()
    ....

Controlar la "Salida de Sessión"

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.

Salida de Sesión 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.

Salida de Sesión de la Aplicación

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):

messages_es.properties
#---- 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.
messages_en.properties
#---- 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.

Salida de Sesión de la Aplicación y del 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.

Deshabilitar el 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

  • fdw2.0/fundeweb2.0/gt/autenticacion_cas.txt
  • Última modificación: 29/11/2023 12:44
  • por JUAN MIGUEL BERNAL GONZALEZ