ATLAS MANUAL DE USUARIO SERVICIO DE AUTENTICACION Y AUTORIZACION

Transcripción

1 ATLAS MANUAL DE USUARIO SERVICIO DE AUTENTICACION Y AUTORIZACION Versión 1.4 Área de Aplicaciones Especiales y Arquitectura de Software

2 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.4 Fecha Versión 21/06/2012 Registro de Cambios Versión Causa del Cambio Responsable del Cambio Fecha del Cambio 1.0 Versión inicial del documento Área de Integración y Arquitectura de Aplicaciones 26/05/ Modificado acceso al identificador de usuario a través de la clase UserUtil 1.2 Refactorizado los estilos de los apartados 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 Área de Integración y Arquitectura de Aplicaciones Área de Aplicaciones Especiales y Arquitectura de Software Área de Aplicaciones Especiales y Arquitectura de Software Área de Aplicaciones Especiales y Arquitectura de Software 27/07/ /02/ /07/11 21/06/12 2 de 16

3 Índice 1 INTRODUCCIÓN AUDIENCIA OBJETIVO CONOCIMIENTOS PREVIOS DESCRIPCIÓN INSTALACIÓN Y CONFIGURACIÓN INSTALACIÓN CONFIGURACIÓN Asignación de políticas de acceso URLs securizadas Asociación de roles a urls URLs de las páginas de login, no autorizado, error y por defecto Configuración de Entorno Sin Seguridad USO OBTENCIÓN DE DATOS DE USUARIO DISTINCIÓN DE USUARIOS POR ROLES OBTENCIÓN DE DATOS DEL CERTIFICADO DIGITAL PREGUNTAS MÁS FRECUENTES ENLACES RELACIONADOS GLOSARIO DE TÉRMINOS de 16

4 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. 4 de 16

5 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 Público 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 5 de 16

6 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 6 de 16

7 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. 7 de 16

8 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 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. Los posibles valores para los valores de las políticas son: 8 de 16

9 Nombre Política ATLAS politicaprohibido politicadesactivada No se permite nunca el acceso Se permite siempre el acceso Descripción politicasolocertificado Validar Certificado contra la plataforma multipki de ASF politicausuariointranet Validar el usuario contra LDAP y recoger el rol de USU politicausuariointernet Validar Certificado (multipki) o validar el usuario y recoger su rol en USUI politicausuariojusticia Validar Certificado (multipki) o validar el usuario y recoger su rol en USUJ politicademo 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. 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 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. 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 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 objectdefinitiondatasource 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/**. applicationcontext-general.xml 9 de 16

10 <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 Para más información sobre cómo configurar la propiedad objectdefinitiondatasource del bean FilterSecurityInterceptor, consultar la documentación de SpringSecurity. Nota para politicasolocertificado 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: <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/**" access="role_public"/> </filter-invocation-definition-source> </beans:property> </beans:bean> 10 de 16

11 1.1.3 URLs de las páginas de login, no autorizado, error y por defecto. 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 urlnoautorizado /login.jsf Página a la que redirigir si el usuario autenticado carece del rol necesario para acceder a un recurso urllogin /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 urlerror /errorpage.jsf Página a la que redirigir en caso de que se produzca un error intentando autenticar las credenciales de un usuario otrosparametros.urlpordefecto /secure/index.jsf Página a la que redirigir tras acceder a la URL de login y autenticarse correctamente. 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 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 11 de 16

12 2 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. 2.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: ClaseEjemplo.java 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 = otrainfo.get(" "); logger.info(" "+ ); } 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. 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 12 de 16

13 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 Dirección de correo electrónico En blanco en las políticas: Intranet, Justicia 2.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). 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(int i=0; i<userroles.length; i++) { logger.log("rol: " + userroles[i].getauthority().tostring()); } } else { logger.log("sin roles"); } 2.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(); 13 de 16

14 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); 14 de 16

15 3 PREGUNTAS MÁS FRECUENTES La lista de preguntas frecuentes se encuentra en el portal de arquitectura. 15 de 16

16 4 ENLACES RELACIONADOS Producto Lenguaje Java Extensible Markup Language (XML) Spring Framework Spring Security Maven URL 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 16 de 16