Gestin de Registros y Respaldos en el Contexto Hospitalario.

Proyecto de grado
Edicin 2009

Seguridad en aplicaciones Java EE - ICEFaces

Supervisores: Mara Eugenia Corti Ariel Sabiguero

Responsables: Julio Carrau Gustavo Perez

Estudiantes: Martn Calabria Gonzalo Perretti

Gestin de Registros y Respaldos en el Contexto Hospitalario

Contenido
1. Arquitectura de seguridad JavaEE.............................................................................................. 3 1.1. Seguridad a nivel de capa de aplicacin..................................................................................... 5 1.2. Seguridad a nivel de capa de transporte: .............................................................................. 6 1.3. Seguridad a nivel de capa de mensaje: ...................................................................................... 7 2. Seguridad para una aplicacin web ........................................................................................... 9 3. Seguridad Ajax en ICEFaces...................................................................................................... 14 4. Conclusiones............................................................................................................................. 17 5. Referencias............................................................................................................................... 18

Seguridad en aplicaciones Java EE - ICEFaces

Gestin de Registros y Respaldos en el Contexto Hospitalario

1. Arquitectura de seguridad JavaEE

Cada tipo de aplicacin java (Java EE, web, web service) se despliega sobre determinado contenedor, el cual se encarga de brindar soporte para la seguridad en dichas aplicaciones. Un contenedor proporciona dos mecanismos de seguridad: declarativo y programtico. Declarativo: Utiliza descriptores de despliegue (deployment descriptors) en cada aplicacin para especificar los requerimientos de seguridad. Los descriptores son externos a la aplicacin y son ledos por el servidor en tiempo de ejecucin para determinar si un usuario tiene permitido el acceso a cierto recurso de cierta aplicacin. Java EE define un descriptor para cada tipo de componente: Para componentes EJB se utiliza el archivo ejb-jar.xml Para servicios web se utiliza el archivo jaxrpc-mapping-info.xml el cual realiza el mapeo entre java y el WSDL. Para componentes web se utiliza el descriptor de aplicacin web.xml.

En ellos se definen las reglas y roles para el acceso a los recursos de la aplicacin.

Programtico: Si el mtodo declarativo no es suficiente para resolver los requerimientos del modelo de seguridad e la aplicacin se puede introducir el cdigo necesario, el cual quedar embebido dentro de la aplicacin.

Un mecanismo de seguridad deber proveer las siguientes funcionalidades: Impedir el acceso no autorizado a recursos y datos de la aplicacin. Proteger el sistema de las interrupciones de los servicios que afectan la calidad del mismo. Facilidad de administracin. Transparencia a los usuarios del sistema. Interoperabilidad con otras aplicaciones.

Las aplicaciones java consisten de componentes que pueden tener tanto recursos protegidos como no protegidos. Los recursos protegidos requieren de autorizacin para ser accedidos. La autorizacin consiste en la identificacin y autenticacin del cliente que intenta acceder al recurso. El mecanismo de seguridad de la aplicacin deber definir los conjuntos de usuarios que podrn acceder a cada recurso.

Seguridad en aplicaciones Java EE - ICEFaces

Gestin de Registros y Respaldos en el Contexto Hospitalario Mecanismos de Implementacin de Seguridad en Java SE: JAAS: Java Authentication and Authorization es un conjunto de APIs que permiten realizar el control de acceso sobre usuarios. Su principal caracterstica es su extensibilidad para incorporar nuevos mecanismos de seguridad programticos. JCE: Java Cryptographic Extension brinda un framework e implementacin de algoritmos de encriptado (simtricos y asimtricos), generacin de claves, autenticacin de mensajes, manejo de almacenes de claves y certificados. JSSE: Java Secure Socket Extension provee un framework e implementacin de una versin java de los protocolos SSL y TLS.

Mecanismos de Implementacin de Seguridad en Java EE: Son provistos por el contenedor en el cual la aplicacin se encuentra desplegada, y pueden implementarse declarativa o programticamente.

Seguridad en aplicaciones Java EE - ICEFaces

Gestin de Registros y Respaldos en el Contexto Hospitalario

1.1.

Seguridad a nivel de capa de aplicacin

El contenedor se encarga de proveer la seguridad en la capa de aplicacin y adems es posible utilizar cortafuegos para mejorar la proteccin de las comunicaciones entrantes. Sin embargo, los datos dejan de ser seguros una vez que abandonan el contexto de la aplicacin. Esto no es problema para las aplicaciones tradicionales, pero si se trata de un servicio web, en el cual los datos viajan por canales no seguros, es necesario utilizar los mecanismos de seguridad a nivel de capa de transporte y capa de mensaje.

Las ventajas de la seguridad en capa de aplicacin son: Seguridad adaptada nicamente a las necesidades de la aplicacin. Seguridad de granularidad fina, con configuraciones especificas para la aplicacin.

Las desventajas son: La seguridad depende de los atributos de seguridad, los cuales no son tranferibles entre tipos de aplicacin. Soporte para multiples protocolos hace vulnerable a este mecanismo de seguridad. Los datos estn cerca, o contenidos dentro del punto de vulnerabilidad.

Seguridad en aplicaciones Java EE - ICEFaces

Gestin de Registros y Respaldos en el Contexto Hospitalario

1.2.

Seguridad a nivel de capa de transporte:

Este tipo de seguridad es provisto por los mecanismos de transmisin de datos sobre el cable entre el cliente y el servidor, por lo tanto se basa en el protocolo HTTPS usando SSL. La seguridad en la capa de tranporte es un mecanismo punto a punto de autenticacin, integridad y confidencialidad de datos. Fases de ejecucin: Cliente y Servidor acuerdan el algoritmo de encriptacin de datos. Una clave es intercambiada utilizando encriptacin de clave pblica y autenticacin basada en certificados. Cifrado simtrico es utilizado para el intercambio de informacin.

Ventajas: Tecnologa simple de utilizar y estndar. Aplica al cuerpo del mensaje y adjuntos.

Desventajas: Altamente acoplado con el protocolo de capa de transporte. La proteccin es removida automticamente por el receptor una vez que se recibe el mensaje. Solucin punto a punto, si hay intermediarios la proteccin es removida y el mensaje puede ser alterado. La seguridad se aplica a todo el contenido o no se aplica, es decir no puede elegirse selectivamente las porciones del mensaje que se asegurarn. Esto si es posible en el mdelo de seguridad en capa de mensaje.

Seguridad en aplicaciones Java EE - ICEFaces

Gestin de Registros y Respaldos en el Contexto Hospitalario

1.3.

Seguridad a nivel de capa de mensaje:

En este mdelo la informacin de seguridad est contenida dentro del mensaje SOAP, lo cual permite que dicha informacin viaje junto con el mismo. Si existen intermediarios entre el cliente y el servidor, los mismos no podrn extraer aquellas porciones del mensaje que se encuentren encriptadas. Ventajas: Informacin de seguridad dentro del mensaje. Puede aplicarse seguridad selectivamente a cada porcin del mensaje SOAP. Existencia de intermediarios entre cliente-servidor no pone en riesgo la confidencialidad e integridad de los datos enviados. Es independiente de la aplicacin y del protocolo de transporte utilizado.

Desventajas: Complejidad. Agrega sobrecarga (overhead) en la comunicacin ya que se encriptan/desencriptan porciones del mensaje.

Manejo de Usuarios, Grupos y Dominios: Para identificar a los usuarios y permitirle o denegarle el acceso a los recursos de la aplicacin se deben seguir los siguientes pasos: 1. Codificar el prompt donde el usuario ingresa sus credenciales. Esto depender del mecanismo de autenticacin utilizado (ver seccin 2). 2. Crear el deployment descriptor segn el tipo de componente (ejb, ws, web) y colocar en el la informacin de roles y reglas. 3. Agregar los usuarios y grupos necesarios en el servidor. 4. Mapear los usuarios y grupos definidos en el servidor con los roles de la aplicacin.

Seguridad en aplicaciones Java EE - ICEFaces

Gestin de Registros y Respaldos en el Contexto Hospitalario

El mapeo entre grupos y roles se utiliza para mantener independencia entre los roles de la aplicacin y los grupos definidos en el servidor. Por otra parte existe una sutil diferencia entre ambos conceptos ya que un rol define permisos para un conjunto de recursos dentro de una aplicacin, mientras que un grupo define el conjunto de usuarios autenticados en todo el servidor. Para almacenar los grupos y usuarios se definen en el servidor los dominios, los cuales pueden verse como una base de datos de usuarios y grupos admitidos. Existen bsicamente cuatro tipos de dominios: File: En el cual los usuarios y grupos se definen en un xml almacenado en el servidor. No es utilizado para clientes que se comunican mediante HTTPS sobre SSL. Admin: Define el usuario para el acceso a la consola de administracin. Certificate: En este dominio el servidor almacenar las credenciales de los usuarios en una base de datos para certificados. Si se selecciona este mecanismo el servidor utilizar certificados junto con el protocolo HTTPS para validar a los clientes. JDBC: Permite almancenar la informacin en una base de datos relacional y accederla mediante JDBC.

El dominio utilizado puede ser cambiado por cualquiera de los restantes , segn las necesidades y requerimientos de seguridad. Por ejemplo si se desea autenticacin de los clientes mediante certificados simplemente bastar con seleccionar el nuevo dominio y cargarlo con los certificados utilizados.

Seguridad en aplicaciones Java EE - ICEFaces

Gestin de Registros y Respaldos en el Contexto Hospitalario

2. Seguridad para una aplicacin web

Para tener un panorama del manejo de las peticiones en una aplicacin web se puede observar la siguiente figura:

Se utilizar seguridad declarativa mediante los deployment descriptors correspondientes: Archivo web.xml:
<web-app> <login-config> <auth-method>BASIC</auth-method> <realm-name>JDBCRealm</realm-name> </login-config> <security-role> <description/> <role-name>administrador</role-name> </security-role> <security-constraint> <web-resource-collection> <web-resource-name>view dept data</web-resource-name> <url-pattern>/sistemaAuditoria/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>administrador</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> </web-app>

Seguridad en aplicaciones Java EE - ICEFaces

Gestin de Registros y Respaldos en el Contexto Hospitalario

En este archivo se define el mecanismo de login de usuario y el dominio que utilizar para validar a los mismos, en este caso el dominio es de tipo JDBC. Luego se definen los roles para la aplicacin, en este caso existe un nico rol denominado administrador. Por ltimo se define una regla de seguridad la cual permite al rol administrador realizar GET y POST sobre todos los recursos web de la aplicacin. El elemento <user-data-constraint> se utiliza para definir el mecanismo de seguridad cuando se tiene habilitado SSL sobre HTTPS. El mapeo de roles con grupos del servidor se realiza en el archivo sun-web.xml:
<sun-web-app> <context-root>/AuditoriaSistemaRegistros</context-root> <security-role-mapping> <role-name>administradores</role-name> <group-name>administradores</group-name> </security-role-mapping> <security-role-mapping> <role-name>auditores</role-name> <group-name>auditores</group-name> </security-role-mapping> </sun-web-app>

Como se puede apreciar se definen dos mapeos, y tanto los nombres de los roles como los nombres de los grupos del servidor coinciden, pero perfectamente pueden ser distintos. Habilitacin de SSL para establecer comunicaciones seguras Para habilitar HTTPS sobre SSL es necesario disponer de certificados ya sea emitidos por una Autoridad Certificadora (CA) o auto-firmados. El certificado para el servidor debe colocarse en el keystore del mismo y los certificados de los clientes en el truststore. Esto ltimo solo es necesario si se desea autenticacin mutua. Por ltimo se debe configurar el descriptor de la aplicacin para definir el mtodo a utilizar. En el archivo web.xml anterior se defini el elemento <user-data-constraint> en el cual se indica la potencia de la proteccin requerida: Confidential: Aplica cuando el requerimiento indica que los datos a transmitir entre el cliente y servidor no deben ser observados por terceros. Integral: Aplica cuando el requerimiento indica que los datos a enviar no deben ser alterados . None: El servidor acepta peticiones tanto con seguirdad como sin seguridad incorporada. Habilitar SSL puede ser costoso para la performance de la aplicacin, por lo que no siempre es conveniente asegurar todas las pginas de la misma, sino aquellas que manejan datos crticos, como por ejemplo una pantalla de login de usuario, etc.

Seguridad en aplicaciones Java EE - ICEFaces

10

Gestin de Registros y Respaldos en el Contexto Hospitalario Mecanismos de Autenticacin Existen cuatro mecanismos de seguridad disponibles en un servidor Java EE. Estos son: Autenticacin bsica sobre HTTP Autenticacin basada en formulario sobre HTTP. Autenticacin SSL sobre HTTPS unidireccional. Autenticacin SSL sobre HTTPS bidireccional.

Autenticacin bsica sobre HTTP El cliente realiza una peticin al servidor, el cual presenta una pantalla para el ingreso de las credenciales del usuario. Una vez ingresadas, el usuario confirma y los datos viajan al servidor donde sern validados contra el dominio.

Elemento necesario en el archivo web.xml:

<login-config> <auth-method>BASIC</auth-method> </login-config>

Autenticacin basada en formulario sobre HTTP Es similar al mecanismo anterior, simplemente que se le permite al desarrollador disear la pantalla de login de usuario. A su vez, deber disear una pgina de error a la cual sern redirigidos aquellos usuarios que no se autenticaron correctamente en el servidor.

Seguridad en aplicaciones Java EE - ICEFaces

11

Gestin de Registros y Respaldos en el Contexto Hospitalario

Fragmento de cdigo para el archivo web.xml:

<login-config> <auth-method>FORM</auth-method> <realm-name>file</realm-name> <form-login-config> <form-login-page>/logon.jsp</form-login-page> <form-error-page>/logonError.jsp</form-error-page> </form-login-config> </login-config>

Autenticacin SSL sobre HTTPS unidireccional Requiere que el cliente disponga de un certificado de clave pblica con el cual se autenticar contra el servidor. Una vez autenticado, se establece la conexin segura y al momento de realizar el login los datos sern encriptados para asegurar la confidencialidad e intergridad de los mismos. Archivo web.xml:
<login-config> <auth-method>CLIENT-CERT</auth-method> </login-config>

Autenticacin SSL sobre HTTPS bidireccional En la autenticacin mutua, tanto el cliente como el servidor se autentican uno contra el otro. El cliente realiza la peticin y el servidor enva su certificado. En ese momento el cliente lo vlida, chequeando que exista en su almacen de certificados confiables y en caso positivo enva su propio certificado para que el servidor lo valide. El servidor lo valida de la misma manera y en caso satisftactorio se le otorga al cliente el acceso al recurso protegido.

Seguridad en aplicaciones Java EE - ICEFaces

12

Gestin de Registros y Respaldos en el Contexto Hospitalario

Seguridad en aplicaciones Java EE - ICEFaces

13

Gestin de Registros y Respaldos en el Contexto Hospitalario

3. Seguridad Ajax en ICEFaces

Dada la aparicin de tecnologas como ajax la tendencia es desarrollar sistemas centrados en el cliente. Esto va en contra de una premisa fundamental: no confiar en el cliente. En base a esta premisa se han desarrollado las principales arquitecturas que atacan la problemtica de la seguridad. Por lo tanto al utilizar la mayora de las tecnologas ajax, se deber tener en cuenta los problemas de seguridad, ya que estas proveen un ambiente de ejecucin en el cliente en el que coexisten la capa de presentacin y la lgica de negocio. Con esto se logran los efectos caracteristicos de las aplicaciones de interfaz ricas, pero es imposible proteger ambas capas en este mdelo. Para hacerlo, se debe colocar el cdigo sensible en el servidor, limitando el potencial de ajax y agregando complejidad a la aplicacin. Por lo tanto, migrando hacia un sistema centrado en el servidor, y teniendo en cuenta un mdelo y arquitectura de seguridad tan reconocido en la industria como el de Java EE, la problemtica se traduce en integrar la tecnologa ajax en la plataforma Java EE para disponer de los mecanismos de seguridad descritos anteriormente manteniendo el mismo potencial. Para mantener el potencial, ICEFaces se basa en JSF, tecnologa centrada en el servidor, carente de componentes ajax y que realiza una actualizacin de pantalla completa para modificar datos de presentacin. A continuacin se muestra el ciclo de vida de una peticin en JSF:

El ciclo de vida de JSF comienza con una peticin del usuario, la cual es procesada para obtener sus parmetros y luego pasa por una validacin y posterior actualizacin del mdelo. Por ltimo se realizan los procesamientos correspondientes en la aplicacin y se enva la respuesta al cliente. Al introducir Ajax es fundamental no evadir el ciclo de vida de JSF ya que esto se traduce en evadir el mdelo de aplicacin centrado en el servidor y por ende su mecanismo de seguridad. Por lo tanto, la utilizacin del componente XHR (XmlHttpRequest) debe desembocar en un submit estndar del formulario para que el ciclo JSF pueda ejecutarse completamente. Existen dos mecanismos requeridos para esto: Submit parcial y automatico que reaccione a las acciones del usuario en la interfaz grfica de modo que realice una peticin al servidor para su procesamiento. Automatico significa que cada componente de la interfaz realizar el submit sin intervencin del desarrollador, mientras que parcial se refiere a que no es necesario realizar el submit de todo el formulario sino nicamente de aquellos componentes con los que el usuario est interactuando. 14

Seguridad en aplicaciones Java EE - ICEFaces

Gestin de Registros y Respaldos en el Contexto Hospitalario Mecanismo incremental de actualizacin de la pgina para evitar el renderizado excesivo de la pgina, buscando realizar la menor cantidad posible de actualizaciones.

A continuacin se visualiza la arquitectura propuesta por ICEFaces para integrar la tecnologa ajax al ciclo de vida JSF:

Claramente sobresalen 3 elementos principales en la arquitectura ICEFaces: Suite de Componentes ICEFaces que permiten realizar el submit parcial segn las acciones del usuario sobre ellos, liberando al desarrollador de introducir cdigo JavaScript de bajo nivel. El Framework ICEFaces es la extensin de JSF poniendo la atencin en la fase de renderizado (rendering phase). Utiliza la tcnica direct-to-DOM para realizar las actualizaciones incrementales lo que resulta en una mejora de la experiencia para el usuario. El Puente Ajax es el encargado de establecer la comunicacin entre el cliente y el servidor, y para ello dispone de componentes en ambos extremos.

El puente Ajax implementado en JavaScript se encarga de implementar los dos mecanismos rcien detallados (submit parcial e actualizacin incremental), exponiendo un nico submit estndar mediante XHR y manejando nicamente datos de la presentacin durante las actualizaciones incrementales. Esto evita la introduccin de agujeros en la arquitectura de seguridad Java EE. El mecanismo de submit parcial est embebido dentro de cada componente ICEFaces y el desarrollador puede utilizarlo simplemente asignando el valor true al atributo partialSubmit del mismo. Una vez realizado el submit parcial por parte del usuario el puente se encarga de llevarlo a cabo comunicndose con el servidor y actualizando la pgina de manera transparente. Para implementar las actualizaciones incrementales ICEFaces ofrece una tcnica denominada direct-to-DOM en la cual se mantiene un DOM (Data Object Model) en el servidor. Este DOM es actualizado cada vez que se recibe una peticin del usuario. Cuando ocurren modificaciones en dicho DOM se envan las actualizaciones incrementales mediante el puente Ajax hacia el cliente, donde la parte del puente que reside en el mismo se encarga de actualizar el DOM del explorador web. A continuacin se presenta un diagrama de arquitectura ms detallado en el cual se pueden ver los componentes y conceptos mencionados. Seguridad en aplicaciones Java EE - ICEFaces 15

Gestin de Registros y Respaldos en el Contexto Hospitalario

Control de Acceso Adems de las caractersticas de seguridad Ajax que ofrece ICEFaces tambin soporta control de acceso en la capa de presentacin. Para permitir/denegar acceso a los recursos se utilizan los siguientes atributos de los compoenntes: Rendered = {condicion} Disabled = {condifion} renderedOnUserRole = {roles de usuario} enabledOnUserRole = {roles de usuario}

La utilizacin de este mecanismo se traduce de forma transparente en la utilizacin de los mecanismos de control de acceso provistos por la arquitectura Java EE.

Seguridad en aplicaciones Java EE - ICEFaces

16

Gestin de Registros y Respaldos en el Contexto Hospitalario

4. Conclusiones
ICEFaces ofrece un framework para desarrollo de aplicaciones con tecnologa Ajax centradas en el servidor, eliminando la necesidad que el programador escriba cdigo JavaScript de bajo nivel. Los principales beneficios en trminos de seguridad son los siguientes: No se introducen agujeros de seguridad en la arquitectura Java EE al momento de utilizar XHR ya que este realiza un submit estndar disparando el ciclo de vida de JSF el cual cumple los requisitos de seguridad establecidos por Java EE. Prevencin de inyeccin de cdigo JavaScript malicioso es llevado a cabo por el framework JSF y heredado por ICEFaces. Compatibilidad con tecnologas de persistencia como Hibernate, las cuales previenen los ataques de inyeccin SQL. Tcnicas de control de acceso de Java EE pueden ser reutilizadas para implementar el control de acceso en la capa de presentacin. Compatibilidad con SSL permite establecer conexiones seguras.

Seguridad en aplicaciones Java EE - ICEFaces

17

Gestin de Registros y Respaldos en el Contexto Hospitalario

5. Referencias
[WEB-01] [WEB-02] [WEB-03] [WEB-04] [WEB-05] Java EE 5 Tutorial http://java.sun.com/javaee/5/docs/tutorial/doc/bnbwj.html Sun Java System Aplication Server 9.1 Administration Guide http://docs.sun.com/app/docs/doc/819-3671/ablqx?a=browse ICEFaces Security Whitepaper http://www.icefaces.org/main/resources/whitepapers.iface ICEFaces Developer Guide http://www.icefaces.org/main/resources/documentation.iface MySpace Worm Technical Explanation http://namb.la/popular/tech.html

Seguridad en aplicaciones Java EE - ICEFaces

18