ATLAS MANUAL DE USUARIO SERVICIO DE AUTENTICACION Y AUTORIZACION

ATLAS MANUAL DE USUARIO SERVICIO DE AUTENTICACION Y AUTORIZACION Versión 1.11 Arquitectura de Software

Hoja de Control Título Documento de Referencia Responsable Manual de Usuario NORMATIVA ATLAS Área de Aplicaciones Especiales y Arquitectura de Software Versión 1.11 Fecha Versión 10/12/2014 Registro de Cambios Versión Causa del Cambio Responsable del Cambio Fecha 1.0 Versión inicial del documento Arquitectura de Software 26/05/2010 1.1 Modificado acceso al identificador de usuario a través de la clase UserUtil Arquitectura de Software 27/07/2010 1.2 Refactorizado los estilos de los apartados Arquitectura de Software 16/02/2011 1.3 Las preguntas frecuentes se consultarán en el portal de arquitectura. Se modifica el nombre del Area 1.4 Incluida política para sólo certificado digital, y documentado ROLE_PUBLIC 1.5 Apartado 4.4, personalización de las páginas: posibilidad de ocultar la información del usuario contectado y el botón de logout. Revisión de políticas disponibles Documentado el cambio de la variable app.name en el fichero application.properties si se utiliza politicausuariointranet 1.6 Apartado 4.4, movidas variables app.name y app.id.certificate al fichero environment.properties. 1.7 Apartado 3.2.1 explicación del fichero politicademo.xml, Apartado 4.2 explicación de ocultar botones o columnas en función de un rol Apartado 4.4 Obtención de la IP del usuario desde la cabecera http Arquitectura de Software Arquitectura de Software Arquitectura de Software Arquitectura de Software Arquitectura de Software 05/07/2011 21/06/2012 25/10/2012 03/01/2013 01/07/2013 1.8 Apartado 3.2.1: Incluida la política de Gsta (politicagsta). Arquitectura de Software 17/12/2013 2 de 27

1.9 Apartado 1.1.2 : Modificada definición de filtersecurityinterceptor para politicasolocertificado 1.10 Apartado 1.1.2: Añadida nota sobre la asignación de ROLE_X. Apartado 4.6: Se añade el tag de visualización por Rol 1.11 Apartado 3.2.6 Características particulares de la política solocertificado 3.2.Asociación de roles a URLs leyendo de Base de datos Apartado 4.7: Añadida variable para cerrar la ventana al desconectarse de la aplicación si la política es SoloCertificado 3.2.8 Características particulares de las políticas con Token Arquitectura de Software Arquitectura de Software Arquitectura de Software 16/05/2014 16/06/2014 10/12/2014 3 de 27

Índice 1 INTRODUCCIÓN... 5 1.1 AUDIENCIA OBJETIVO... 5 1.2 CONOCIMIENTOS PREVIOS... 5 2 DESCRIPCIÓN... 6 3 INSTALACIÓN Y CONFIGURACIÓN... 9 3.1 INSTALACIÓN... 9 3.2 CONFIGURACIÓN... 9 3.2.1 Asignación de políticas de acceso... 9 3.2.2 URLs securizadas... 12 3.2.3 Asociación de roles a URLs... 12 3.2.4 Asociación de roles a URLs leyendo de Base de datos... 13 3.2.5 URLs de las páginas de login, no autorizado, error, por defecto, etc.... 15 3.2.6 Configuración de Entorno Sin Seguridad... 16 3.2.7 Características particulares de la política solocertificado... 17 3.2.8 Características particulares de las políticas con Token... 18 4 USO... 19 4.1 OBTENCIÓN DE DATOS DE USUARIO... 19 4.2 DISTINCIÓN DE USUARIOS POR ROLES... 20 4.3 OBTENCIÓN DE DATOS DEL CERTIFICADO DIGITAL... 21 4.4 OBTENCIÓN DE LA IP DEL USUARIO DESDE LA CABECERA HTTP... 22 4.5 PERSONALIZACIÓN DE LAS PÁGINAS... 22 4.6 TAG DE VISUALIZACIÓN DEPENDIENTE DE ROLES... 22 4.6.1 USO... 23 4.6.1.1 PASO 1: DECLARACIÓN DEL OBJETO CONTENEDOR EN EL BEAN DE RESPALDO... 23 4.6.1.2 PASO 2: DEFINICIÓN DEL ESPACIO DE NOMBRES DE ETIQUETAS DE ATLAS... 25 4.6.1.3 PASO 3: INSERCIÓN EN LA PÁGINA DE LA ETIQUETA ATLAS:CONTENEDORROL... 25 4.7 LOGOUT CON CERTIFICADO... 26 5 PREGUNTAS MÁS FRECUENTES... 27 6 ENLACES RELACIONADOS... 27 GLOSARIO DE TÉRMINOS... 27 4 de 27

1 INTRODUCCIÓN Éste documento contiene el Manual de Usuario del del Módulo de Seguridad de Atlas. En él se incluye la autenticación de usuarios a través de las distintas políticas permitidas en ICM, así como la configuración de la autorización del acceso de los usuarios a las distintas áreas de una aplicación en función de su ROL. 1.1 Audiencia objetivo Éste Manual está orientado a los desarrolladores de aplicaciones web sobre el framework Atlas, que por tanto hagan uso del Módulo de Seguridad para autenticación y autorización en sus aplicaciones. 1.2 Conocimientos Previos Para un completo entendimiento del documento, el lector deberá tener conocimientos previos sobre las siguientes tecnologías: - Lenguaje Java - Extensible Markup Language (XML) - Spring Framework - Spring Security - Maven Para saber más sobre dichas tecnologías, consultar los accesos referenciados en el apartado Enlaces Relacionados. 5 de 27

2 DESCRIPCIÓN La Comunidad de Madrid dispone de aplicaciones de carácter público y privado, dependiendo, tanto del tipo de función que desempeñan como del tipo de usuarios al que van dirigidas. En el framework Atlas se ha desarrollado el para cubrir este requisito de gestión de accesos. Las aplicaciones de carácter privado limitaran su acceso a determinados usuarios. La forma de acceder a este tipo de aplicaciones puede ser mediante dos mecanismos: certificado digital y/o login/password. Los usuarios que tienen su acceso permitido a determinadas aplicaciones estarán dados de alta en alguno de los repositorios que la Comunidad de Madrid dispone. En estos repositorios de usuarios se encuentra toda la información de los usuarios y sus perfiles o roles de trabajo para cada aplicación. Estos repositorios son los que se muestran a continuación: Política LDAP USU USUI USUJ Repositorio a validar y acciones Almacena los datos de login de los usuarios de la intranet. Se utiliza para la autenticación de los usuarios. Repositorio de usuarios y perfiles de la Comunidad de Madrid. Se utiliza para la autorización de los usuarios. Repositorio de usuarios y perfiles de la Comunidad de Madrid con acceso desde Internet. Se utiliza para la autenticación y autorización de los usuarios. Repositorio de usuarios y perfiles de la Comunidad de Madrid para aplicaciones de Justicia. Se utiliza para la autenticación y autorización de los usuarios. Para el framework Atlas se han definido unas políticas de acceso para las aplicaciones que consisten en la definición de unas reglas de validación de acceso de los usuarios. Estas políticas indican cual es el mecanismo de acceso, contra que repositorios se deben llevar a cabo el proceso de autenticación, así como otras medidas a adoptar. A continuación se muestra una tabla con la lista de políticas de acceso que se han definido para Atlas y que se pueden utilizar en las aplicaciones web. Tipo Prohibido Público Solo Certificado Repositorio a validar y acciones No se permite nunca el acceso Se permite siempre el acceso Validar Certificado contra la plataforma multipki de ASF 6 de 27

Usuario Intranet Usuario Internet Usuario Justicia Demo Validar el usuario contra LDAP y recoger el rol de USU Validar Certificado (multipki) o validar el usuario y recoger su rol en USUI Validar Certificado (multipki) o validar el usuario y recoger su rol en USUJ Política para desarrollo en la cual no es necesario disponer de ningún repositorio. Los usuarios de pruebas se definen en un fichero xml. Estas políticas se definen en un sitio único para todas las aplicaciones de Atlas, de esta forma cualquier cambio que se realice en la configuración de las mismas no supone tener que realizar modificaciones en la aplicaciones. Por ejemplo si se cambia la dirección o puertos de la configuración del repositorio LDAP se cambiaría en la configuración de las políticas y ya estaría efectivo el cambio para todas las aplicaciones Atlas. En algunas aplicaciones se puede dar el caso de que, dependiendo del entorno desde donde se acceda a la aplicación, la forma de autenticación sea distinta. Por ejemplo: una autenticación con certificado si la aplicación es accedida desde internet y permitir acceso mediante usuario/contraseña para los accesos desde la intranet. El de usuarios permite que dependiendo del dominio/host al que se conecte el usuario se presente una política de acceso u otra, según se halla definido en la aplicación a la que se está accediendo. El se construye sobre la tecnología de Spring Security y además implementa una serie de funcionalidades extra: Definición de políticas de acceso. Gestión de políticas de acceso de forma externa a la aplicación. Asignación de políticas de autenticación en función del nombre de dominio al que el usuario accede. Single-Sign-On entre aplicaciones para una misma política (por tiempo y/o sesión de navegador). Bloqueo de cuentas de usuario frente a intentos de login fallidos. El single-sign-on permite realizar un login automático para los usuarios que ya se hayan identificado previamente en una aplicación con la misma política de acceso. Para poder realizar esta operación, una vez que el componente ha validado el usuario, se crea una cookie de sesión en el navegador del usuario con el nombre de la política utilizada. De esta forma, cuando un usuario accede a una aplicación, el componente de autorización deberá comprobar la existencia de una cookie de sesión, cuyo nombre corresponda con alguna de las políticas de acceso configuradas en la aplicación. Una vez recuperada, desencriptará el contenido y realizará la comprobación de la autenticación con los datos que encuentra dentro de la cookie. La autorización de acceso a una aplicación estará basada en los roles a los que pertenezca un usuario. Para 7 de 27

esta tarea se va a utilizar la propia funcionalidad de Spring-Security (Acegi) y la configuración de los componentes gráficos JSF. Mediante los roles, un usuario tendrá definido su nivel de acceso a las diferentes áreas y componentes de las aplicaciones, que por sus características, deban de tener controlado el acceso. Por ejemplo áreas de administración de una aplicación, editar o modificar valores en pantalla, etc. Hay que destacar que el módulo Spring-Security (Acegi), permite tener el control de la autorización a varios niveles: Autorización a nivel de recursos Web. Podrá limitarse el acceso a ciertos recursos de la aplicación Web en función de los roles que posea la persona autentificada. Autorización a nivel de métodos de clases de negocio. Podrá limitarse los métodos de las clases que se pueden invocar en función de los roles del usuario. El arquetipo de aplicaciones web de Atlas ya viene con la configuración base del Servicio de Autenticación y Autorización de Usuarios y mediante configuración se personalizará para los requisitos de acceso de nuestro aplicativo. La configuración que es necesario realizar es: Asignación de políticas de acceso Asignación de url securizadas Asignación de roles a urls Adicionalmente, desde el código de la aplicación puede accederse a otra información del usuario autenticado: Obtención de los datos personales del usuario autenticado (Nombre, Apellidos, DNI, etc.). Obtención de los roles de un usuario, para decidir realizar unas acciones u otras en función de si un usuario tiene un determinado ROL Obtención de los datos del certificado digital (en caso de que el usuario se haya autenticado utilizando un certificado). En los siguientes apartados se detalla cómo realizar la configuración del arquetipo, así como la forma en la que se puede acceder a los datos del usuario autenticado. 8 de 27

3 INSTALACIÓN Y CONFIGURACIÓN En este apartado se incluye información sobre la instalación y la configuración del Servicio de Autenticación y Autorización de Usuarios de Atlas. 3.1 INSTALACIÓN El de Usuarios se distribuye como un artefacto Jar desplegado en el Artifactory de ICM integrado por defecto en el Arquetipo Web, por lo que si se utiliza dicho arquetipo como punto de partida no será necesaria una instalación manual del componente. 3.2 CONFIGURACIÓN 3.2.1 Asignación de políticas de acceso El de Usuarios permite asignar diferentes políticas de autenticación en función del nombre del host al que se ataca, esto nos permite definir por ejemplo una forma de acceso distinta para intranet y otra para internet. La definición de las políticas se realiza en el fichero applicationcontext-security-hostpolitica.xml (que se encuentra en la carpeta src/main/resources/conf del módulo web de la aplicación). En éste fichero existe un bean llamado applicationcontext-security-hostpolitica al que, en el constructor, se le pasa un mapa java ( java.util.map ) con una entrada por nombre de host al que se le quiera asignar una política. La clave ( key ) de cada entrada es el nombre del host y el valor ( value ) el nombre de la política. applicationcontext-security-hostpolitica.xml [...] <beans:bean name="applicationcontext-security-hostpolitica" id="applicationcontext-security-hostpolitica" class="java.util.hashmap"> <beans:constructor-arg> <beans:map> <beans:entry key="intranet.madrid.org" value="politicausuariointranet"/> <beans:entry key="gestiona.madrid.org" value="politicausuariointernet"/> </beans:map> </beans:constructor-arg> </beans:bean Aquí se muestra un ejemplo de una aplicación en la que si se entra por el dominio de intranet va a utilizar la políticausuariointranet y si entra por el dominio de Internet va a utilizar la politicausuariointernet. 9 de 27

Los posibles valores para los valores de las políticas son: Nombre Política ATLAS Descripción politicaprohibido politicadesactivada politicasolocertificado politicausuariointranet No se permite nunca el acceso Se permite siempre el acceso Validar Certificado contra la plataforma multipki de ASF Validar el usuario contra LDAP y recoger el rol de USU. politicausuariointranettoken Validar el usuario contra LDAP y recoger el rol de USU. Valida también desde el Token Single Sign ON y recoge el rol de USU politicausuariointernet Validar Certificado (multipki) o validar el usuario y recoger su rol en USUI politicausuariointernettoken Validar Certificado (multipki) o validar el usuario y recoger su rol en USUI Valida también desde el Token Single Sign ON y recoge el rol de USUI politicausuariojusticia politicademo politicagsta Validar Certificado (multipki) o validar el usuario y recoger su rol en USUJ Política para desarrollo en la cual no es necesario disponer de ningún repositorio. Los usuarios de pruebas se definen en un fichero de pruebas llamado politicademo.xml. Política especial para aplicaciones del Gestor de Expedientes Gsta / Atlantix 10 de 27

Nota Si se utiliza la politicausuariointranet que valida el usuario contra LDAP y recoge el rol del modelo de datos de USU, para poder realizar dichas acciones se utiliza una variable denominada app.name que está definida en el fichero src/main/resources/environment.properties. Si se utiliza la politicausuariointernet que valida el usuario con certificado y recoge el rol del modelo de datos de USUI, para poder realizar dichas acciones se utiliza una variable denominada app.id.certificate que está definida en el fichero src/main/resources/environment.properties. Se deberán revisar que dichas variables corresponde con el nombre de aplicación que deseamos: environment.properties ###################################################### # Fichero de propiedades donde se configuran todos # # los parametros de la aplicación que no necesitan # # una configuración diferente para cada entorno (su # # valor es el mismo en el entorno de desarrollo # # local, validación y producción) # ###################################################### [...] # Ids de aplicacion # Identificador de la aplicacion utilizado para las tablas de USU (intranet) app.name=xxxx # Identificador de la aplicacion utilizado para tablas de USUI (internet) app.id.certificate=xxxx # Identificador de la aplicacion utilizado en ASF app.id.asf=apl_demo Para el desarrollo de las aplicaciones se utilizará la politicademo. El resto de políticas se configurarán solamente cuando se realice la instalación de la aplicación en ICM, realizando modificaciones en los ficheros environment.properties correspondientes a los distintos entornos. Nota Para el desarrollo en local existe un fichero /src/main/resources/conf/politicademo.xml que contiene los usuarios y roles para pruebas. Por defecto están creados los siguientes usuarios: Admin con ROLE_1 y ROLE1 Usuario_ok con ROLE_1 Usuario_locked con ROLE_1 (usuario bloqueado por defecto) 11 de 27

3.2.2 URLs securizadas El de Usuarios permite definir qué rol es necesario para acceder a determinadas URLs. Esto se hace configurando el fichero applicationcontext-general.xml. Las rutas que requieren autenticación independientemente del rol que se les desee asignar están fijadas para todas las aplicaciones. Todas las páginas seguras deberán incluirse en el directorio /secure. Este directorio ya está creado para el arquetipo web. Los contenidos fuera de este directorio /secure podrá ser accedido por todos los usuarios de la aplicación. Es imprescindible que la página de login no esté securizada, así como las de errores de seguridad. También es buena idea no hacer pasar por los filtros de seguridad (poner en rutas no securizadas) imágenes y scripts (p.ej. JavaScript) que no lo requieran. 3.2.3 Asociación de roles a URLs El siguiente paso consiste en asignar roles a URLs previamente autenticadas (según el ejemplo anterior). Esto se hace en la propiedad objectdefinitionsource del bean filtersecurityinterceptor. En la siguiente ilustración se puede ver un ejemplo de configuración de un filtersecurityinterceptor en el que se requiere el rol ROLE_2 para acceder a las URLs /secure/admin./** y alguno de los roles ROLE_1 o ROLE_2 para acceder a las demás URLs del tipo /secure/**. Los roles ROLE_X se forman concatenando a la cadena ROLE_ el código del grupo de la tabla GRUPO de USU. Para ver los grupos de una aplicación se puede hacer el siguiente query, sustituyendo XXXX por el código de la aplicación que se quiera ver. Query para ver los grupos de una aplicación select * from grupo where cod_aplicacion='xxxx' 12 de 27

applicationcontext-general.xml <beans:bean id="filtersecurityinterceptor" class="org.springframework.security.intercept.web.filtersecurityinterceptor"> <beans:property name="authenticationmanager" ref="authenticationmanager"/> <beans:property name="accessdecisionmanager" ref="httprequestaccessdecisionmanager"/> <beans:property name="objectdefinitionsource"> <filter-invocation-definition-source lowercase-comparisons="true" path-type="ant"> <intercept-url pattern="/secure/admin/**" access="role_2"/> <intercept-url pattern="/secure/**" access="role_1,role_2"/> </filter-invocation-definition-source> </beans:property> </beans:bean> Nota Los patrones de URLs en los elementos <intercept-url> se han configurado de tipo Ant ( * = cualquier nombre, ** = en cualquier profundidad de directorios). El atributo lowercase-comparisons= true quiere decir que todos los patrones de URL deberán ser indicados en minúsculas ya que las URLs a que acceden los usuarios se convertirán en minúsculas para la comparación. Para más información sobre cómo configurar la propiedad objectdefinitionsource del bean FilterSecurityInterceptor, consultar la documentación de SpringSecurity. 3.2.4 Asociación de roles a URLs leyendo de Base de datos La configuración normal de una aplicación para asignar roles a url es la descrita en el punto anterior. Puede haber proyectos que necesiten cargar esta lista de url s y roles de Base de Datos o de un repositorio personalizado. Para esto ATLAS tiene previsto un objeto AtlasFilterInvocationDefinitionSource y una interfaz que habrá que implementar llamada AtlasUrlRolLoader. 13 de 27

Habrá que modificar el fichero applicationcontext-general.xml de la siguiente forma Framework Atlas applicationcontext-general.xml <!-- Configuración de roles de acceso a las URLs securizadas --> <bean id="filtersecurityinterceptor" class="org.springframework.security.intercept.web.filtersecurityinterceptor"> <property name="authenticationmanager" ref="authenticationmanager"/> <property name="accessdecisionmanager" ref="httprequestaccessdecisionmanager"/> <property name="objectdefinitionsource" ref="atlasobjectdefinitionsource" /> </bean> <bean id="atlasobjectdefinitionsource" class="atlas.core.seguridad.filters.atlasfilterinvocationdefinitionsource"> <property name="urlrolloader" ref="urlrolloader" /> </bean> <bean id="urlrolloader" class="atlas.core.seguridad.filters.atlasurlrolloadermock"> </bean> La parte en amarillo es el que cambia el FilterInvocationDefinitionSource por uno personalizado de ATLAS AtlasFilterInvocationDefinitionSource. Además de esto, en el proyecto habrá que crear un urlrolloader que herede de la interfaz AtlasUrlRolLoader. Por defecto existe un Mock (AtlasUrlRolLoaderMock) que tiene las siguientes asignaciones: ROLE_1 y ROLE_2 para las url /secure/** ROLE_1 para las url /secure/admin/** La interfaz a implementar es la siguiente: public interface AtlasUrlRolLoader { atlas.core.seguridad.filters.atlasurlrolloader } /** * Método que carga una lista con todas las url y asociada a cada url un * array de roles. * Las url pueden ir en formato Ant. * @see AtlasUrlRolLoaderMock * @return */ public LinkedHashMap<String, String[]> loadurlrol(); El bean AtlasFilterInvocationDefinitionSource tiene un método público refresh() que permite volver a recargar el mapa de url s y roles a travez del objeto urlrolloader. 14 de 27

3.2.5 URLs de las páginas de login, no autorizado, error, por defecto, etc. En el arquetipo web vienen predefinidas unas URLs estándar para las páginas relacionadas con la autenticación del usuario. La configuración de éstas URLs está en el fichero application.properties que está en la carpeta src/main/resources/conf del arquetipo web. En la siguiente tabla se muestran los parámetros de cada una de las páginas predefinidas en el arquetipo web, así como su valor (La modificación de estos valores ha de ser previamente autorizada por ICM): Parámetro Página Contenido app.url.noautorizado /login.jsf Página a la que redirigir si el usuario autenticado carece del rol necesario para acceder a un recurso. Es una propiedad que será bueno cambiarla en la politicasolocertificado app.url.login /login.jsf Página a la que redirigir para solicitar al usuario sus credenciales cuando intenta acceder a un recurso securizado y no está autenticado o cuando las credenciales son erróneas. app.url.error /errorpage.jsf Página a la que redirigir en caso de que se produzca un error intentando autenticar las credenciales de un usuario. app.url.cert.error /html/errorcertificado.jsf Página a la que redirigir en caso de que se produzca un error en el acceso con certificado. app.url.pordefecto /secure/index.jsf?id=1 Página a la que redirigir tras acceder a la URL de login y autenticarse correctamente. app.url.logout /logout.jsf Página a la que redirigir cuando se haga un logout en la aplicación app.url.sesionexpirada /sesionexpirada.jsf Página a la que redirigir cuando una sessión de usuario ha expirado. Nota Si el valor de éstas propiedades en el archivo application.properties comienza por una barra ( / ), se toma como URL relativa al contexto de la aplicación. En caso contrario, se toma como URL absoluta. 15 de 27

3.2.6 Configuración de Entorno Sin Seguridad En este apartado se describe cómo configurar una aplicación para que no tenga seguridad de usuario (por ejemplo, para una aplicación interna que no requiera autenticación). Para configurar la aplicación sin seguridad, hay que realizar los siguientes pasos: Copiar todos los archivos situados en src/main/webapp/secure al directorio src/main/webapp Reemplazar /secure por / en todos los archivos movidos. Reemplazar /secure/ por / en resources/conf/application.properties Reemplazar /secure/ por / en resources/menu.xml Reemplazar /secure/ por / en WEB-INF/faces-navigation.xml 16 de 27

3.2.7 Características particulares de la política solocertificado En este apartado se detalla la configuración específica para la politica solocertificado a) Indicar la policita solocertificado en el fichero applicationcontext-security-hostpolitica.xml en las máquinas que se desee según se explica en el punto 3.2.1 b) Indicar el ROLE_PUBLIC para todas las url del directorio secure. Si se utiliza la política denominada politicasolocertificado (validación del certificado digital contra la plataforma ASF), existe un nombre de rol especial denominado ROLE_PUBLIC, que se asigna automáticamente a aquellos usuarios que han accedido con certificado válido. Ejemplo de configuración para esta política: applicationcontext-general.xml <bean id="filtersecurityinterceptor" class="org.springframework.security.intercept.web.filtersecurityinterceptor"> <property name="authenticationmanager" ref="authenticationmanager" /> <property name="accessdecisionmanager" ref="httprequestaccessdecisionmanager" /> <property name="objectdefinitionsource"> <security:filter-invocation-definition-source lowercase-comparisons="true" path-type="ant"> <security:intercept-url pattern="/secure/**" access="role_public" /> </security:filter-invocation-definition-source> </property> </bean> c) Indicar la página de error de certificado Modificar la variable app.url.noautorizado del fichero application.properties application.properties # Configuracion de urls de aplicacion app.url.pordefecto=/secure/index.jsf?id=1 app.url.noautorizado=/html/errorcertificado.jsf app.url.login=/login.jsf app.url.error=/errorpage.jsf app.url.cert.error=/html/errorcertificado.jsf d) Añadir en el pom.xml del proyecto web la variable clientauth para que el tomcat7 local pida el certificado de usuario pom.xml del proyecto web <plugin> <groupid>org.apache.tomcat.maven</groupid> <artifactid>tomcat7-maven-plugin</artifactid> <version>${tomcat7-maven-plugin.version}</version> <configuration> <clientauth>true</clientauth> </configuration> </plugin> 17 de 27

3.2.8 Características particulares de las políticas con Token Las politicas politicausuariointranettoken y politicausuariointernettoken permiten acceder a la aplicación, además de por los mecanismos normales de cada política por un token generado desde el Web Service de Single Sign On cuya documentación se puede consultar en: http://intranet.madrid.org/arquitecturasw/otras-tecnologias/seguridad/itemlist/category/280-single-sign-on Este token se pasará por la url en un parámetro llamado ssoid Ejemplo de llamada con token Con esta llamada la apliación Atlas que recibe el token hará lo siguiente: 1. Comprobará la validdez del token 2. Obtendrá del token el usuario ya autenticado por el Servicio Web FESB 3. Se logará en la aplicación Atlas automáticamente con este usuario sin pasar por la pantalla de login 4. Buscará el rol asociado al usuario en las tablas de usu o usui según corresponda a la politica. 18 de 27

4 USO Una vez instalado y configurado, el componente de seguridad trata las peticiones antes de que lleguen a la aplicación y gestiona todo lo relacionado con la autenticación y autorización de usuarios. Adicionalmente a la autenticación y autorización ya configuradas, se puede acceder a cierta información del usuario autenticado desde el código de la aplicación. Dichos usos desde el código se describen en los siguientes apartados. 4.1 Obtención de datos de usuario Siempre que el usuario haya sido autenticado, se dispondrá de los datos de dicho usuario para poder ser utilizados desde la aplicación, según se muestra en el siguiente ejemplo: import atlas.core.seguridad.atlasauthenticationdetails; String usr = UserUtil.getUserName(); logger.info("usuario: " + usr); String pass = UserUtil.getPassword(); logger.info("contraseña: " + pass); AtlasAuthenticationDetails details = UserUtil.getUserDetails(); if(details == null) { // Usuario no autenticado } else { // Usuario autenticado Map<String, String> otrainfo = details.getotrainfo(); String email= otrainfo.get("email"); logger.info("email: "+email); } Para acceder a dichos datos se puede invocar el método estático getuserdetails de la clase UserUtil, que devuelve una instancia de AtlasAuthenticationDetails. Sobre esta instancia se puede invocar el método getotrainfo que devuelve un Map con los valores de los datos asociados al usuario. 19 de 27

En la siguiente tabla, se pueden ver los campos que se pueden obtener del Map de propiedad otrainfo del objeto AtlasAuthenticationDetails: Clave Descripción Notas USERNAME Identificador del usuario No utilizar este método ya que no se garantiza que funcione con todas las políticas. Utilizar UserUtil.getUserName() NOMBRE Nombre del usuario En el caso de la política Intranet, contiene el nombre y los apellidos APELLIDO1 Primer apellido En blanco en la política Intranet APELLIDO2 Segundo apellido En blanco en la política Intranet NOMBRECOMPLETO Nombre y apellidos DNI DNI En blanco en la política Intranet DIRECCION TELEFONO ORGANISMO Dirección Teléfono Organismo en el que trabaja DEPENDENCIA Dependencia En blanco en las políticas: Internet, Justicia PUESTOTRABAJO Puesto de trabajo En blanco en las políticas: Internet, Justicia EMAIL Dirección de correo electrónico En blanco en las políticas: Intranet, Justicia 4.2 Distinción de Usuarios por ROLES En ocasiones, desde el código podemos querer comprobar si el usuario autenticado tiene un determinado ROL, para realizar acciones diferentes dependiendo de su ROL (por ejemplo, mostrar/ocultar botones en función de si el usuario es administrador). Nota Todos los componentes JSF tienen una propiedad rendered que indica si ese componente se va a mostrar en pantalla o no. Se puede usar un método del Bean para indicar si se deben o no mostrar algunos componentes, por ejemplo en función del rol del usuario. Ejemplo: <h:commandlink action="#{mibean.grabar}" rendered="#{mibean.permitiractualizar}" <h:outputtext value="grabar registro /> </h:commandlink> Para una lista paginada de Atlas hay una propiedad mostrarcolumna que indica si una columna se va mostrar en pantalla o no. Para otros componentes de Atlas consultar la documentación específica. 20 de 27

Para acceder a los roles de un usuario se puede invocar el método estático getuserroles de la clase UserUtil, que devuelve un array de objectos de tipo GrantedAuthority. Sobre cada GrantedAutority se puede invocar al método getauthority que devuelve el nombre del rol (utilizando el método tostring). En el siguiente ejemplo se muestra cómo acceder a los roles del usuario autenticado: ClaseEjemplo.java GrantedAuthority[] userroles = UserUtil.getUserRoles(); if (userroles!= null) { for (GrantedAuthority role : userroles) { log.info("rol: " + role.getauthority().tostring()); } } else { log.info("sin roles"); } 4.3 Obtención de Datos del Certificado Digital Si el usuario se ha autenticado utilizando un certificado digital, es posible acceder a los datos de dicho certificado utilizando el método getusercertificate de la clase UserUtil, según el siguiente ejemplo: ClaseEjemplo.java X509Certificate cert = UserUtil.getUserCertificate(); Si se quiere directamente acceder a los datos del certificado, se puede utilizar el método obtenerdatoscertificado de la clase AsfService, que devuelve un objeto listo para obtener de él los datos del certificado. Este método recibe como parámetro el certificado que se ha obtenido según el ejemplo anterior. Ejemplo que muestra los datos del certificado por el log: ClaseEjemplo.java // Se asume que en el contexto está declarado el servicio de ASF AsfService asfservice = (AsfService) appcontext.getbean( nombrebeanasf ); DatosCertificado dc = asfservice.obtenerdatoscertificado(userutil.getusercertificate()); logger.log("nombre: " + dc.commonname); logger.log("apellidos: " + dc.apellidos); 21 de 27

4.4 Obtención de la IP del usuario desde la cabecera http Framework Atlas Si se necesita obtener la IP del usuario que está haciendo alguna acción se puede hacer llamando al método estático getip(httpservletrequest request) de la clase atlas.core.seguridad.util.requesthelper Este método mira primero el parámetro "ClientIp" de la cabecera y si no lo encuentra busca en el remote address. ClaseEjemplo.java Import atlas.core.seguridad.util.requesthelper; HttpServletRequest httpservletrequest = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest(); String ip = getip(httpservletrequest); 4.5 Personalización de las páginas Es posible personalizar ciertos elemento de las páginas dependiendo de las necesidades de la política. En la cabecera aparecen el nombre del usuario conectado y un botón para hacer logout. En el application.properties de la aplicación hay dos variables para controlar si deben aparecer o no: application.properties # Configuración para mostrar o no el usuario contectado y el botón de logout en la cabecera app.userinfo=true app.logout=true 4.6 Tag de visualización dependiente de ROLES Si se necesita poder visualizar determinados bloques en las páginas jsf dependiendo del rol que tenga asignado el usuario, se puede utilizar la etiqueta <atlas:contenedorrol>. Se le debe indicar a la etiqueta los roles que son necesarios para poder visualizar el contenido dentro de las etiquetas (si son más de uno deben ir separados por comas), y si el usuario autenticado tiene uno o varios de los roles indicados, el contenido se mostrara. Si el usuario no tiene uno de los roles permitidos, o no hay usuario autenticado, el contenido no se mostrara. 22 de 27

4.6.1 Uso En este caso los pasos a seguir son los siguientes: 4.6.1.1 Paso 1: Declaración del objeto contenedor en el bean de respaldo El bean de respaldo de la página debe definirse en el fichero de configuración de JSF que puede encontrarse en el proyecto web generado por el arquetipo bajo este nombre: \src\main\webapp\web-inf\faces-managed-beans.xml. En dicho bean debe crearse un objeto de tipo atlas.componente.bean.contenedorrolbean e inicializarlo. Por cada contenedor será necesario crear un objeto de este tipo. ContenedorRolSampleBean.java 23 de 27

/** * The Class ContenedorRolSampleBean. */ public class ContenedorRolSampleBean {... /** * Servicio de la fachada */ private EjplFacade facade; /** * Contenedor */ private ContenedorRolBean contenedor; /** * {@inheritdoc} */ public void init() { this.contenedor = new ContenedorRolBean(); } /** * @return el contenedor */ public ContenedorRolBean getcontenedor() { return contenedor2; } /** * @param contenedor */ public void setcontenedor(contenedorrolbean contenedor) { this.contenedor = contenedor; } /** * @return la fachada */ public EjplFacade getfacade() { return facade; } /** * @param facade. * Asocia la fachada al Backing Bean */ public void setfacade(ejplfacade facade) { this.facade = facade; } }... 24 de 27

4.6.1.2 Paso 2: Definición del espacio de nombres de etiquetas de Atlas Framework Atlas Es necesario crear un fichero xhtml y establecer la definición del espacio de nombres para las etiquetas de componentes de Atlas. Un ejemplo de cabecera de fichero xhtml es la siguiente: <?xml version="1.0" encoding="utf-8"?> Cabecera de fichero xhtml <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/tr/xhtml1/dtd/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:atlas="http://atlas.core.componentes/jsf" xmlns:a4j="http://richfaces.org/a4j"> 4.6.1.3 Paso 3: Inserción en la página de la etiqueta atlas:contenedorrol Es necesario insertar la etiqueta contenedorrol en el formulario de una página. Un ejemplo de contenedorrol es el siguiente: Ejemplo.xhtml <atlas:contenedorrol id="bloquerole1" rolesacceso="role_1, ROLE_2" datamodel="#{ejemplobasicolpbean.contenedor1}"> <ul> <li> <h:outputtext styleclass="label" value="#{bundle['lp.descripbasico']}" /> </li> <li class="sangrialista"> <h:outputtext styleclass="label" value="#{bundle['lp.descripbasico2']}" /> </li> </ul> </atlas:contenedorrol> 25 de 27

4.7 Logout con certificado Existe un problema al realizar logout desde aplicaciones que poseen acceso por certificado, el cual, aunque se realize correctamente el logout a nivel de aplicación, no lo hace a nivel de navegador, por lo que, al detectar el certificado, la aplicación vuelve a conectar automáticamente. Para solucionar este problema, se ha creado una página de logout, que en caso de haber entrado por certificado mostrará un mensaje al usuario informando que debe cerrar el navegador. Este mensaje es personalizable con la siguiente Key del fichero de mensajes de aplicación: messages_es.properties logout.existecert = Por favor, para salir completamente de la aplicaci\u00f3n cierre el navegador. 26 de 27

5 PREGUNTAS MÁS FRECUENTES La lista de preguntas frecuentes se encuentra en el portal de arquitectura. 6 ENLACES RELACIONADOS Producto Lenguaje Java Extensible Markup Language (XML) Spring Framework Spring Security Maven URL http://java.sun.com/docs/books/jls/third_edition/html/j3toc.html http://www.w3.org/xml/ http://www.springframework.org/ http://static.springframework.org/spring-security/site/ http://maven.apache.org/ GLOSARIO DE TÉRMINOS Término Dominio Descripción Arquetipo Maven Plantilla de una aplicación Maven Artefacto Maven Pieza de software, generalmente empaquetada en un jar o war Artifactory Maven Repositorio versionado de artefactos de Maven POM Maven Project Object Model. Fichero de Maven que describe un artefacto, sus dependencias y sus procesos automáticos (compilación, pruebas unitarias, empaquetado, despliegue, etc ), en otras cosas. Bean Spring En terminología de Spring, un bean es un POJO (objeto) Java Contenedor de beans Spring Objeto de Spring responsable de mantener una serie de beans Contexto de aplicación Spring Es un contendor de beans propio de la aplicación. Se configura en el web.xml y generalmente se define en el fichero applicationcontext.xml Inyectar Spring Establecer una propiedad de un bean desde el contexto de aplicación 27 de 27